openldap-software

openldap-software@openldap.org

2719 discussions

Large database initial replication problem
by Łukasz Wąsikowski 22 Oct '08

22 Oct '08

Welcome! I've got large test database (>20000 entries), set up replication using syncrepl (refreshAndPersist). It work's fine when consumer is connected to provider while importing all database. But when I add new consumer to use existing database only first 500 records are replicated. I know about sizelimit, but I don't want to raise it (because I don't know how big my database will grow). The question is - why consumer won't get rest of the entries in another queries? What am I doing wrong? I can't import all database everytime I connect new consumer in a production enviroment. -- Best regards, Lukasz Wasikowski

5 6

adding syncprov module fails
by Dieter Kluenter 21 Oct '08

21 Oct '08

Hi, I am trying to set up a cascading replication from scratch, adding syncprov module fails with: ,----[ output of slapd -dsync ] | @(#) $OpenLDAP: slapd 2.4.12 (Oct 17 2008 16:01:17) $ | dieter@rubin.l4b.de:/work/openldap-2.4.12/servers/slapd | slap_queue_csn: queing 0xa583f0 20081021122834.783484Z#000000#001#000000 | slap_graduate_commit_csn: removing 0xa578b0 20081021122834.783484Z#000000#001#000000 | slapd starting | slap_queue_csn: queing 0x40a70480 20081021122922.151442Z#000000#001#000000 | Control 1.3.6.1.4.1.4203.1.9.1.1 already registered. | syncprov_init: Failed to register control -9 | slap_graduate_commit_csn: removing 0xa52ef0 20081021122922.151442Z#000000#001#000000 `---- this is my script to load the module $LDAPMODIFY -x -D $ROOTDN -w $CPW -H $HOST <<EOF dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov EOF My initial slapd.conf is just ,----[ slapd.conf ] | include /opt/openldap-2.4/etc/openldap/schema/core.schema | include /opt/openldap-2.4/etc/openldap/schema/cosine.schema | include /opt/openldap-2.4/etc/openldap/schema/inetorgperson.schema | include /opt/openldap-2.4/etc/openldap/schema/nis.schema | | pidfile /opt/openldap-2.4/var/run/slapd.pid | argsfile /opt/openldap-2.4/var/run/slapd.args | | modulepath /opt/openldap-2.4/libexec/openldap | moduleload syncprov.la | | database config | rootdn "cn=config" | rootpw "xxx" `---- How come that the control is already registered? -Dieter -- Dieter Klünter | Systemberatung http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6 53°08'09,95"N 10°08'02,42"E

2 2

two issues with dyngroups
by Guillaume Rousse 21 Oct '08

21 Oct '08

Hello list. I'm an happy users of dynlist overlay, in order to make my unix users members of their unix primary group: # admins, groups, msr-inria.inria.fr dn: cn=admins,ou=groups,dc=msr-inria,dc=inria,dc=fr objectClass: groupOfURLs objectClass: posixGroup gidNumber: 5000 memberURL: ldap:///ou=users,dc=msr-inria,dc=inria,dc=fr??sub?(gidNumber=5000) cn: admins With this configuration: # dynamic groups overlay dynlist dynlist-attrset groupOfURLs memberURL member However, I'm facing two issues here. The first is that dynlist overlay only accept a single configuration directive for the whole base, preventing to map differently the request URL depending on the context. In my previous example, I need to map the URL as DN, because I'm dynamically building a group from users. If I wanted to build a group from other group, my URL would have been something as: ldap:///ou=group,dc=msr-inria,dc=inria,dc=fr?member?sub?(cn=users) and the configuration directive would have been instead dynlist-attrset groupOfURLs memberURL It would be nice to handle the overlay differently there. The second directive is that ACLs seems to ignore this dynamic group: # admins access to dn.subtree="dc=msr-inria,dc=inria,dc=fr" by group="cn=admins,ou=groups,dc=msr-inria,dc=inria,dc=fr" write by * break This worked with a static group, it doesn't work anymore with a dynamic one as I just presented. I'm using OpenLDAP 2.4.11. Should I open ITS for those issues ? -- Guillaume Rousse Moyens Informatiques - INRIA Futurs Tel: 01 69 35 69 62

2 3

Newbie question ldap_sasl_interactive_bind_s: Invalid credentials (49)
by Uli Kleemann 19 Oct '08

19 Oct '08

Hello my fellow openldap friends, I've installed openldap 2.4 on debian lenny usinf the Debian packages slapd and ldap-utils. For Authentification I would like to use sasl simple-bind but if I try e.g: ldapsearch -D "cn=admin,dc=lug-saar,dc=spc" -W -d 255 respectively ldapsearch -D "cn=Manager,dc=lug-saar,dc=de" -W -d 255 I got: ldap_sasl_interactive_bind_s: Invalid credentials (49) As I couldn't find the Error using google yet, but getting as more confused as more HOWTOS I read here is my ldap.conf: --------------------------------------------------------------------------------------------------------------------------------- # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. BASE dc=lug-saar,dc=de #URI ldap://ldap.lug-saar.de URI ldap://192.168.199.159 ldap_version 3 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never ------------------------------------------------------------------------------------------------------------------------------------ my slapd.conf ------------------------------------------------------------------------------------------------------------------------------------- # This is the main slapd configuration file. See slapd.conf(5) for more # info on the configuration options. ####################################################################### # Global Directives: # Features to permit #allow bind_v2 # Schema and objectClass definitions include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema # Where the pid file is put. The init.d script # will not stop the server if you change this. pidfile /var/run/slapd/slapd.pid # List of arguments that were passed to the server argsfile /var/run/slapd/slapd.args # Read slapd.conf(5) for possible values loglevel none # Where the dynamically loaded modules are stored modulepath /usr/lib/ldap moduleload back_hdb # The maximum number of entries that is returned for a search operation sizelimit 500 # The tool-threads parameter sets the actual amount of cpu's that is used # for indexing. tool-threads 1 # Specific Backend Directives for hdb: # Backend specific directives apply to this backend until another # 'backend' directive occurs backend hdb ####################################################################### # Specific Backend Directives for 'other': # Backend specific directives apply to this backend until another # 'backend' directive occurs #backend <other> ####################################################################### # Specific Directives for database #1, of type hdb: # Database specific directives apply to this databasse until another # 'database' directive occurs database hdb # The base of your directory in database #1 suffix "dc=lug-saar,dc=de" # rootdn directive for specifying a superuser on the database. This is needed # for syncrepl. rootdn "cn=root,dc=lug-saar,dc=de" rootpw secret rootpw {SSHA}Jh+[3]GpYm86f7E0ierBIQJhnN/gKmx # Where the database file are physically stored for database #1 directory "/var/lib/ldap" # The dbconfig settings are used to generate a DB_CONFIG file the first # time slapd starts. They do NOT override existing an existing DB_CONFIG # file. You should therefore change these settings in DB_CONFIG directly # or remove DB_CONFIG and restart slapd for changes to take effect. # For the Debian package we use 2MB as default but be sure to update this # value if you have plenty of RAM dbconfig set_cachesize 0 2097152 0 # Sven Hartge reported that he had to set this value incredibly high # to get slapd running at all. See http://bugs.debian.org/303057 for more # information. # Number of objects that can be locked at the same time. dbconfig set_lk_max_objects 1500 # Number of locks (both requested and granted) dbconfig set_lk_max_locks 1500 # Number of lockers dbconfig set_lk_max_lockers 1500 # Indexing options for database #1 index objectClass eq # Save the time that the entry gets modified, for database #1 lastmod on # Checkpoint the BerkeleyDB database periodically in case of system # failure and to speed slapd shutdown. checkpoint 512 30 # Where to store the replica logs for database #1 # replogfile /var/lib/ldap/replog # The userPassword by default can be changed # by the entry owning it if they are authenticated. # Others should not be able to see it, except the # admin entry below # These access lines apply to database #1 only access to attrs=userPassword,shadowLastChange by dn="cn=root,dc=lug-saar,dc=de" write by anonymous auth by self write by * none # Ensure read access to the base for things like # supportedSASLMechanisms. Without this you may # have problems with SASL not knowing what # mechanisms are available and the like. # Note that this is covered by the 'access to *' # ACL below too but if you change that as people # are wont to do you'll still need this if you # want SASL (and possible other things) to work # happily. access to dn.base="" by * read # The admin dn has full write access, everyone else # can read everything. access to * by dn="cn=root,dc=lug-saar,dc=de" write by * read # For Netscape Roaming support, each user gets a roaming # profile for which they have write access to #access to dn=".*,ou=Roaming,o=morsnet" # by dn="cn=root,dc=lug-saar,dc=de" write # by dnattr=owner write ####################################################################### # Specific Directives for database #2, of type 'other' (can be hdb too): # Database specific directives apply to this databasse until another # 'database' directive occurs #database <other> # The base of your directory for database #2 #suffix "dc=debian,dc=org" --------------------------------------------------------------------------------------------------------------------------------- The schema and ldif files I put into /etc/ldap/schema What did I do wrong? Thanks in advance. -- Uli Kleemann <uli.kleemann(a)guug.de> Note: No Microsoft programs were used in the creation or distribution of this message. If you are using a Microsoft program to view this message, be forewarned that I am not responsible for any harm you may encounter as a result.

5 6

Recording the Last Successful Authorization
by Tim Gustafson 17 Oct '08

17 Oct '08

I was wondering if there is any way to configure OpenLDAP to record the last time an account was successfully authorized? We need to be able to prune accounts after a period of inactivity, but there's no way right now to know if they user has been active or not. We can't base it on the last time they connected to a shell because not everyone uses shells; some people just authenticate to POP their e-mail or log into a web page. If there was some way to maintain a time stamp of the last time that that a user successfully authenticated (by way of an LDAP bind to the LDAP server) that would solve this problem. Thanks! Tim Gustafson SOE Webmaster UC Santa Cruz tjg(a)soe.ucsc.edu 831-459-5354

2 1

userCertificate;binary in a 2.3.X ldif file
by Brett ＠Google 17 Oct '08

17 Oct '08

Can anyone shed any light on : slapadd: could not parse entry (line=234) str2entry: attributeType userCertificate #0: needs ';binary' transfer as per syntax 1.3.6.1.4.1.1466.115.121.1.8 This is ocurring when running 2.4.x slapadd on a certificate containing a binary attribute, which was a slapcat from a 2.3.X openldap server. The attribute in question is already a binary attribute, there is a double colon after the certificate name, so i gather it just wants userCertificate;binary:: as the attribute name in the LDIF dump when loading ? Cant simply search and replace, because that will increase the line length, which will stop it from parsing. Alternatively, anybody know of any tool which can re-justify line lengths in an ldif, if i search and replace the attribute name ? It might be nice to have some sort of non-default legacy flag, for loading a previous release's ldif (or at least be more forgiving than the present parser) Cheers Brett

2 2

mysterious segfault
by Jason Dusek 17 Oct '08

17 Oct '08

I've added two seemingly innocuous lines to my LDAP configuration: Index: conf-root/etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif =================================================================== --- etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif (revision 1444) +++ etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif (working copy) @@ -1,6 +1,9 @@ dn: olcDatabase={1}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig +objectClass: olcSyncProvConfig +olcSpCheckpoint: 100 5 +olcSpSessionlog: 100 olcDatabase: {1}bdb olcSuffix: dc=metascopic,dc=com olcAccess: {0}to attrs=userPassword However, they cause `slaptest` to segfault on Linux! I'm a little perplexed by this. :; slaptest -F etc/openldap/slapd.d/ Segmentation fault Removing the lines restores `slaptest` to a state of sanity. -- _jsn

3 7

slapcat doesn't return correct error status for bdb fatal error
by Guillaume Rousse 17 Oct '08

17 Oct '08

[root@etoile ~]# slapcat -b dc=msr-inria,dc=inria,dc=fr ... bdb(dc=msr-inria,dc=inria,dc=fr): pthread lock failed: Invalid argument bdb(dc=msr-inria,dc=inria,dc=fr): PANIC: Invalid argument bdb(dc=msr-inria,dc=inria,dc=fr): PANIC: DB_RUNRECOVERY: Fatal error, run database recovery bdb(dc=msr-inria,dc=inria,dc=fr): PANIC: fatal region error detected; run recovery bdb_db_close: database "dc=msr-inria,dc=inria,dc=fr": close failed: DB_RUNRECOVERY: Fatal error, run database recovery (-30975) [root@etoile ~]# echo $? 0 It makes a bit difficult to know if slapcat-based backup were successful. -- Guillaume Rousse Moyens Informatiques - INRIA Futurs Tel: 01 69 35 69 62

2 2

Open LDAP 2.3.38 core dump when trying to add netgroup
by Eric Boehm 17 Oct '08

17 Oct '08

I am trying to create a minimal LDAP installation to test using LDAP for netgroups. My slapd.conf contains include /usr/local/openldap/etc/openldap/schema/core.schema include /usr/local/openldap/etc/openldap/schema/cosine.schema include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema include /usr/local/openldap/etc/openldap/schema/nis.schema include /usr/local/openldap/etc/openldap/schema/misc.schema pidfile /usr/local/openldap/var/run/slapd.pid argsfile /usr/local/openldap/var/run/slapd.args database bdb suffix "dc=nortel,dc=com" rootdn "cn=Manager,dc=nortel,dc=com" rootpw {SSHA}VszWHdlMt+txouAiBDwn0uKRII8OKzKc directory /usr/local/openldap/var/openldap-data index cn,sn pres,eq,approx,sub index objectClass eq I can add the following data without trouble dn: dc=nortel,dc=com objectClass: dcObject objectClass: organization dc: nortel o: Nortel description: Nortel Inc. dn: cn=Manager,dc=nortel,dc=com objectClass: organizationalRole cn: Manager description: Directory Manager dn: ou=Netgroup,dc=nortel,dc=com ou: Netgroup objectClass: top objectClass: organizationalUnit dn: nisMapName=netgroup.byuser,dc=nortel,dc=com nismapname: netgroup.byuser objectClass: top objectClass: nisMap dn: nisMapName=netgroup.byhost,dc=nortel,dc=com nismapname: netgroup.byhost objectClass: top objectClass: nisMap However, when I try to add dn: cn=sample,ou=netgroup,dc=nortel,dc=com objectclass: nisNetGroup objectclass: top cn: sample nisNetgroupTriple: (zrtps0q8,,) nisNetgroupTriple: (zrtps0q8.us.nortel.com,,) slapd dies and leaves a core dump I built slapd with debugging and when I bring it up in the debugger. It tells me t@5 (l@1) terminated by signal BUS (invalid address alignment) 0xffffffff7efd2f3c: __lock_get_internal+0x08ac: ldx [%l1 + 0x18], %l0 Current function is bdb_id2entry The source code line is 125 in id2entry.c rc = cursor->c_get( cursor, &key, &data, DB_SET ); I can't figure out what I am doing wrong. I tried to strip things down to the bare essentials. I suspect I haven't created the LDAP database properly but I am unable to determine what step or data I am missing. -- Eric M. Boehm /"\ ASCII Ribbon Campaign boehm(a)nortel.com \ / No HTML or RTF in mail X No proprietary word-processing Respect Open Standards / \ files in mail

2 2

debugging syncrepl issue
by Guillaume Rousse 17 Oct '08

17 Oct '08

Hello list. I'm facing a syncrepl issue really strange. Sofar, everytime I had sync issue, I just had to stop the consumer, delete its database, and restart it again to make it work. However, this time it seems unsufficient, and synchronisation hangs on some entries. In the consumer logs, with loglevel set to sync, starting with an empty base, I get lots of successfully synced entries: Oct 7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123 be_search (0) Oct 7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123 uid=test,ou=users,dc=msr-inria,dc=inria,dc=fr Oct 7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123 be_add (0) Oct 7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123 inserted UUID 86a10a62-ddf2-102c-9dfe-558a8530d5ee Then I get a warning for some strange entry: Oct 7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123 be_search (0) Oct 7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123 ou=kerberos,dc=msr-inria,dc=inria,dc=fr Oct 7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123 be_add (68) Oct 7 17:55:25 nation slapd[30453]: dn_callback : new entry is older than ours ou=kerberos,dc=msr-inria,dc=inria,dc=fr ours 20080704085717.749336Z#000000#000#000000, new 20080704085416.079377Z#000000#000#000000 Oct 7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123 entry unchanged, ignored (ou=kerberos,dc=msr-inria,dc=inria,dc=fr) Oct 7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123 inserted UUID 504ed75a-e374-102c-8faa-7b1baeea81b3 then additional successfully synced entries: Oct 7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123 be_search (0) Oct 7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123 uid=jabbour,ou=users,dc=msr-inria,dc=inria,dc=fr Oct 7 17:55:26 nation slapd[30453]: syncrepl_entry: rid=123 be_add (0) Oct 7 17:55:26 nation slapd[30453]: syncrepl_entry: rid=123 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 7 17:55:26 nation slapd[30453]: syncrepl_entry: rid=123 inserted UUID f516b45c-e38c-102c-8953-f71742eb083b And then something fails: Oct 7 17:55:26 nation slapd[30453]: do_syncrep2: rid=123 LDAP_RES_SEARCH_RESULT Oct 7 17:55:26 nation slapd[30453]: do_syncrep2: cookie=rid=123,csn=20081003163733.899132Z#000000#000#000000 Oct 7 17:55:26 nation slapd[30453]: slap_queue_csn: queing 0x846f858 20081003163733.899132Z#000000#000#000000 Oct 7 17:55:26 nation slapd[30453]: slap_graduate_commit_csn: removing 0x8471120 20081003163733.899132Z#000000#000#000000 Oct 7 17:55:26 nation slapd[30453]: do_syncrep2: cookie=rid=123,csn=20081006083018.748988Z#000000#000#000000 Oct 7 17:55:26 nation slapd[30453]: slap_queue_csn: queing 0x8386340 20081006083018.748988Z#000000#000#000000 Oct 7 17:55:26 nation slapd[30453]: slap_graduate_commit_csn: removing 0x841ad98 20081006083018.748988Z#000000#000#000000 Oct 7 17:55:26 nation slapd[30453]: syncrepl_message_to_op: rid=123 be_modify uid=rousse,ou=users,dc=msr-inria,dc=inria,dc=fr (0) I'm unable to understand what's going wrong there. On provider's side, all I have is the warning for the entry with an apparent wrong timestamp: Oct 7 17:55:22 etoile slapd[32640]: syncprov_search_response: cookie=rid=123,csn=20081003163733.899132Z#000000#000#000000 Oct 7 17:55:26 etoile slapd[32640]: Entry reqStart=20081003163733.000015Z,cn=log CSN 20081003163733.899132Z#000000#000#000000 older or equal to ctx 20081003163733.899132Z#000000#000#000000 Oct 7 17:55:26 etoile slapd[32640]: syncprov_search_response: cookie=rid=123,csn=20081007080656.987198Z#000000#000#000000 I checked access permissions and limits for syncrepl user on provider side, everything is OK. I'm using OpenLDAP 2.4.11 on both sides. And here is my syncrepl configuration: syncrepl rid=123 provider=ldaps://ldap1.msr-inria.inria.fr type=refreshAndPersist retry="60 +" logbase="cn=log" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog searchbase="dc=msr-inria,dc=inria,dc=fr" scope=sub schemachecking=off bindmethod=simple binddn="cn=syncrepl,ou=roles,dc=msr-inria,dc=inria,dc=fr" credentials=XXXXX Any hint welcome. -- Guillaume Rousse Moyens Informatiques - INRIA Futurs Tel: 01 69 35 69 62

2 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software