openldap-technical

openldap-technical@openldap.org

14 participants
9795 discussions

How should a cron jobb handle modify(cn=config) error?
by Hallvard Breien Furuseth 07 Jan '19

07 Jan '19

We have a cn=config database with olcDbDirectory: /ldap/var/db/foobar-<directory version> A cron job in a quandary can clear things up thus: Rebuild the database in a new directory with slapadd, ldapmodify cn=config so olcDbDirectory points at the new DB directory, and finally throw away the old DB dir. ldapmodify -H ldapi:// -Q -Y EXTERNAL <<EOF # hdb can have more "interesting" problems than mdb:-) dn: olcDatabase={3}hdb,cn=config changetype: modify replace: olcDbDirectory olcDbDirectory: /ldap/var/db/foobar-$NEW_DIR_VERSION EOF Now if ldapmodify fails, what should the cron job do - in addition to alerting a human? When can it assume that the new DB dir is unused and can be deleted? ...that the old DB dir can be deleted? How complicated code should I have to examine the situation and decide what to do? Do we just wait for a human to fix things? Or is it time to restart slapd? Yet that can fail too, so next question becomes what to do next - reboot? A cron job which keeps escalating the problem in order to fix it makes me nervous - LDAP must be up. It's load balanced, so a single server in trouble is OK - unless the problem is a systemic one so all servers hiccup at once. Do others have something like this implemented? -- Hallvard

2 2

storing large blob in LDAP
by Derek Zhou 02 Jan '19

02 Jan '19

Hi, Is is possible to store large blob outside the main database, and only keep file names in the LDAP database? The blobs I want to stored are not as often used as other attributes and not indexed, so it seems to me that bloating up the main database is not economical in terms of fast disk space and overall database efficiency. Then I suppose I need a middle ware or something to combine the data from file system and data from LDAP server. Has anyone try that before? Or I should just store the blobs inside, and live with the bloated database? Thanks a lot Derek

2 1

Unable to start up the ldap server after reboot
by Bharath, Basutkar (TR Tech, Content & Ops) 02 Jan '19

02 Jan '19

HI Team, Am unable to start up the ldap server on solaris 10, could you please help us with the below error; bash-3.2# /usr/local/openldap/libexec/slapd -d 384 -u ldap -g ldap -h "ldap:/// "& >/dev/null 2>&1 [1] 8686 bash-3.2# @(#) $OpenLDAP: slapd 2.2.15 (Nov 10 2014 13:34:11) $ @opusldap1:/usr/local/sftw/openldap-2.2.15/servers/slapd bdb_initialize: Sleepycat Software: Berkeley DB 4.2.52: (December 3, 2003) Global ACL: access to attrs=userPassword by dn.base="cn=admin,dc=riag,dc=com" write(=wrscx) by group/groupOfUniqueNames/uniqueMember.base="cn=ldap_admins,dc=riag,dc=com" write(=wrscx) by anonymous auth(=x) by self write(=wrscx) by * auth(=x) Global ACL: access to attrs=printQueue by dn.base="cn=admin,dc=riag,dc=com" write(=wrscx) by group/groupOfUniqueNames/uniqueMember.base="cn=ldap_admins,dc=riag,dc=com" write(=wrscx) by self write(=wrscx) by * read(=rscx) Global ACL: access to * by dn.base="cn=admin,dc=riag,dc=com" write(=wrscx) by group/groupOfUniqueNames/uniqueMember.base="cn=ldap_admins,dc=riag,dc=com" write(=wrscx) by * read(=rscx) bdb_db_init: Initializing bdb database bdb(dc=riag,dc=com): PANIC: fatal region error detected; run recovery bdb_db_open: dbenv_open failed: DB_RUNRECOVERY: Fatal error, run database recovery (-30978) backend_startup: bi_db_open failed! (-30978) bdb(dc=riag,dc=com): DB_ENV->lock_id_free interface requires an environment configured for the locking subsystem bdb(dc=riag,dc=com): txn_checkpoint interface requires an environment configured for the transaction subsystem bdb_db_destroy: txn_checkpoint failed: Invalid argument (22) slapd stopped. connections_destroy: nothing to destroy. Sensitivity: Confidential

3 2

send_ldap_response: ber write failed
by Jean-Francois Malouin 27 Dec '18

27 Dec '18

Hi, I have those errors BER write errors that have crept up recently on 2 slapd providers in a mirror replication setup and I can't seem to find the cause of them. I must have made a change to the config but pea brain of me can't seem to find the root of it. They are now occurring a few times a day. I have turned on BER, conns, stats, and sync debugging but it's still unclear to me what is going on. Can anyone shed some light? IP=172.16.10.247 is a HAproxy server with the 2 mirrors as backends. There is also a Munin host that polls the providers every 5m or so to gather stats. Thanks and Happy Holiday! jf Here a anonymized excerpt of the logs of one server showing the error message: Dec 26 03:20:45 ldap-server slapd[4306]: daemon: listen=8, new connection on 18 Dec 26 03:20:45 ldap-server slapd[4306]: daemon: added 18r (active) listener=(nil) Dec 26 03:20:45 ldap-server slapd[4306]: conn=2799347 fd=18 ACCEPT from IP=172.16.10.247:33746 (IP=0.0.0.0:389) Dec 26 03:20:45 ldap-server slapd[4306]: daemon: activity on 2 descriptors Dec 26 03:20:45 ldap-server slapd[4306]: daemon: activity on: Dec 26 03:20:45 ldap-server slapd[4306]: 18r Dec 26 03:20:45 ldap-server slapd[4306]: Dec 26 03:20:45 ldap-server slapd[4306]: daemon: read active on 18 Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=8 active_threads=0 tvp=zero Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=9 active_threads=0 tvp=zero Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=10 active_threads=0 tvp=zero Dec 26 03:20:45 ldap-server slapd[4306]: conn=2799347 op=0 BIND dn="" method=128 Dec 26 03:20:45 ldap-server slapd[4306]: conn=2799347 op=0 RESULT tag=97 err=0 text= Dec 26 03:20:45 ldap-server slapd[4306]: daemon: activity on 1 descriptor Dec 26 03:20:45 ldap-server slapd[4306]: daemon: activity on: Dec 26 03:20:45 ldap-server slapd[4306]: Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=8 active_threads=0 tvp=zero Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=9 active_threads=0 tvp=zero Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=10 active_threads=0 tvp=zero Dec 26 03:20:45 ldap-server slapd[4306]: daemon: activity on 1 descriptor Dec 26 03:20:45 ldap-server slapd[4306]: daemon: activity on: Dec 26 03:20:45 ldap-server slapd[4306]: 18r Dec 26 03:20:45 ldap-server slapd[4306]: Dec 26 03:20:45 ldap-server slapd[4306]: daemon: read active on 18 Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=8 active_threads=0 tvp=zero Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=9 active_threads=0 tvp=zero Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=10 active_threads=0 tvp=zero Dec 26 03:20:45 ldap-server slapd[4306]: daemon: activity on 1 descriptor Dec 26 03:20:45 ldap-server slapd[4306]: daemon: activity on: Dec 26 03:20:45 ldap-server slapd[4306]: Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=8 active_threads=0 tvp=zero Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=9 active_threads=0 tvp=zero Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=10 active_threads=0 tvp=zero Dec 26 03:20:45 ldap-server slapd[4306]: daemon: activity on 1 descriptor Dec 26 03:20:45 ldap-server slapd[4306]: daemon: activity on: Dec 26 03:20:45 ldap-server slapd[4306]: Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=8 active_threads=0 tvp=zero Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=9 active_threads=0 tvp=zero Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=10 active_threads=0 tvp=zero Dec 26 03:20:45 ldap-server slapd[4306]: connection_read(18): input error=-2 id=2799347, closing. Dec 26 03:20:45 ldap-server slapd[4306]: connection_closing: readying conn=2799347 sd=18 for close Dec 26 03:20:45 ldap-server slapd[4306]: daemon: removing 18 Dec 26 03:20:45 ldap-server slapd[4306]: conn=2799347 fd=18 closed (connection lost) Dec 26 03:20:45 ldap-server slapd[4306]: daemon: activity on 1 descriptor Dec 26 03:20:45 ldap-server slapd[4306]: daemon: activity on: Dec 26 03:20:45 ldap-server slapd[4306]: Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=8 active_threads=0 tvp=zero Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=9 active_threads=0 tvp=zero Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=10 active_threads=0 tvp=zero Dec 26 03:20:46 ldap-server slapd[4306]: daemon: activity on 1 descriptor Dec 26 03:20:46 ldap-server slapd[4306]: daemon: activity on: Dec 26 03:20:46 ldap-server slapd[4306]: 15r Dec 26 03:20:46 ldap-server slapd[4306]: Dec 26 03:20:46 ldap-server slapd[4306]: daemon: read active on 15 Dec 26 03:20:46 ldap-server slapd[4306]: daemon: epoll: listen=8 active_threads=0 tvp=zero Dec 26 03:20:46 ldap-server slapd[4306]: daemon: epoll: listen=9 active_threads=0 tvp=zero Dec 26 03:20:46 ldap-server slapd[4306]: daemon: epoll: listen=10 active_threads=0 tvp=zero Dec 26 03:20:46 ldap-server slapd[4306]: conn=2799050 op=3 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=root))" Dec 26 03:20:46 ldap-server slapd[4306]: ber_flush2 failed errno=32 reason="Broken pipe" Dec 26 03:20:46 ldap-server slapd[4306]: connection_closing: readying conn=2799050 sd=15 for close Dec 26 03:20:46 ldap-server slapd[4306]: send_ldap_response: ber write failed Dec 26 03:20:46 ldap-server slapd[4306]: conn=2799050 op=3 SEARCH RESULT tag=101 err=0 nentries=0 text= Dec 26 03:20:46 ldap-server slapd[4306]: connection_resched: attempting closing conn=2799050 sd=15 Dec 26 03:20:46 ldap-server slapd[4306]: daemon: removing 15 Dec 26 03:20:46 ldap-server slapd[4306]: conn=2799050 fd=15 closed (connection lost on write)

3 3

ITS#8928 - SOURCE_DATE_EPOCH (was: OpenLDAP 2.4.47 available)
by Michael Ströder 19 Dec '18

19 Dec '18

On 12/19/18 5:51 PM, OpenLDAP Project wrote: > Added slapd reproducible build support (ITS#8928) What would be an appropriate value for SOURCE_DATE_EPOCH to be chosen when packaging OpenLDAP? Ciao, Michael.

2 2

RE24 testing call (2.4.47) LMDB RE0.9 testing call (0.9.23)
by Quanah Gibson-Mount 19 Dec '18

19 Dec '18

2.4.47 is now believed to be ready for release after tracking down a deadlock and a few other replication issues. Please test. :) Generally, get the code for RE24: <http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/h…> Configure & build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. Thanks! OpenLDAP 2.4.47 Engineering Added slapd-sock DN qualifier for subtrees to be processed (ITS#8051) Added slapd-sock ability to send extended operations to external listeners (ITS#8714) Fixed liblber to avoid incremental access to user-supplied bv in dupbv (ITS#8752) Fixed libldap dn to domain parsing with bad input (ITS#8842) Fixed slapd slapcat to correctly honor -g option (ITS#8667) Fixed slapd to correctly handle NO_SUCH_OBJECT with dynamic groups (ITS#8923) Fixed slapd to check status of rdnNormalize (ITS#8932) Fixed slapd cn=config when modifying slapo-syncprov config (ITS#8616) Fixed slapd sasl authz-policy "all" behavior (ITS#8909) Fixed slapd sasl minor typo (ITS#8918) Fixed slapd to correctly hide hidden DBs in the rootDSE (ITS#8912) Fixed slapd domainScope control to match Microsoft specification (ITS#8840) Fixed slapd-bdb/hdb/mdb to not convert certain IDLs to ranges (ITS#8868) Fixed slapo-accesslog deadlock during cleanup (ITS#8752) Fixed slapo-memberof cn=config modifications (ITS#8663) Fixed slapo-ppolicy with multimaster replication (ITS#8927) Fixed slapo-syncprov with NULL modlist (ITS#8843) Build Environment Fixed missing includes with OpenSSL 1.0.2 (ITS#8809) Contrib Fixed slapo-pbkdf2 hash generation (ITS#8878) Documentation admin24 fixed minor typo (ITS#8887) LMDB 0.9.23 Engineering ITS#8756 Fix loose pages in dirty list ITS#8831 Fix mdb_load flag init ITS#8844 Fix mdb_env_close in forked process Documentation ITS#8857 mdb_cursor_del doesn't invalidate cursor ITS#8908 GET_MULTIPLE etc don't change passed in key Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

5 10

ldap user authentication, PAM and chsh (change shell): how to make it work?
by Jean-Francois Malouin 17 Dec '18

17 Dec '18

Hi, Please, bear with me! I know that this is not an openldap question per se, but I've been banging my head on the wall for a long time on this issue and maybe someone knows the quick answer: with user authentication coming from LDAP, what is the magic that has to inserted with the PAM stuff on a client to allow users to change their login shells using 'chsh'? I've been googling this for hours to no avail. I nice hint would just suffice. I'm using libnss-ldap along with pam-ldap on Ubuntu and Debian clients. I managed to make the 'passwd' command to work using the libnss-ldap configuration 'pam_password exop' directive but I'm clueless with chsh... Right now I'm getting messages chsh: user 'luser' does not exist in /etc/passwd and the system auth logs tells me: chsh[4638]: pam_unix(chsh:auth): authentication failure; logname=luser uid=1137 euid=0 tty= ruser= rhost= user=luser /etc/pam.d/chsh originally contained, once the @include included: auth required pam_shells.so auth sufficient pam_rootok.so auth [success=2 default=ignore] pam_unix.so nullok_secure auth [success=1 default=ignore] pam_ldap.so use_first_pass auth requisite pam_deny.so auth required pam_permit.so auth optional pam_cap.so account [success=2 new_authtok_reqd=done default=ignore] pam_unix.so account [success=1 default=ignore] pam_ldap.so account requisite pam_deny.so account required pam_permit.so session [default=1] pam_permit.so session requisite pam_deny.so session required pam_permit.so session optional pam_umask.so session required pam_unix.so session optional pam_ldap.so session optional pam_systemd.so I tried to trim it down -- removing the account and session entries but to no avail so far... thanks, jf

5 11

Antw: Re: fast delete a lot of entries
by Ulrich Windl 17 Dec '18

17 Dec '18

>>> Derek Zhou <derek(a)shannon-data.com> schrieb am 14.12.2018 um 07:27 in Nachricht <4351992.5iqGPAtjck@speedy>: > On Thursday, December 13, 2018 05:24:53 PM Derek Zhou wrote: >> Howard and others: >> >> Again on deleting lots of entries. I have 2 experiments: >> >> 1, in a fresh db insert 10 million entries. let's call this state A. then > delete 9 million entries over night. let's call this state B >> 2, in a fresh db insert 1 million entries I call this state B' >> >> In B and B' even the 1 million entries are the same; so from user's > perspective B and B' are indistinguishable. However, deleting entries from B > is much slower than deleting entries from B', like 10x slower. It seems like > deleting speed depends on the peak db size, and how full the db currently is. > >> >> My question is: is this wide a deletion performance gap expected? >> > Further testing shows that this deletion speed drop only happens in writemap > mode. default mode is much better. When you are that deep into analyzing (assuming you use Linux), it wmight be interesting to run blocktrace to see how your filesystem is accessed. (Once I did that for our database server, and you could clearly see accesses to the redo logs as well as the effects of fsync) [...] Regards, Ulrich

1 0

Q: "deferring operation: too many executing" / "deferring operation: pending operations"
by Ulrich Windl 17 Dec '18

17 Dec '18

Hi! I have a question for the following log messages: slapd[2215]: connection_input: conn=144871 deferring operation: too many executing slapd[2215]: connection_input: conn=144871 deferring operation: pending operations slapd[2215]: connection_input: conn=144871 deferring operation: pending operations What is "too many", i.e. where is that limit configured? Is it possible to tell how many "pending operations" there are? Finally: It seems slapd "drives against the wall hard", meaning it runs at full speed until the limit is reached, the refuses any more connection/operation. Is it possible to activate (configure) a "soft knee" behavior, where after reaching a specified limit of connections or operations rate slapd starts responding increasingly slower? That would help load balancers to select a different server in time... Regards, Ulrich

3 3

ldap_oc_mappings | keycol of type varchar
by Thangavel, Parameswaran 16 Dec '18

16 Dec '18

Hi, While exploring the OpenLDAP's backend-sql package, I found below behavior. The ldap_oc_mappings expects the keycol to be of type integer. For example, if I change the datatype of the identifier (id) of persons table to of type varchar then I am not able to retrieve the persons record during LDAP requests. However, if the column "id" is of type Integer then I am able to view the persons record as part of LDAP search requests. insert into ldap_oc_mappings (id,name,keytbl,keycol,create_proc,delete_proc,expect_return) values (2,'inetOrgPerson','persons','id',NULL,NULL,0); insert into persons (id,name,surname,password) values ('a21qec','Mitya','Kovalev','mit'); Question: 1) Is my observation correct? i.e the keycol used to map the LDAP entries to SQL data expects the primary key (id) to be of type integer. 2) If #1 is correct, do we have a way to support VARCHAR datatype for the primary key? In my application, we use GUID (alpha-numeric characters) as the primary key. Please advise. Thanks Param

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical