openldap-technical

openldap-technical@openldap.org

18 participants
9897 discussions

Locker killed to resolve a deadlock
by Jorgen Lundman 21 Sep '17

21 Sep '17

openldap-2.4.36 db-4.8.30.NC Solaris-10u11 Hello list, We've been running those LDAP versions for years and we have been pretty pleased with it. But then "they" went and added an automated test script, that adds some records every 10 mins, confirms they are replicated all the way to the frontends, then deletes the records. This has started to cause trouble, in the last month or so. The errors are: Sep 22 06:08:26 vmx02 slapd[14039]: [ID 960831 local4.debug] => bdb_idl_delete_key: c_get failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30994) Sep 22 06:13:37 vmx02 last message repeated 36 times Sep 22 06:13:44 vmx02 slapd[14039]: [ID 960831 local4.debug] => bdb_idl_delete_key: c_get failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30994) Sep 22 06:20:17 vmx02 last message repeated 39 times Until we restart slapd. Setup is: prov (1 writer) -> ldapmaster -> ldapslave(s) -> frontend(s) -> ldapslave(s) -> frontend(s) -> frontend(s) The problem happens the most on frontend servers, but occasionally on ldapslaves, and twice now on ldapmaster. So we don't think it is syncrepl related. One answer would be to stop the 10min "ldap sync test" script of course, but it would be nice to solve the actual problem. slapd.conf, on slaves/frontend look like: include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/company-schema/qmail.schema include /usr/local/etc/openldap/company-schema/local.schema include /usr/local/etc/openldap/company-schema/RADIUS-LDAPv3.schema include /usr/local/etc/openldap/company-schema/AmavisdLDAP.schema include /usr/local/etc/openldap/company-schema/analyse.schema include /usr/local/etc/openldap/company-schema/formail.schema include /usr/local/etc/openldap/company-schema/filter.schema pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args loglevel sync database monitor access to dn.subtree="cn=Monitor" by dn="cn=admin,dc=company,dc=jp" read by * none database bdb suffix "dc=company,dc=jp" rootdn "cn=admin,dc=company,dc=jp" lastmod on checkpoint 128 15 overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 cachesize 10000 idlcachesize 15000 directory /usr/local/var/openldap-data index objectClass eq index uid eq index uidNumber eq index mail eq index mailAlternateAddress pres,eq index deliveryMode eq index accountStatus eq index gecos eq index radiusGroupName eq index o pres,eq index entryCSN,entryUUID eq dbconfig set_lk_detect DB_LOCK_DEFAULT dbconfig set_lg_max 52428800 dbconfig set_cachesize 0 67108864 1 dbconfig set_flags db_log_autoremove dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 syncrepl rid=345 provider=ldap://ldapslave01 type=refreshAndPersist interval=00:00:00:30 searchbase="dc=company,dc=jp" filter="(objectClass=*)" attrs="*,+" scope=sub schemachecking=off bindmethod=simple binddn="uid=replicate,o=companyserver.jp,ou=admin,dc=company,dc=jp" credentials="<secret>" retry="60 10 300 +" updateref ldap://ldapmaster01 -- Jorgen Lundman | <lundman(a)lundman.net> Unix Administrator | +81 (0)90-5578-8500 Shibuya-ku, Tokyo | Japan

1 0

Re: slapd: null_callback : error code 0x14
by Quanah Gibson-Mount 21 Sep '17

21 Sep '17

--On Tuesday, September 19, 2017 7:40 PM -0700 "Paul B. Henson" <henson(a)acm.org> wrote: > Hmm. I only have one active master, and it's the only server receiving > updates. Let me try including some more detail on an error from this > morning. > > So here's the error on the replica: > > Sep 19 03:56:19 coeus slapd[43551]: null_callback : error code 0x14 > Sep 19 03:56:19 coeus slapd[43551]: syncrepl_message_to_op: rid=003 > be_modify uid=egr44503,ou=group,dc=cpp,dc=edu (20) Well, my first question is, do you see these changes to this group entry in the log from your other rid as well? I.e., if it is being applied twice, you should see each modification logged twice. Usually with sync logging, you have lines noting what the CSN is that's being processed as well. There's not enough log information here to act on. :) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 2

Re: olcPasswordHash per database
by Howard Chu 21 Sep '17

21 Sep '17

Nikos Voutsinas wrote: > Hello, > > We need for a specific database (olcDatabase) to force an SHA password hash, > while keeping the default hashing scheme for the rest of them (the SSHA). > However it seems that olcPasswordHash is not allowed with-in an olcDatabase > object. > > What's the suggested method to overwrite the default password hash for a > specific db? Not currently supported. You're welcome to submit a patch to implement this. In the meantime, you can run a separate slapd instance, and tie it back in to the first slapd using back-ldap. Overall it's probably a bad idea though. If you have anything outside of slapd depending on the specific password hash mechanism, you're doing something wrong. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

olcPasswordHash per database
by Nikos Voutsinas 21 Sep '17

21 Sep '17

Hello, We need for a specific database (olcDatabase) to force an SHA password hash, while keeping the default hashing scheme for the rest of them (the SSHA). However it seems that olcPasswordHash is not allowed with-in an olcDatabase object. What's the suggested method to overwrite the default password hash for a specific db? Thank you in advance Nikos

2 1

Re: Instructions for Open LDAP library?
by Martin van den Nieuwelaar 20 Sep '17

20 Sep '17

On 19/09/17 08:00, John Lewis wrote: > On Mon, 2017-09-18 at 14:31 +1200, Martin van den Nieuwelaar wrote: >> Hi People, >> >> I'm writing an application using Qt and wish to use the openldap >> library >> within my program to query an LDAP server. I have been searching >> for >> instructions on using the library from a client point of view but >> have >> not been successful. I tried using the man pages and I think I'm >> part >> way there but have reached an impasse on the correct way (or any way >> at >> all for that matter) to extract the results from an LDAPMessage >> *. I >> have an example search working using the command line program >> ldap_search, so the next thought is to look at the source for >> ldap_search and see what calls it makes to figure things out. This >> somehow seems like the wrong way to be going about things however. >> >> Is there something equivalent for openldap to the documentation for >> libcurl, https://ec.haxx.se/libcurl-easyhandle.html ? If there is >> that >> would be brilliant. > The libcurl library supports LDAP. Howard Chu even wrote a new LDAP > implementation for it back in 2010 to make it fully asynchronous. Is > there a good reason not to use it? > Thanks for the suggestion. I hadn't even thought to see if libcurl could perform LDAP queries, but indeed it looks like it can so this is definitely worth looking into. In the interim I did get my Qt program working, not by using the openldap library calls for which I'm still none the wiser but by using Qt's very capable and well documented QProcess class for running external programs and calling the ldapsearch command line program. Thanks again for the reply. -- R A Ward Ltd. | We take the privacy of our customers seriously. Christchurch | All sensitive E-Mail attachments MUST be encrypted. New Zealand

1 0

Using overlay rwm to rewrite search base depending on search filter
by Clément OUDOT 20 Sep '17

20 Sep '17

Hello, I am playing with overlay rwm to try to change the base DN of a search depending on a value in search filter. The goal is to rewrite base "dc=example,dc=com" to "dc=test,dc=example,dc=com" if I have (uid=login@test) in the LDAP filter. Has someone already done this? My configuration for the moment is the following, but I don't understant how to capture a value in searchFilter context to use it in searchDN context: dn: olcOverlay={0}rwm,olcDatabase={1}meta,cn=config objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: rwm olcRwmRewrite: rwm-rewriteEngine on olcRwmRewrite: rwm-rewriteContext searchFilter olcRwmRewrite: rwm-rewriteRule "uid=(.*(a))(.*)" "uid=$0$1" ":" olcRwmRewrite: rwm-rewriteContext searchDN olcRwmRewrite: rwm-rewriteRule "dc=example,dc=com" "dc=${searchFilter($1)},dc=example,dc=com" ":" Thanks for your help! Clément.

1 1

Re: slapd: null_callback : error code 0x14
by Quanah Gibson-Mount 19 Sep '17

19 Sep '17

--On Friday, September 15, 2017 8:48 PM -0700 "Paul B. Henson" <henson(a)acm.org> wrote: > So I've been putting off posting about this, but I recently upgraded to > 2.4.45, stopped using the memberof overlay, no longer have a node with > serverID 0, and overall think my ldap servers should be in good shape > :), and it's still happening, so I thought it was time... > > I'm getting weird errors in my logs about group replication changes: > > Sep 15 03:55:16 minerva slapd[71654]: null_callback : error code 0x14 > Sep 15 03:55:16 minerva slapd[71654]: syncrepl_message_to_op: rid=003 > be_modify uid=arc464,ou=group,dc=cpp,dc=edu (20) These aren't "wierd errors". 0x14=20. I.e., you're simply getting the same error logged twice. > As far as I can tell, all the updates succeed and the objects are > exactly the same on all the replicas, so these failures just seem to be > log noise? Well, error code 20 is "type or value already exists". If the replica and the masters are starting from the same point, this would tend to imply that the replica is receiving the change multiple times, and it's failing on the subsequent modify operations. There's not enough information here to really deduce much beyond that. I've seen this occur in MMR situations where two masters were updating the same entries within a short window of each other. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Antw: Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 19 Sep '17

19 Sep '17

--On Tuesday, September 19, 2017 7:31 PM +0200 Radovan Semancik <radovan.semancik(a)evolveum.com> wrote: > What I meant were external contributions from people outside of the core > team. And I have obviously missed (at least) one such contribution. I'm > sorry for this. My fault. And I get your point and I apologize for this > confusion. One thing you're likely missing is that -devel is generally used for discussion of new feature requests. The ITS system (and thus the openldap-bugs list) are where discussion generally occurs for contributions related to existing features. So the -devel list is generally much lower traffic. For example, this is the archive for September (so far): <http://www.openldap.org/lists/openldap-bugs/201709/> > I just want to point out I haven't failed to notice that all of my other > points got ignored. I didn't think any of the rest of what you said was valid so there was nothing to address. You came in with a premise that was not based on fact. There are numerous people contributing that are not direct project team members, and they don't have issues with the contribution process. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Antw: Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 19 Sep '17

19 Sep '17

--On Tuesday, September 19, 2017 11:54 AM +0200 Radovan Semancik <radovan.semancik(a)evolveum.com> wrote: > Regarding the pull requests and discussions: I have checked the devel > mailing list for several months and I haven't see any discussion > regarding a contribution. Really? You must not have looked very hard then. <http://www.openldap.org/lists/openldap-devel/201709/msg00000.html> covers some 22 contributions. <http://www.openldap.org/lists/openldap-devel/201709/msg00003.html> discussions some contributions related to man page fixes. <http://www.openldap.org/lists/openldap-devel/201706/msg00004.html> covers work I did to make TLS command line options for the ldap* tools <http://www.openldap.org/lists/openldap-devel/201706/msg00006.html> is part of an ongoing discussion of allowing ldap clients to use a specific local address <http://www.openldap.org/lists/openldap-devel/201706/msg00000.html> is a discussion about adding ldap_init_fd contribution from samba etc. > What I see as a major problem is that there is no will. OpenLDAP project > clearly needs major improvement. But there are almost no contributors to > improve the project. As demonstrated by the above you clearly are incorrect. I would generally suggest you withhold comment on the project until you have some clue what you're talking about. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 19 Sep '17

19 Sep '17

--On Friday, September 15, 2017 12:49 AM +0200 Michael Ströder <michael(a)stroeder.com> wrote: > Personally I strongly prefer static configuration because it's so much > easier to control it with the usual idempotent config management > techniques (puppet, ansible, etc.) which you need for the rest of the > system anyway. Those are all systems designed to manage flat file configurations. cn=config is not a flat file configuration, so it makes sense they're fairly useless when confronted with a concept that's significantly more forward thinking. > I'd even state that it's a strong plus of OpenLDAP compared to other LDAP > server implementations to still provide this configuration method. I think it's a strong plus to be able to reconfigure a standalone server into an MMR cluster with zero downtime, along with other critical configuration bits, such as deploying new schema, additional overlays, etc. Being able to fully automate deployments w/o requiring restarts was an exceptional win for me. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

7 11

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical