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
On 30 Mar 2020, at 06:29, Laurent GUERBY laurent@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@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....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
On 3/29/20 4:53 PM, William Brown wrote:
On 30 Mar 2020, at 06:29, Laurent GUERBY laurent@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@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....
— 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....
On 30 Mar 2020, at 10:15, Mark Reynolds mreynolds@redhat.com wrote:
On 3/29/20 4:53 PM, William Brown wrote:
On 30 Mar 2020, at 06:29, Laurent GUERBY laurent@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@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....
— 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....
--
389 Directory Server Development Team
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
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@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
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
On 31 Mar 2020, at 01:14, Laurent GUERBY laurent@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
On 3/30/20 5:54 PM, William Brown wrote:
On 31 Mar 2020, at 01:14, Laurent GUERBY laurent@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@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....
On 1 Apr 2020, at 05:14, Mark Reynolds mreynolds@redhat.com wrote:
On 3/30/20 5:54 PM, William Brown wrote:
On 31 Mar 2020, at 01:14, Laurent GUERBY laurent@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@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....
--
389 Directory Server Development Team
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
On Mon, 2020-03-30 at 06:53 +1000, William Brown wrote:
On 30 Mar 2020, at 06:29, Laurent GUERBY laurent@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
389-users@lists.fedoraproject.org
-
Laurent GUERBY -
Mark Reynolds -
William Brown