openldap-technical

openldap-technical@openldap.org

9 participants
9866 discussions

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

Logging Region out of memory
by Scott Mayo 13 Jun '18

13 Jun '18

I just started getting this early this morning. I set this server up a number of years ago. I am getting ready to put a new one in place, but need to get this back up and going in the mean time. Openldap version is 2.4.12 /sbin/service ldap start Checking configuration files for slapd: [FAILED] Logging region out of memory; you may need to increase its size db_open(/var/lib/ldap/id2entry.bdb) failed: Cannot allocate memory (12). backend_startup_one: bi_db_open failed! (12) slap_startup failed (test would succeed using the -u switch) stale lock files may be present in /var/lib/ldap [WARNING] Any ideas on what I need to check there? Thanks. -- Scott Mayo - System Administrator Bloomfield Schools PH: 573-568-5669 FA: 573-568-4565

4 6

LDAP backend uri configuration option order
by Scott Koranda 13 Jun '18

13 Jun '18

Hi, In the LDAP backend manual (eg. 'man slapd-ldap') I read for the 'uri' configuration option "The URI list is space- or comma-separated. Whenever the server that responds is not the first one in the list, the list is rearranged and the responsive server is moved to the head, so that it will be first contacted the next time a connection needs to be created." Outside of updating the value for the 'uri' configuration option (more properly the 'olcDbURI' configuration option) or restarting slapd, is there any way to cause the ordering to return to the configured order once an unresponsive server again becomes responsive? Thanks, Scott K

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical