[389-users] Re: cockpit doubt, or rebuild Cockpit plugin

On 3/5/20 10:51 PM, Mark Reynolds wrote:
>
> On 3/4/20 10:06 PM, William Brown wrote:
>>
>>> On 4 Mar 2020, at 23:14, Alberto Viana <albertocrj@gmail.com> wrote:
>>>
>>> William/Mark
>>>
>>> In master branch this function is checkPackageAndLoad() and it's
>>> found in src/cockpit/389-console/src/ds.jsx, or in older versions
>>> it's somewhere in ds.js (it has a different function name though),
>>> then just rebuild cockpit
>>>
>>> Already did that (even before your suggestion), but I just wonder
>>> like William if there's no "smart" way to check if already has 389
>>> in the system.
>> William does wonder, and William also knows Mark and Simon who wrote
>> the cockpit tooling are very smart. So perhaps there is a reason for
>> why it was done like this that I'm not aware of.
>>
>> Generally the main reason I hit things like this is because I use
>> prefix builds in my environment, so /opt/dirsrv. I'm wondering if an
>> alternate option here Mark is to use the presence of a defaults.inf
>> in one of the known locations or via PREFIX, similar to
>> src/lib389/lib389/paths.py, or even exposing that in a tool like
>> ds_present that returns a 1/0 based on if a defaults.inf can be
>> found. That would solve the case with lib389 present but not a
>> 389-ds-base. Simply loading Paths() isn't enough, because it's lazy
>> loaded. but you could do Paths().with_systemd to trigger the read?
>>
>> Just an idea :)
> There are several checks we do before we load the Directory Server
> UI.  First we check if 389-ds-base is even installed.  This is the rpm
> check.  If it is installed, then we check if there is at least one
> instance available (via lib389).  If any of these conditions are not
> met we load a unique page describing the problem and how to fix it.
>
> At this time the cockpit plugin will NOT work with custom PREFIX'ed
> builds as there is no way to tell cockpit or lib389 that DS is under a
> custom location.   Checking for defaults.inf might be an option to
> find and set the PREFIX env var when calling the CLI from the UI, but
> it would still require a significant amount of grunt work to the UI
> source code to make this work.  I wonder if the ".dsrc" functionality
> could be extended to handler this case and set the PREFIX in lib389
> for us?  Contributions are always welcome :-)

I am not expert in that area however I think .dsrc is ldap_client
oriented and defaults.inf is server oriented. IMHO I expect prefix to be
set  defaults.inf (in addition to env var) rather than .dsrc.

>
>>
>>
>>> Thanks anyway.
>>>
>>> Alberto Viana
>>>
>>> On Tue, Mar 3, 2020 at 9:32 PM William Brown <wbrown@suse.de> wrote:
>>>
>>>
>>>> On 4 Mar 2020, at 04:07, Mark Reynolds <mreynolds@redhat.com> wrote:
>>>>
>>>>
>>>>
>>>> On 3/3/20 1:01 PM, Mark Reynolds wrote:
>>>>>
>>>>> On 3/3/20 12:28 PM, Alberto Viana wrote:
>>>>>> Hi Guys,
>>>>>>
>>>>>> I'm testing some versions of 389 and I realise that in newer
>>>>>> versions, cockpit stopped to work to me:
>>>>>>
>>>>>> There is no 389-ds-base package installed on this system. Sorry
>>>>>> there is nothing to manage...
>>>>>>
>>>>>> In my case (due to internal reasons) we compile our version of 389.
>>>>>>
>>>>>> Is this an expected behavior? Is it suppose to only work if I
>>>>>> have a 389 package installed in the system? There's any
>>>>>> workaround for that?
>>>>> It's looking for an rpm via:
>>>>>
>>>>>      rpm -q 389-ds-base
>>>>>
>>>>> Just install the official rpm, and overwrite it with your private
>>>>> build.
>>>>>
>>>> If you are doing a private build anyway, you could just remove this
>>>> check from the UI code:
>>>>
>>>> In master branch this function is checkPackageAndLoad() and it's
>>>> found in src/cockpit/389-console/src/ds.jsx, or in older versions
>>>> it's somewhere in ds.js (it has a different function name though),
>>>> then just rebuild cockpit
>>> Couldn't we do an instance list instead? That way it would catch
>>> anything that's in /etc/dirsrv or /data?
>>>
>>>
>>>>
>>>>
>>>>>
>>>>> HTH,
>>>>>
>>>>> Mark
>>>>>
>>>>>> Thanks
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 389-users mailing list --
>>>>>> 389-users@lists.fedoraproject.org
>>>>>>
>>>>>> To unsubscribe send an email to
>>>>>> 389-users-leave@lists.fedoraproject.org
>>>>>>
>>>>>> Fedora Code of Conduct:
>>>>>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>>>>>
>>>>>> List Guidelines:
>>>>>> https://fedoraproject.org/wiki/Mailing_list_guidelines
>>>>>>
>>>>>> List Archives:
>>>>>> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
>>>>>>
>>>>> --
>>>>>
>>>>> 389 Directory Server Development Team
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 389-users mailing list --
>>>>> 389-users@lists.fedoraproject.org
>>>>>
>>>>> To unsubscribe send an email to
>>>>> 389-users-leave@lists.fedoraproject.org
>>>>>
>>>>> Fedora Code of Conduct:
>>>>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>>>>
>>>>> List Guidelines:
>>>>> https://fedoraproject.org/wiki/Mailing_list_guidelines
>>>>>
>>>>> List Archives:
>>>>> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
>>>>>
>>>> --
>>>>
>>>> 389 Directory Server Development Team
>>>>
>>>> _______________________________________________
>>>> 389-users mailing list -- 389-users@lists.fedoraproject.org
>>>> To unsubscribe send an email to
>>>> 389-users-leave@lists.fedoraproject.org
>>>> Fedora Code of Conduct:
>>>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>>> List Guidelines:
>>>> https://fedoraproject.org/wiki/Mailing_list_guidelines
>>>> List Archives:
>>>> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
>>> —
>>> Sincerely,
>>>
>>> William Brown
>>>
>>> Senior Software Engineer, 389 Directory Server
>>> SUSE Labs
>>>
>> —
>> Sincerely,
>>
>> William Brown
>>
>> Senior Software Engineer, 389 Directory Server
>> SUSE Labs
>> _______________________________________________
>> 389-users mailing list -- 389-users@lists.fedoraproject.org
>> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
>
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org