openldap-technical

openldap-technical@openldap.org

1 participants
9898 discussions

Debian getting rid of nis and adding rfc2307bis
by malcolm moore 27 Jun '18

27 Jun '18

Are there any instructions for this anywhere ? I've been seaching and struggling now for several days and I can't work out how to do it. It can't be as difficult as i am making it Ta Mal

2 1

Re: OPenLDAP instances frequently crashes
by Saurabh Lahoti 25 Jun '18

25 Jun '18

Dear, Just before crash below message logged into system logs of servers: Jun 11 23:01:37 musang kernel: Out of memory: Kill process 22184 (slapd) score 888 or sacrifice child Jun 11 23:01:37 musang kernel: Killed process 22184, UID 0, (slapd) total-vm:52226320kB, anon-rss:37170216kB, file-rss:1044kB Although, my physical RAM size is 38 GB & actual database size is 32 GB. Why is it not managing memory appropriately with the help from swap...? ---- *Thanks & Kind Regards,* Saurabh LAHOTI. On Wed, 13 Jun 2018 at 15:57, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Wednesday, June 13, 2018 8:56 AM +0200 Michael Ströder > <michael(a)stroeder.com> wrote: > > > On 06/12/2018 06:15 AM, Saurabh Lahoti wrote: > >> Frequently, our OpenLDAP instances crashes thereby leading us into > severe > >> disastrous results & outages for business. > >> > >> While going through slapd logs, it always says " bdb_db_open: database: > >> unclean shutdown detected; attempting recovery" > >> > >> What could possibly go wrong here..? > > > > Which OpenLDAP version are you using? Which OS? > > What does openldap log before it crashes? > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

3 2

Meta backend and attributes mapping
by ROY Grégory 22 Jun '18

22 Jun '18

Hello, I try somehow to do what I explain below. But without success... I think I'm doing badly for the attribute mapping, maybe it would be better with the rwm overlay? Could someone put me on the right track? -> I have this : ---------------------------------------------------------------------------------------------------------------------------------------------------- dc=domain1,dc=local dc=domain2, dc=local |__ou=users |__ou= apps |__ou=standard |__ou= app1 |__cn = JOHN DOE | |__cn = DOEJOHN |__ att: sAMAccountName= DOEJOHN | |__att: Appval=valuex |__att: phonenumber=0102030405 |__ou= app2 |__cn= DOEJOHN |__att: Appval=valuey ---------------------------------------------------------------------------------------------------------------------------------------------------- -> and i wan't to do this : ---------------------------------------------------------------------------------------------------------------------------------------------------- dc=meta,dc=local |_ou=users |_cn= DOEJOHN |_att: phonenumber=0102030405 |_att: App1val=valuex |_att: App2val=valuey ---------------------------------------------------------------------------------------------------------------------------------------------------- -> I do it this way, with the meta backend : ---------------------------------------------------------------------------------------------------------------------------------------------------- ######################################################################### defaultsearchbase dc=meta,dc=local ### database META ##################################################### database meta suffix dc=meta,dc=local rootdn "cn=admin,dc=meta,dc=local" rootpw secret ## AD1 USERS ### uri "ldap://ad.domain1.local:389/ou=users,dc=meta,dc=local" suffixmassage "ou=users,dc=meta,dc=local" "ou=users,ou=standard,dc=domain1,dc=local" idassert-bind bindmethod=simple binddn="CN=reader,DC=domain1,DC=local" credentials="password" mode=self idassert-authzFrom "dn.regex:.*" access to * by * read map attribute uid sAMAccountname ## AD2 APP 1 ############### uri "ldap://ad.domain2.local:389/ou=users,dc=meta,dc=local" suffixmassage "ou=users,dc=meta,dc=local" "ou=app1,ou=apps,dc=domain2,dc=local" idassert-bind bindmethod=simple binddn="CN=reader,DC=domain2,DC=local" credentials="password" mode=self idassert-authzFrom "dn.regex:.*" access to * by * read map attribute uid cn map attribute App1val Appval ## AD2 APP 2 ############### uri "ldap://ad.domain2.local:389/ou=users,dc=meta,dc=local" suffixmassage "ou=users,dc=meta,dc=local" "ou=app2,ou=apps,dc=domain2,dc=local" idassert-bind bindmethod=simple binddn="CN=reader,DC=domain2,DC=local" credentials="password" mode=self idassert-authzFrom "dn.regex:.*" access to * by * read map attribute uid cn map attribute App2val Appval lastmod off ---------------------------------------------------------------------------------------------------------------------------------------------------- I get this result, and it does not really correspond to what I want to get .... : ---------------------------------------------------------------------------------------------------------------------------------------------------- [root@server openldap]# ldapsearch -x "uid=DOEJOHN" -H 'ldap://localhost/' -b dc=meta,dc=local -LLL phonenumber App1val App2val dn: cn=JOHN DOE,ou=users,dc=meta,dc=local phonenumber: 0102030405 dn: cn=DOEJOHN,ou=users,dc=meta,dc=local App1val: valuex dn: cn=DOEJOHN,ou=users,dc=meta,dc=local App2val: valuey ---------------------------------------------------------------------------------------------------------------------------------------------------- Regards, -- Greg

2 2

warning about rootdn privileges
by Chris Hoogendyk 21 Jun '18

21 Jun '18

When one's Google Foo fails, turn to an appropriate list. I would like to get rid of these warnings (rootdn is always granted unlimited privileges). First, it's annoying that our cron always spits back an email. Second, one assumes that where there is a warning, there might be something that should be done differently. I've tried searching, but it seems this warning always comes up in conjunction with some other error that someone is concerned about. This particular warning is always ignored in the discussion of the error of concern as far as I have been able to find. 5b2472a5 /usr/local/etc/openldap/slapd.conf: line 170: rootdn is always granted unlimited privileges. 5b2472a5 /usr/local/etc/openldap/slapd.conf: line 293: rootdn is always granted unlimited privileges. 5b2472a5 hdb_monitor_db_open: monitoring disabled; configure monitor database to enable 5b2472a5 /usr/local/etc/openldap/slapd.conf: line 170: rootdn is always granted unlimited privileges. 5b2472a5 /usr/local/etc/openldap/slapd.conf: line 293: rootdn is always granted unlimited privileges. 5b2472a5 hdb_monitor_db_open: monitoring disabled; configure monitor database to enable I don't think I need to include anything about my slapd.conf, because this is more a general question of what causes this warning, and what is the recommended guidance for avoiding it. -- --------------- Chris Hoogendyk - O__ ---- Systems Administrator c/ /'_ --- Biology & Geosciences Departments (*) \(*) -- 315 Morrill Science Center ~~~~~~~~~~ - University of Massachusetts, Amherst <hoogendyk(a)bio.umass.edu> --------------- Erdös 4

2 2

About the bdb and hdb backends
by JC 20 Jun '18

20 Jun '18

I am a bit confused about the bdb and hdb backends. My understanding is that the former is based on the Berkeley database, whereas the latter uses an Oracle version of Berkeley database. In my slapd.conf configuration file there is an entry that specifies that bdb, not hdb, is to be used. However, when launching slapd, it attempts to use hdb_db_open(). Why would that be the case?

2 1

master/slave sync stops working
by Kai Wiechers 17 Jun '18

17 Jun '18

Hi List, I have trouble with my fresh setup openLDAP Master/Slave sync. The slave stops syncing every few hours with the message shown below. If I restart the slave things start working again. I monitored the network connectivity between th hosts and there is no issue with that. Debug output running slapd -d 256 -d 128 5b23c9dc do_syncrep2: rid=001 (-1) Can't contact LDAP server 5b23c9dc do_syncrepl: rid=001 rc -1 retrying (4 retries left) /var/log/syslog: Jun 15 16:14:52 ldap-server slapd[5178]: do_syncrep2: rid=001 (-1) Can't contact LDAP server Jun 15 16:14:52 ldap-server slapd[5178]: do_syncrepl: rid=001 rc -1 retrying (4 retries left) I'm running Ubuntu 16.04.4 openLDAP 2.4.42 (from Ubuntu repository) on both servers. I setup the sync using these LDIF files on master: dn: olcDatabase={1}mdb,cn=config changetype: modify delete: olcAccess olcAccess: {0} - add: olcAccess olcAccess: {0}to attrs=userPassword,shadowLastChange by dn="cn=admin,dc=domain,dc=com" write by dn="cn=replicator,dc=domain,dc=com" write by self write by anonymous auth by * none - delete: olcAccess olcAccess: {2} - add: olcAccess olcAccess: {2}to * by dn="cn=admin,dc=domain,dc=com" manage by dn="cn=replicator,dc=domain,dc=com" manage by self write by anonymous auth by users read dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: syncprov.la dn: olcDatabase={1}mdb,cn=config changetype: modify add: olcDbIndex olcDbIndex: entryUUID,entryCSN eq dn: olcOverlay=syncprov,olcDatabase={1}mdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov On the Slave I imported these LDIF files: dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: syncprov.la dn: olcDatabase={1}mdb,cn=config changetype: modify add: olcDbIndex olcDbIndex: entryUUID,entryCSN eq dn: olcDatabase={1}mdb,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=ldap://ldap-master.domain.com/ bindmethod=simple binddn="cn=replicator,dc=domain,dc=com" credentials=PASSWORD searchbase="dc=domain,dc=com" scope=sub schemachecking=on type=refreshAndPersist retry="30 5 300 3" interval=00:00:00:30 starttls=yes tls_reqcert=allow I'm really new to openLDAP so please let me know how to provide additional Info if you need them. Thanks and best regards, Kai

1 0

master/slave sync stops working
by Kai Wiechers 15 Jun '18

15 Jun '18

Hi List, I have trouble with my fresh setup openLDAP Master/Slave sync. The slave stops syncing every few hours with the message shown below. If I restart the slave things start working again. I monitored the network connectivity between th hosts and there is no issue with that. Debug output running slapd -d 256 -d 128 5b23c9dc do_syncrep2: rid=001 (-1) Can't contact LDAP server 5b23c9dc do_syncrepl: rid=001 rc -1 retrying (4 retries left) /var/log/syslog Jun 15 16:14:52 ldap-server slapd[5178]: do_syncrep2: rid=001 (-1) Can't contact LDAP server Jun 15 16:14:52 ldap-server slapd[5178]: do_syncrepl: rid=001 rc -1 retrying (4 retries left) I'm running Ubuntu 16.04.4 openLDAP 2.4.42 (from Ubuntu repository) on both servers. I setup the sync using these LDIFs on the master. |dn: olcDatabase={||1||}mdb,cn=config| |changetype: modify| |delete: olcAccess| |olcAccess: {||0||}| |-| |add: olcAccess| |olcAccess: {||0||}to attrs=userPassword,shadowLastChange| | ||by dn=||"cn=admin,dc=domain,dc=com"| |write| | ||by dn=||"cn=replicator,dc=domain,dc=com"| |write| | ||by self write| | ||by anonymous auth| | ||by * none| |-| |delete: olcAccess| |olcAccess: {||2||}| |-| |add: olcAccess| |olcAccess: {||2||}to *| | ||by dn=||"cn=admin,dc=domain,dc=com"| |manage| | ||by dn=||"cn=replicator,dc=domain,dc=com"| |manage| | ||by self write| | ||by anonymous auth| | ||by users read| |dn: cn=module{||0||},cn=config| |changetype: modify| |add: olcModuleLoad| |olcModuleLoad: syncprov.la <https://confluence.2rioffice.com/display/SA/syncprov.la>| |dn: olcDatabase={||1||}mdb,cn=config| |changetype: modify| |add: olcDbIndex| |olcDbIndex: entryUUID,entryCSN eq| |dn: olcOverlay=syncprov,olcDatabase={||1||}mdb,cn=config| |changetype: add| |objectClass: olcOverlayConfig| |objectClass: olcSyncProvConfig| |olcOverlay: syncprov| On the Slave I imported these LDIFs |dn: cn=module{||0||},cn=config| |changetype: modify| |add: olcModuleLoad| |olcModuleLoad: syncprov.la <https://confluence.2rioffice.com/display/SA/syncprov.la>| |dn: olcDatabase={||1||}mdb,cn=config| |changetype: modify| |add: olcDbIndex| |olcDbIndex: entryUUID,entryCSN eq| |dn: olcDatabase={||1||}mdb,cn=config| |changetype: modify| |add: olcSyncRepl| |olcSyncRepl: rid=||001| | ||provider=ldap:||//ldap-master.domain.com/ <https://confluence.2rioffice.com/display/SA/ldap-grev-ham-de.2rioffice.com/>| | ||bindmethod=simple| | ||binddn=||"cn=replicator,dc=domain,dc=com"| | ||credentials=PASSWORD| | ||searchbase=||"dc=domain,dc=com"| | ||scope=sub| | ||schemachecking=on| | ||type=refreshAndPersist| | ||retry=||"30 5 300 3"| | ||interval=||00||:||00||:||00||:||30| | ||starttls=yes| | ||tls_reqcert=allow| I'm really new to openLDAP so please let me know how to provide additional Info if you need them. Thanks and best regards, Kai

1 0

monitoring response queue (was: (ITS#8852) slapd memory use grows..)
by Michael Ströder 15 Jun '18

15 Jun '18

On 05/19/2018 08:18 AM, hyc(a)symas.com wrote: > I've run your reproducer and see no memory leak. The response queue will > indeed grow without bound if the consumer runs slower than the provider, and > doesn't read responses fast enough. But in the case of this test script, > eventually the client finishes and the consumer catches up. How to monitor this response queue? The reason I'm asking: I see memory growth on customer's Æ-DIR providers and I'd like to track down the reason for it eventually by excluding other possible causes. Ciao, Michael.

2 1

olcDBMap error
by w.turner＠mailoo.org 14 Jun '18

14 Jun '18

Hello, I am trying to update my LDAAP configuration to use cn=config. For this, I have converted my slapd.config file to a cn=config using the the slaptest command. After it had finished converting, the terminal showed multiple times the following line: warning, source attributeType 'olcDBMap:value #x' should be defined in schema Do I need to add a specific schema for this attribute ?

1 0

Re: OPenLDAP instances frequently crashes
by Saurabh Lahoti 13 Jun '18

13 Jun '18

Dear, Firstly, would like to sincerely extend my gratitude for illustrative explanation & clarity on slapd instability problem. Indeed, your correlations with our symptoms truly solves this jigsaw puzzle. To conclude on this discussion, does OS flavor affects the slapd operations & management. Earlier we were on Solaris & recently moved to RHEL. And we had ensure exact replica of Solaris is taken into RHEL with CPU, RAM, HDD & other system parameters. On Solaris our LDAP environment was pretty much quiet & stable. It was this migration post which we started encountering memory problem & instability of instances. Kindly suggest your advice.. ---- *Thanks & Kind Regards,* Saurabh LAHOTI. On Wed, 13 Jun 2018 at 22:57, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Wednesday, June 13, 2018 11:30 PM +0200 Saurabh Lahoti > <saurabh.astronomy(a)gmail.com> wrote: > > > Jun 11 23:01:37 musang kernel: Out of memory: Kill process 22184 (slapd) > > score 888 or sacrifice child > > Jun 11 23:01:37 musang kernel: Killed process 22184, UID 0, (slapd) > > total-vm:52226320kB, anon-rss:37170216kB, file-rss:1044kB > > This is not slapd crashing. This is linux OOM deciding to kill slapd for > you because your system ran out of memory, and slapd was the last thing to > ask for more memory. The total memory requirements for slapd are not > limited to just what's stored in the database. And, given that you're > using back-bdb or back-hdb, the memory requirements are significantly > higher than the size of the DB, as slapd has to have multiple caches (at > least 3) to help overcome performance issues in BDB (dncache, idlcache, > entrycache). > > Add more memory. Better, yet, ensure you are running the latest version > of > OpenLDAP and switch to back-mdb, which has significantly smaller memory > requirements than back-bdb/hdb. > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

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