Re: Update of OpenLdap

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