From istvan at istvan.org Mon Jul 2 11:26:08 2018 From: istvan at istvan.org (Stefan van Lieshout) Date: Mon, 02 Jul 2018 12:26:08 +0200 Subject: [Pkg-openldap-devel] Bug#902853: ldap-utils: Logfile warnings after upgrade to 2.4.40+dfsg-1+deb8u4 Message-ID: <20180702102608.32357.58263.reportbug@tsuica.istvan.org> Package: ldap-utils Version: 2.4.40+dfsg-1+deb8u3 Severity: normal Dear Maintainer, The upgrade to 2.4.40+dfsg-1+deb8u4 results in a lot of warnings in the logfile /var/log/auth.log Jul 2 09:27:43 hostname apache2: ldapdb_canonuser_plug_init() failed in sasl_canonuser_add_plugin(): invalid parameter supplied Jul 2 09:27:43 hostname apache2: _sasl_plugin_load failed on sasl_canonuser_init for plugin: ldapdb This is not only for the apache2 process, also sssd_be, sm-mta & php spawn the same warnings. A downgrade to 2.4.40+dfsg-1+deb8u3 did solve the issue. There was no disruption in service noticed when version 2.4.40+dfsg-1+deb8u4 was installed. With regards, Stefan -- System Information: Debian Release: 8.11 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-6-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ldap-utils depends on: ii libc6 2.19-18+deb8u10 ii libgnutls-deb0-28 3.3.8-6+deb8u7 ii libldap-2.4-2 2.4.40+dfsg-1+deb8u3 ii libsasl2-2 2.1.26.dfsg1-13+deb8u1 Versions of packages ldap-utils recommends: ii libsasl2-modules 2.1.26.dfsg1-13+deb8u1 Versions of packages ldap-utils suggests: ii libsasl2-modules-gssapi-mit 2.1.26.dfsg1-13+deb8u1 -- no debconf information From owner at bugs.debian.org Mon Jul 2 17:51:04 2018 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Mon, 02 Jul 2018 16:51:04 +0000 Subject: [Pkg-openldap-devel] Processed: reassign 902853 to libldap-2.4-2 References: <1530550024-1158-bts-ryan@nardis.ca> Message-ID: Processing commands for control at bugs.debian.org: > reassign 902853 libldap-2.4-2 2.4.40+dfsg-1+deb8u4 Bug #902853 [ldap-utils] ldap-utils: Logfile warnings after upgrade to 2.4.40+dfsg-1+deb8u4 Bug reassigned from package 'ldap-utils' to 'libldap-2.4-2'. No longer marked as found in versions openldap/2.4.40+dfsg-1+deb8u3. Ignoring request to alter fixed versions of bug #902853 to the same values previously set Bug #902853 [libldap-2.4-2] ldap-utils: Logfile warnings after upgrade to 2.4.40+dfsg-1+deb8u4 Marked as found in versions openldap/2.4.40+dfsg-1+deb8u4. > thanks Stopping processing here. Please contact me if you need assistance. -- 902853: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902853 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From ryan at nardis.ca Mon Jul 2 18:02:27 2018 From: ryan at nardis.ca (Ryan Tandy) Date: Mon, 2 Jul 2018 10:02:27 -0700 Subject: [Pkg-openldap-devel] Bug#902853: ldap-utils: Logfile warnings after upgrade to 2.4.40+dfsg-1+deb8u4 In-Reply-To: <20180702102608.32357.58263.reportbug@tsuica.istvan.org> References: <20180702102608.32357.58263.reportbug@tsuica.istvan.org> <20180702102608.32357.58263.reportbug@tsuica.istvan.org> Message-ID: <20180702170227.ncyptamgr5g6gfyy@comet.nardis.ca> Hi Stefan, On Mon, Jul 02, 2018 at 12:26:08PM +0200, Stefan van Lieshout wrote: >The upgrade to 2.4.40+dfsg-1+deb8u4 results in a lot of warnings in the logfile /var/log/auth.log > >Jul 2 09:27:43 hostname apache2: ldapdb_canonuser_plug_init() failed in sasl_canonuser_add_plugin(): invalid parameter supplied >Jul 2 09:27:43 hostname apache2: _sasl_plugin_load failed on sasl_canonuser_init for plugin: ldapdb > >This is not only for the apache2 process, also sssd_be, sm-mta & php spawn the same warnings. > >A downgrade to 2.4.40+dfsg-1+deb8u3 did solve the issue. Thank you for the report. Indeed one thing that changed in this version is that libldap now initializes libsasl eagerly, instead on on first use, so previously these messages might have only appeared when a process invoked SASL via LDAP - or not at all. You are the first to mention an issue like this, though, so I wonder if it's caused by a local configuration on your side. Is your libsasl2-modules-ldap up-to-date with libsasl2-2? What do you use it for? From owner at bugs.debian.org Mon Jul 2 18:09:03 2018 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Mon, 02 Jul 2018 17:09:03 +0000 Subject: [Pkg-openldap-devel] Processed: tagging 902853 References: <1530551104-3624-bts-ryan@nardis.ca> Message-ID: Processing commands for control at bugs.debian.org: > tags 902853 + moreinfo Bug #902853 [libldap-2.4-2] ldap-utils: Logfile warnings after upgrade to 2.4.40+dfsg-1+deb8u4 Added tag(s) moreinfo. > thanks Stopping processing here. Please contact me if you need assistance. -- 902853: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902853 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From ryan at nardis.ca Mon Jul 16 22:23:14 2018 From: ryan at nardis.ca (Ryan Tandy) Date: Mon, 16 Jul 2018 14:23:14 -0700 Subject: [Pkg-openldap-devel] Is there a better way to handle Kerberos ldap configuration In-Reply-To: References: Message-ID: <20180716212314.3lfidtahzfz6vfo2@comet.nardis.ca> Hi Sam, On Mon, Jul 16, 2018 at 05:02:34PM -0400, Sam Hartman wrote: >Mostly for the slapd maintainer. >Currently krb5-kdc-ldap ships an OpenLDAP schema file for the Kerberos >schema. >I just noticed that we don't ship the ldif file for the newer format >slapd config and will be fixing that in my next upload. Great, thanks! >Currently in order to take advantage of either, the administrator needs >to grab the schema or ldif out of /usr/share/doc/krb5-kdc-ldap and >manually process it. Yes. >Is there some way we could do better than this? How do we handle >optional schemas in Debian? If we don't have a better way, would you >consider a patch to support the Kerberos schema in the Debian slapd >package? What do you mean by "support"? I would be reluctant to add new schemas in an automated way - this should be an explicit action by the administrator. Our default configuration just includes the few most widely used schemas. A couple of thoughts on the rest of the bug: Schemas are best considered as static data, rather than user-editable configuration. From this perspective, /usr is the right place for them. (In fact, we have a long-term wishlist item of moving the default schemas away from /etc, too.) Shipping your schema uncompressed would be one way to reduce friction for slapd administrators but of course has a cost in disk space. I do think shipping the .ldif in addition to the .schema will already be a major usability improvement, so thanks for doing that! Ryan From hartmans at debian.org Mon Jul 16 22:02:34 2018 From: hartmans at debian.org (Sam Hartman) Date: Mon, 16 Jul 2018 17:02:34 -0400 Subject: [Pkg-openldap-devel] Is there a better way to handle Kerberos ldap configuration Message-ID: Hi. Mostly for the slapd maintainer. Currently krb5-kdc-ldap ships an OpenLDAP schema file for the Kerberos schema. I just noticed that we don't ship the ldif file for the newer format slapd config and will be fixing that in my next upload. Currently in order to take advantage of either, the administrator needs to grab the schema or ldif out of /usr/share/doc/krb5-kdc-ldap and manually process it. Is there some way we could do better than this? How do we handle optional schemas in Debian? If we don't have a better way, would you consider a patch to support the Kerberos schema in the Debian slapd package? From ryan at nardis.ca Tue Jul 17 02:47:27 2018 From: ryan at nardis.ca (Ryan Tandy) Date: Mon, 16 Jul 2018 18:47:27 -0700 Subject: [Pkg-openldap-devel] Bug#829749: Is there a better way to handle Kerberos ldap configuration In-Reply-To: References: <20180716212314.3lfidtahzfz6vfo2@comet.nardis.ca> <146774406398.13471.9853904910177362165.reportbug@kirtar> Message-ID: <20180717014727.3q4tcd54cd2reml4@kiwi.nardis.ca> On Mon, Jul 16, 2018 at 08:08:41PM -0400, Sam Hartman wrote: > Ryan> What do you mean by "support"? I would be reluctant to add new > Ryan> schemas in an automated way - this should be an explicit > Ryan> action by the administrator. Our default configuration just > Ryan> includes the few most widely used schemas. > >So, I agree administrator action should be required. >However, especially with the schema managed over the ldap protocol, I >find the process of updating a schema moderately tedious. >Mostly I'm wondering if you have considered helping the administrator >out by having a simple command they can run to enable a schema once they >have decided to do so. I had not, actually. Assuming our default slapd configuration, adding a schema is just: ldapadd -H ldapi:// -Y EXTERNAL -f /path/to/schema.ldif Is that the command you suggest could be automated, or is there more to your process than that? I appreciate your feedback and will definitely consider it - just want to make sure I've understood you correctly. My only issue with a wrapper script (or such) is that authenticating to the config DB with SASL EXTERNAL is merely a default, not something we can assume in general... I don't know how commonly users change that default, but I know it does happen. Ryan From hartmans at debian.org Tue Jul 17 01:08:41 2018 From: hartmans at debian.org (Sam Hartman) Date: Mon, 16 Jul 2018 20:08:41 -0400 Subject: [Pkg-openldap-devel] Is there a better way to handle Kerberos ldap configuration In-Reply-To: <20180716212314.3lfidtahzfz6vfo2@comet.nardis.ca> (Ryan Tandy's message of "Mon, 16 Jul 2018 14:23:14 -0700") References: <20180716212314.3lfidtahzfz6vfo2@comet.nardis.ca> Message-ID: >>>>> "Ryan" == Ryan Tandy writes: Ryan> Hi Sam, Ryan> On Mon, Jul 16, 2018 at 05:02:34PM -0400, Sam Hartman wrote: >> Mostly for the slapd maintainer. Currently krb5-kdc-ldap ships >> an OpenLDAP schema file for the Kerberos schema. I just noticed >> that we don't ship the ldif file for the newer format slapd >> config and will be fixing that in my next upload. Ryan> Great, thanks! >> Currently in order to take advantage of either, the administrator >> needs to grab the schema or ldif out of >> /usr/share/doc/krb5-kdc-ldap and manually process it. Ryan> Yes. >> Is there some way we could do better than this? How do we handle >> optional schemas in Debian? If we don't have a better way, would >> you consider a patch to support the Kerberos schema in the Debian >> slapd package? Ryan> What do you mean by "support"? I would be reluctant to add new Ryan> schemas in an automated way - this should be an explicit Ryan> action by the administrator. Our default configuration just Ryan> includes the few most widely used schemas. So, I agree administrator action should be required. However, especially with the schema managed over the ldap protocol, I find the process of updating a schema moderately tedious. Mostly I'm wondering if you have considered helping the administrator out by having a simple command they can run to enable a schema once they have decided to do so. Ryan> A couple of thoughts on the rest of the bug: Ryan> Schemas are best considered as static data, rather than Ryan> user-editable configuration. From this perspective, /usr is Ryan> the right place for them. (In fact, we have a long-term Ryan> wishlist item of moving the default schemas away from /etc, Ryan> too.) Agreed. Ryan> Shipping your schema uncompressed would be one way to reduce Ryan> friction for slapd administrators but of course has a cost in Ryan> disk space. I do think shipping the .ldif in addition to the Ryan> .schema will already be a major usability improvement, so Ryan> thanks for doing that! O definitely; it was a bug we weren't doing so. I noticed we were shipping an ldif, but forgot it was the Novell Edirectory format not the OpenLDAP format. From hartmans at debian.org Tue Jul 17 13:00:27 2018 From: hartmans at debian.org (Sam Hartman) Date: Tue, 17 Jul 2018 08:00:27 -0400 Subject: [Pkg-openldap-devel] Bug#829749: Is there a better way to handle Kerberos ldap configuration In-Reply-To: <20180717014727.3q4tcd54cd2reml4@kiwi.nardis.ca> (Ryan Tandy's message of "Mon, 16 Jul 2018 18:47:27 -0700") References: <20180716212314.3lfidtahzfz6vfo2@comet.nardis.ca> <146774406398.13471.9853904910177362165.reportbug@kirtar> <20180717014727.3q4tcd54cd2reml4@kiwi.nardis.ca> Message-ID: >>>>> "Ryan" == Ryan Tandy writes: Ryan> I had not, actually. Assuming our default slapd configuration, Ryan> adding a schema is just: Ryan> ldapadd -H ldapi:// -Y EXTERNAL -f /path/to/schema.ldif Ah, looking back at my notes, you're right. Adding the schema was easy. The hard parts were: * setting up a separate database because I wanted the Kerberos stuff isolated * Setting up the right indexes * Configuring access control and the appropriate SASL stuff. And sadly, a lot of that was custom enough that I can't think of good automation. OK, it doesn't look like there's much to do for this bug. I'll think about leaving the schema and ldif decompressed.