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: delp...@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
