Date: Wed, 11 Aug 2021 16:52:03 +0200 From: Per olof Ljungmark <peo@nethead.se> To: ports@freebsd.org Subject: Re: Update of OpenLdap Message-ID: <1409f3c6-b903-8993-c0ed-e3135e833348@nethead.se> In-Reply-To: <bac9a38e-9ec9-5ccb-a6f7-94580a18f929@nethead.se> References: <20210807072442.0000095d@seibercom.net> <46245ca6-3f26-5acb-933b-fd8ab864ff30@nethead.se> <PH0PR16MB4245C4AD54C5E74910DFC0B380F89@PH0PR16MB4245.namprd16.prod.outlook.com> <bac9a38e-9ec9-5ccb-a6f7-94580a18f929@nethead.se>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8/11/21 12:01 PM, Per olof Ljungmark wrote: > On 8/11/21 11:33 AM, Carmel wrote: >> On Wed, 11 Aug 2021 10:49:49 +0200, Per olof Ljungmark stated: >>> On 8/7/21 1:24 PM, Jerry Seibert wrote: >>>> FreeBSD 11.4-RELEASE-p9 >>>> >>>> After the recent updating of "openldap", the follow error/warning >>>> message is presented whenever I attempt to access the database. >>>> >>>> Aug 7 07:13:57 scorpio slapd[82175]: OTP unavailable because can't >>>> read/write key database /etc/opiekeys: Permission denied >>>> >>>> Everything works fine so I don't understand what the problem is or >>>> how to correct it, or if it even needs correction. >>> >>> I have a similar problem and I think the reason is that the >>> openldap24-sasl-client port vanished and was merged into >>> openldap24-client. >>> >>> However, this made one of our ldap slaves stop working, I think this >>> is a showstopper. A switch for this is needed, in the meantime, how do >>> we build the client WITHOUT sasl? >>> >>> 20210801: >>> AFFECTS: users of OpenLDAP >>> AUTHOR: delphij@FreeBSD.org >>> >>> SASL is now always enabled for OpenLDAP. >>> >>> If you use portmaster: >>> portmaster -o net/openldap24-client openldap-sasl-client >>> If you use portupgrade: >>> portupgrade -fo net/openldap24-client openldap-sasl-client >>> If you use pkg with binary packages: >>> pkg set -o net/openldap24-sasl-client:net/openldap24-client >>> >> >> I had to change the permissions on the /etc/opiekeys file to 0666 to >> stop the message from repeating. I don't know if that is actually a >> safe solution, but it works. >> >> I agree with you that the change to this port was probably not well >> thought out. >> > > I already did this. We use saslauthd exclusively and now it looks like, > > # ldapsearch > SASL/SCRAM-SHA-1 authentication started > Please enter your password: > ldap_sasl_interactive_bind_s: Invalid credentials (49) > additional info: SASL(-13): user not found: no secret in database > > So I have no idea how I can convince slapd not look look in sasldb2.db. Sorted by reverting to 2021Q2 branch, no time to try to figure out. Does anybody know why sasl2 became a necessity? Per
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1409f3c6-b903-8993-c0ed-e3135e833348>