3:29 p.m.
Hi,
I installed 389-ds 1.4.0.21-1 on a debian 10 system.
When I use cockpit in 389-ds tab I get "{'desc': 'Inappropriate
authentication', 'info': 'SASL EXTERNAL bind requires an SSL
connection'}" so I assume I must install a real certificate.
Is there an official script I could use to configure and maintain a
letsencrypt certificate on a fresh 389-ds install?
The closest I could find (but not tried yet):
https://git.dotlan.net/dhoffend/kolab/blob/73519a40f7adbfdb86394cfb2a0b
9eab39ac9757/debian-kolab16.1/update-letsencrypt.sh
Thanks in advance,
Sincerely,
Laurent
3:53 p.m.
On 30 Mar 2020, at 06:29, Laurent GUERBY <laurent(a)guerby.net>
wrote:
Hi,
I installed 389-ds 1.4.0.21-1 on a debian 10 system.
When I use cockpit in 389-ds tab I get "{'desc': 'Inappropriate
authentication', 'info': 'SASL EXTERNAL bind requires an SSL
connection'}" so I assume I must install a real certificate.
That's probably not the cause here. More likely this is because the user cockpit is
running as doesn't have access to the LDAPI socket. LDAPI uses SASL EXTERNAL so that
the uid/gid can be checked and then mapped to directory server users. Are there cockpit
logs of what commands it's trying to execute that you can check?
Is there an official script I could use to configure and maintain a
letsencrypt certificate on a fresh 389-ds install?
The closest I could find (but not tried yet):
https://git.dotlan.net/dhoffend/kolab/blob/73519a40f7adbfdb86394cfb2a0b
9eab39ac9757/debian-kolab16.1/update-letsencrypt.sh
Thanks in advance,
Sincerely,
Laurent
_______________________________________________
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
7:15 p.m.
On 3/29/20 4:53 PM, William Brown wrote:
> On 30 Mar 2020, at 06:29, Laurent GUERBY <laurent(a)guerby.net> wrote:
>
> Hi,
>
> I installed 389-ds 1.4.0.21-1 on a debian 10 system.
>
> When I use cockpit in 389-ds tab I get "{'desc': 'Inappropriate
> authentication', 'info': 'SASL EXTERNAL bind requires an SSL
> connection'}" so I assume I must install a real certificate.
That's probably not the cause here. More likely this is because the user cockpit is
running as doesn't have access to the LDAPI socket. LDAPI uses SASL EXTERNAL so that
the uid/gid can be checked and then mapped to directory server users. Are there cockpit
logs of what commands it's trying to execute that you can check?
The server must have LDAPI configured (I hope you used dscreate to
create the instance and not setup-ds.pl), then you must log into cockpit
using root or a user with sudo privileges. Second, 1.4.0 is dead and
has not been maintained in a very long time so the UI is probably very
unstable in that version. Please use 389-ds-base-1.4.1 or higher.
HTH,
Mark
> Is there an official script I could use to configure and maintain a
> letsencrypt certificate on a fresh 389-ds install?
>
> The closest I could find (but not tried yet):
>
> https://git.dotlan.net/dhoffend/kolab/blob/73519a40f7adbfdb86394cfb2a0b
> 9eab39ac9757/debian-kolab16.1/update-letsencrypt.sh
>
> Thanks in advance,
>
> Sincerely,
>
> Laurent
> _______________________________________________
> 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
_______________________________________________
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
7:26 p.m.
On 30 Mar 2020, at 10:15, Mark Reynolds <mreynolds(a)redhat.com>
wrote:
On 3/29/20 4:53 PM, William Brown wrote:
>
>> On 30 Mar 2020, at 06:29, Laurent GUERBY <laurent(a)guerby.net> wrote:
>>
>> Hi,
>>
>> I installed 389-ds 1.4.0.21-1 on a debian 10 system.
>>
>> When I use cockpit in 389-ds tab I get "{'desc': 'Inappropriate
>> authentication', 'info': 'SASL EXTERNAL bind requires an SSL
>> connection'}" so I assume I must install a real certificate.
> That's probably not the cause here. More likely this is because the user cockpit
is running as doesn't have access to the LDAPI socket. LDAPI uses SASL EXTERNAL so
that the uid/gid can be checked and then mapped to directory server users. Are there
cockpit logs of what commands it's trying to execute that you can check?
The server must have LDAPI configured (I hope you used dscreate to create the instance
and not setup-ds.pl),
That's very true, good spotting Mark. I wonder if debian ships with pl instead of py
.... :(
then you must log into cockpit using root or a user with sudo
privileges. Second, 1.4.0 is dead and has not been maintained in a very long time so the
UI is probably very unstable in that version. Please use 389-ds-base-1.4.1 or higher.
It could be a debian packaging quirk, sometimes they backport patches instead ... we'd
need to check with that maintainer.
HTH,
Mark
>
>
>> Is there an official script I could use to configure and maintain a
>> letsencrypt certificate on a fresh 389-ds install?
>>
>> The closest I could find (but not tried yet):
>>
>> https://git.dotlan.net/dhoffend/kolab/blob/73519a40f7adbfdb86394cfb2a0b
>> 9eab39ac9757/debian-kolab16.1/update-letsencrypt.sh
>>
>> Thanks in advance,
>>
>> Sincerely,
>>
>> Laurent
>> _______________________________________________
>> 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
> _______________________________________________
> 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
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
2:05 a.m.
On Mon, 2020-03-30 at 06:53 +1000, William Brown wrote:
> On 30 Mar 2020, at 06:29, Laurent GUERBY
<laurent(a)guerby.net>
> wrote:
>
> Hi,
>
> I installed 389-ds 1.4.0.21-1 on a debian 10 system.
>
> When I use cockpit in 389-ds tab I get "{'desc': 'Inappropriate
> authentication', 'info': 'SASL EXTERNAL bind requires an SSL
> connection'}" so I assume I must install a real certificate.
That's probably not the cause here. More likely this is because the
user cockpit is running as doesn't have access to the LDAPI socket.
LDAPI uses SASL EXTERNAL so that the uid/gid can be checked and then
mapped to directory server users. Are there cockpit logs of what
commands it's trying to execute that you can check?
Before I enabled LDAPI I had the following message in the web 389-ds
component :
{'desc': "Can't contact LDAP server", 'errno': 2,
'info': 'No such file
or directory'}
After I enabled LDAPI I got :
{'desc': 'Inappropriate authentication', 'info': 'SASL
EXTERNAL bind
requires an SSL connection'}
As for cockpit logs I went through lots of pages on https://cockpit-pro
ject.org but could not find how to enable more verbose logs.
In the cockpit logs tab I just have generic information about
cockpit starting.
Thanks for your help,
Sincerely,
Laurent
2:16 a.m.
On Sun, 2020-03-29 at 20:15 -0400, Mark Reynolds wrote:
On 3/29/20 4:53 PM, William Brown wrote:
>
> > On 30 Mar 2020, at 06:29, Laurent GUERBY <laurent(a)guerby.net>
> > wrote:
> >
> > Hi,
> >
> > I installed 389-ds 1.4.0.21-1 on a debian 10 system.
> >
> > When I use cockpit in 389-ds tab I get "{'desc':
'Inappropriate
> > authentication', 'info': 'SASL EXTERNAL bind requires an SSL
> > connection'}" so I assume I must install a real certificate.
>
> That's probably not the cause here. More likely this is because the
> user cockpit is running as doesn't have access to the LDAPI socket.
> LDAPI uses SASL EXTERNAL so that the uid/gid can be checked and
> then mapped to directory server users. Are there cockpit logs of
> what commands it's trying to execute that you can check?
The server must have LDAPI configured (I hope you used dscreate to
create the instance and not setup-ds.pl), then you must log into
cockpit
using root or a user with sudo privileges.
Since the first 389-ds how to configure information I could find
mentionned setup-ds.pl I installed 389-ds-base-legacy-tools
which provides setup-ds.
I will reinstall with dscreate which is provided by python3-lib389
following :
https://www.port389.org/docs/389ds/howto/howto-install-389.html
Note : the LDAP "root_password" described above must it be be the
password of the "root" unix user or something different used only by
LDAP?
Second, 1.4.0 is dead and
has not been maintained in a very long time so the UI is probably
very
unstable in that version. Please use 389-ds-base-1.4.1 or higher.
I checked and the backport repo for debian 10 (buster) doesn't
have a more recent version than 1.4.0.
Is anyone maintaining a repository with a more recent version
than 1.4.0 for debian ?
ubuntu 18.04 has 1.3.7.10-1ubuntu1 which is even older.
Thanks in advance for your help,
Sincerely,
Laurent
10:14 a.m.
On Mon, 2020-03-30 at 09:16 +0200, Laurent GUERBY wrote:
On Sun, 2020-03-29 at 20:15 -0400, Mark Reynolds wrote:
> Second, 1.4.0 is dead and
> has not been maintained in a very long time so the UI is probably
> very
> unstable in that version. Please use 389-ds-base-1.4.1 or higher.
I checked and the backport repo for debian 10 (buster) doesn't
have a more recent version than 1.4.0.
Is anyone maintaining a repository with a more recent version
than 1.4.0 for debian ?
Debian unstable has 1.4.3 so I installed:
# tail -1 /etc/apt/sources.list
deb http://deb.debian.org/debian/ unstable main
# apt-get install 389-ds/unstable cockpit/unstable
Ran :
dscreate interactive
cockpit 389 tab showed:
"There is no 389-ds-base package installed on this system. Sorry there
is nothing to manage..."
20200330 16:50:15<mreynolds> you should see the command that
failed. Its trying to do "rpm -q 389-ds-base"
20200330 17:02:04<vashirov> ln -sf /usr/bin/true /usr/bin/rpm
After this small hack everything worked.
Thanks for the help!
Laurent
4:54 p.m.
On 31 Mar 2020, at 01:14, Laurent GUERBY <laurent(a)guerby.net>
wrote:
On Mon, 2020-03-30 at 09:16 +0200, Laurent GUERBY wrote:
> On Sun, 2020-03-29 at 20:15 -0400, Mark Reynolds wrote:
>
>> Second, 1.4.0 is dead and
>> has not been maintained in a very long time so the UI is probably
>> very
>> unstable in that version. Please use 389-ds-base-1.4.1 or higher.
>
> I checked and the backport repo for debian 10 (buster) doesn't
> have a more recent version than 1.4.0.
>
> Is anyone maintaining a repository with a more recent version
> than 1.4.0 for debian ?
Debian unstable has 1.4.3 so I installed:
# tail -1 /etc/apt/sources.list
deb http://deb.debian.org/debian/ unstable main
# apt-get install 389-ds/unstable cockpit/unstable
Ran :
dscreate interactive
cockpit 389 tab showed:
"There is no 389-ds-base package installed on this system. Sorry there
is nothing to manage..."
20200330 16:50:15<mreynolds> you should see the command that
failed. Its trying to do "rpm -q 389-ds-base"
20200330 17:02:04<vashirov> ln -sf /usr/bin/true /usr/bin/rpm
Mark, I think we should make this a bug. Instead of checking for 'rpm -q ...'
here, a better option could be to check for defaults.inf, or even to make a subcommand for
dsctl or something that show's installed codebases. This will affect freebsd etc, and
could be a good way to handle it instead. :)
Thanks Laurent, appreciate your patience with this!
After this small hack everything worked.
Thanks for the help!
Laurent
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
2:14 p.m.
On 3/30/20 5:54 PM, William Brown wrote:
> On 31 Mar 2020, at 01:14, Laurent GUERBY <laurent(a)guerby.net> wrote:
>
> On Mon, 2020-03-30 at 09:16 +0200, Laurent GUERBY wrote:
>> On Sun, 2020-03-29 at 20:15 -0400, Mark Reynolds wrote:
>>
>>> Second, 1.4.0 is dead and
>>> has not been maintained in a very long time so the UI is probably
>>> very
>>> unstable in that version. Please use 389-ds-base-1.4.1 or higher.
>> I checked and the backport repo for debian 10 (buster) doesn't
>> have a more recent version than 1.4.0.
>>
>> Is anyone maintaining a repository with a more recent version
>> than 1.4.0 for debian ?
> Debian unstable has 1.4.3 so I installed:
>
> # tail -1 /etc/apt/sources.list
> deb http://deb.debian.org/debian/ unstable main
>
> # apt-get install 389-ds/unstable cockpit/unstable
>
> Ran :
>
> dscreate interactive
>
> cockpit 389 tab showed:
>
> "There is no 389-ds-base package installed on this system. Sorry there
> is nothing to manage..."
>
> 20200330 16:50:15<mreynolds> you should see the command that
> failed. Its trying to do "rpm -q 389-ds-base"
> 20200330 17:02:04<vashirov> ln -sf /usr/bin/true /usr/bin/rpm
Mark, I think we should make this a bug. Instead of checking for 'rpm -q ...'
here, a better option could be to check for defaults.inf, or even to make a subcommand for
dsctl or something that show's installed codebases. This will affect freebsd etc, and
could be a good way to handle it instead. :)
I already removed this rpm check. It's currently under review as part
of the UI fix patch which you have already partially reviewed.
Mark
Thanks Laurent, appreciate your patience with this!
> After this small hack everything worked.
>
> Thanks for the help!
>
> Laurent
>
—
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 Directory Server Development Team
5:58 p.m.
On 1 Apr 2020, at 05:14, Mark Reynolds <mreynolds(a)redhat.com>
wrote:
On 3/30/20 5:54 PM, William Brown wrote:
>
>> On 31 Mar 2020, at 01:14, Laurent GUERBY <laurent(a)guerby.net> wrote:
>>
>> On Mon, 2020-03-30 at 09:16 +0200, Laurent GUERBY wrote:
>>> On Sun, 2020-03-29 at 20:15 -0400, Mark Reynolds wrote:
>>>
>>>> Second, 1.4.0 is dead and
>>>> has not been maintained in a very long time so the UI is probably
>>>> very
>>>> unstable in that version. Please use 389-ds-base-1.4.1 or higher.
>>> I checked and the backport repo for debian 10 (buster) doesn't
>>> have a more recent version than 1.4.0.
>>>
>>> Is anyone maintaining a repository with a more recent version
>>> than 1.4.0 for debian ?
>> Debian unstable has 1.4.3 so I installed:
>>
>> # tail -1 /etc/apt/sources.list
>> deb http://deb.debian.org/debian/ unstable main
>>
>> # apt-get install 389-ds/unstable cockpit/unstable
>>
>> Ran :
>>
>> dscreate interactive
>>
>> cockpit 389 tab showed:
>>
>> "There is no 389-ds-base package installed on this system. Sorry there
>> is nothing to manage..."
>>
>> 20200330 16:50:15<mreynolds> you should see the command that
>> failed. Its trying to do "rpm -q 389-ds-base"
>> 20200330 17:02:04<vashirov> ln -sf /usr/bin/true /usr/bin/rpm
> Mark, I think we should make this a bug. Instead of checking for 'rpm -q ...'
here, a better option could be to check for defaults.inf, or even to make a subcommand for
dsctl or something that show's installed codebases. This will affect freebsd etc, and
could be a good way to handle it instead. :)
I already removed this rpm check. It's currently under review as part of the UI fix
patch which you have already partially reviewed.
Wow look at you go, fixing stuff so fast :D
Thanks so much, I'll finish that review up today, and again, thanks Laurent for
contacting us. Please let us know if we can help you in any other ways :)
Mark
>
> Thanks Laurent, appreciate your patience with this!
>
>
>> After this small hack everything worked.
>>
>> Thanks for the help!
>>
>> Laurent
>>
> —
> 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 Directory Server Development Team
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
1487
days inactive
1489
days old
389-users@lists.fedoraproject.org
9 comments
3 participants
participants (3)
-
Laurent GUERBY -
Mark Reynolds -
William Brown