On 6 Mar 2020, at 20:30, thierry bordaz <tbordaz(a)redhat.com>
wrote:
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(a)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.
defaults.inf can exist in multiple locations relative to a prefix though, so you actually
bootstrap the discovery process via the paths.py from lib389 to look in those known
locations OR to look in PREFIX/share/dirsrv/inf for the defaults.inf to determine if the
server exists.
.dsrc is certainly about clients though, and is less about the prefix, but more about the
authentication. dsrc has no knowledge of the prefix and itself will call paths.py if
needed for LDAPI location discovery I think ....
>
>>
>>
>>> Thanks anyway.
>>>
>>> Alberto Viana
>>>
>>> On Tue, Mar 3, 2020 at 9:32 PM William Brown <wbrown(a)suse.de> wrote:
>>>
>>>
>>>> On 4 Mar 2020, at 04:07, Mark Reynolds <mreynolds(a)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(a)lists.fedoraproject.org
>>>>>>
>>>>>> To unsubscribe send an email to
>>>>>> 389-users-leave(a)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.fedoraproje...
>>>>> --
>>>>>
>>>>> 389 Directory Server Development Team
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 389-users mailing list --
>>>>> 389-users(a)lists.fedoraproject.org
>>>>>
>>>>> To unsubscribe send an email to
>>>>> 389-users-leave(a)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.fedoraproje...
>>>> --
>>>>
>>>> 389 Directory Server Development Team
>>>>
>>>> _______________________________________________
>>>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
>>>> To unsubscribe send an email to 389-users-leave(a)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.fedoraproje...
>>> —
>>> 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(a)lists.fedoraproject.org
>> To unsubscribe send an email to 389-users-leave(a)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.fedoraproje...
>
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)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.fedoraproje...
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs