openldap-technical

openldap-technical@openldap.org

1 participants
9989 discussions

slapindex with mdb
by Marco Schirrmeister 12 Sep '12

12 Sep '12

Hi, when I run slapindex with my mdb backend the data.mdb files grows and grows and when the configured maxsize (100GB) is reached it stops with cannot allocate memory. 50505d1e => mdb_idl_insert_keys: c_put id failed: Cannot allocate memory (12) 50505d1e => mdb_tool_entry_reindex: txn_aborted! err=80 To test, I created a very basic config. See below. Created a test ldif file with the LDIFGen.jar with 100000 DNs. The file is 110MB. In the slapd.conf is only 1 index configured. uid with eq,sub. When I load this file with slapadd the data.mdb file gets 268MB. (Without any configured index 220MB) When I then run a slapindex, the data.mdb grows to 20GB. If I add 2 more attributes to index. data.mdb gets 36GB index givenname eq,sub index sn eq,sub My question is, is this normal? Why does the data file get's so big with a slapindex and not with a slapadd? OpenLDAP version is 2.4.32 on CentOS6 64bit. # cat /etc/openldap2.4/slapd.conf include /usr/share/openldap2.4/schema/core.schema include /usr/share/openldap2.4/schema/cosine.schema include /usr/share/openldap2.4/schema/corba.schema include /usr/share/openldap2.4/schema/inetorgperson.schema include /usr/share/openldap2.4/schema/java.schema include /usr/share/openldap2.4/schema/krb5-kdc.schema include /usr/share/openldap2.4/schema/kerberosobject.schema include /usr/share/openldap2.4/schema/misc.schema include /usr/share/openldap2.4/schema/nis.schema include /usr/share/openldap2.4/schema/openldap.schema include /usr/share/openldap2.4/schema/autofs.schema pidfile /var/run/ldap2.4/slapd.pid argsfile /var/run/ldap2.4/slapd.args modulepath /usr/lib64/oldap24/openldap2.4 moduleload back_monitor.la moduleload accesslog.la moduleload syncprov.la moduleload auditlog.la loglevel stats serverID 40 ldap://ds71.ogilvy.com database mdb suffix "dc=ogilvy,dc=com" rootdn "cn=manager,dc=ogilvy,dc=com" rootpw secret directory /var/lib/ldap2.4/ogilvy.com limits dn.exact="cn=manager,dc=ogilvy,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited sizelimit 90000 checkpoint 256 5 dbnosync maxsize 104857600000 index uid eq,sub monitoring on database config rootdn "cn=admin,cn=config" rootpw secret database monitor rootdn cn=monitor rootpw secret -- Marco

2 1

ACL entry creation restricted to objectClass
by deepee＠gmx.net 12 Sep '12

12 Sep '12

Hi, is it possible to restrict the creation of an entry to a specific objectClass? If so, any hint or assistance would be very welcome. Thank you very much! Background information follows here: The attrs "@person" within the following acl statement seems to have no effect (during creation). It seems to me attrs=entry already is granting access to "all values" (of all kind of attributes?): ----------------------- #slapd version: HEAD (also REL_ENG_2_4) ----------------------- #acl: access to dn.base="dc=example,dc=org" attrs=children by users write access to dn.one="dc=example,dc=org" attrs=entry,@person by users write by anonymous auth ----------------------- #ldapmodify -x -H "ldap://localhost:333/" -D "uid=user,dc=example,dc=org" -w user -f /tmp/example_operation.ldif ----------------------- #/tmp/example_operation.ldif: #add a person entry: dn: cn=hello,dc=example,dc=org changetype: add objectClass: person objectClass: top cn: hello sn: hello userPassword: hello #add an account entry: dn: cn=world,dc=example,dc=org changetype: add objectClass: device objectClass: top cn:world serialNumber: 1 #both operation do succeed, see log below ----------------------- #log (level 128): 5050a940 => access_allowed: result not in cache (userPassword) 5050a940 => access_allowed: auth access to "uid=user,dc=example,dc=org" "userPassword" requested 5050a940 => dn: [1] dc=example,dc=org 5050a940 => dn: [2] dc=example,dc=org 5050a940 => acl_get: [2] matched 5050a940 => acl_get: [2] attr userPassword 5050a940 => acl_mask: access to entry "uid=user,dc=example,dc=org", attr "userPassword" requested 5050a940 => acl_mask: to value by "", (=0) 5050a940 <= check a_dn_pat: users 5050a940 <= check a_dn_pat: anonymous 5050a940 <= acl_mask: [2] applying auth(=xd) (stop) 5050a940 <= acl_mask: [2] mask: auth(=xd) 5050a940 => slap_access_allowed: auth access granted by auth(=xd) 5050a940 => access_allowed: auth access granted by auth(=xd) 5050a940 => access_allowed: add access to "dc=example,dc=org" "children" requested 5050a940 => dn: [1] dc=example,dc=org 5050a940 => acl_get: [1] matched 5050a940 => acl_get: [1] attr children 5050a940 => acl_mask: access to entry "dc=example,dc=org", attr "children" requested 5050a940 => acl_mask: to all values by "uid=user,dc=example,dc=org", (=0) 5050a940 <= check a_dn_pat: users 5050a940 <= acl_mask: [1] applying write(=wrscxd) (stop) 5050a940 <= acl_mask: [1] mask: write(=wrscxd) 5050a940 => slap_access_allowed: add access granted by write(=wrscxd) 5050a940 => access_allowed: add access granted by write(=wrscxd) 5050a940 => access_allowed: add access to "cn=hello,dc=example,dc=org" "entry" requested 5050a940 => dn: [1] dc=example,dc=org 5050a940 => dn: [2] dc=example,dc=org 5050a940 => acl_get: [2] matched 5050a940 => acl_get: [2] attr entry 5050a940 => acl_mask: access to entry "cn=hello,dc=example,dc=org", attr "entry" requested 5050a940 => acl_mask: to all values by "uid=user,dc=example,dc=org", (=0) 5050a940 <= check a_dn_pat: users 5050a940 <= acl_mask: [1] applying write(=wrscxd) (stop) 5050a940 <= acl_mask: [1] mask: write(=wrscxd) 5050a940 => slap_access_allowed: add access granted by write(=wrscxd) 5050a940 => access_allowed: add access granted by write(=wrscxd) 5050a940 => access_allowed: add access to "dc=example,dc=org" "children" requested 5050a940 => dn: [1] dc=example,dc=org 5050a940 => acl_get: [1] matched 5050a940 => acl_get: [1] attr children 5050a940 => acl_mask: access to entry "dc=example,dc=org", attr "children" requested 5050a940 => acl_mask: to all values by "uid=user,dc=example,dc=org", (=0) 5050a940 <= check a_dn_pat: users 5050a940 <= acl_mask: [1] applying write(=wrscxd) (stop) 5050a940 <= acl_mask: [1] mask: write(=wrscxd) 5050a940 => slap_access_allowed: add access granted by write(=wrscxd) 5050a940 => access_allowed: add access granted by write(=wrscxd) 5050a940 => access_allowed: add access to "cn=world,dc=example,dc=org" "entry" requested 5050a940 => dn: [1] dc=example,dc=org 5050a940 => dn: [2] dc=example,dc=org 5050a940 => acl_get: [2] matched 5050a940 => acl_get: [2] attr entry 5050a940 => acl_mask: access to entry "cn=world,dc=example,dc=org", attr "entry" requested 5050a940 => acl_mask: to all values by "uid=user,dc=example,dc=org", (=0) 5050a940 <= check a_dn_pat: users 5050a940 <= acl_mask: [1] applying write(=wrscxd) (stop) 5050a940 <= acl_mask: [1] mask: write(=wrscxd) 5050a940 => slap_access_allowed: add access granted by write(=wrscxd) 5050a940 => access_allowed: add access granted by write(=wrscxd)

2 1

pam_password exop
by teoman.onay＠degroof.be 12 Sep '12

12 Sep '12

Hi, Could you give me some more info on that parameter : pam_password exop All what i've found is this : The directive "pam_password exop" tells pam-ldap to change passwords in a way that allows OpenLDAP to apply the hashing algorithm specified in /etc/ldap/slapd.conf, instead of attempting to hash locally and write the result directly into the database. Does this mean that the password is sent clear to the ldap server then hashed over there ? It looks like a huge security flaw ... i've used tcpdump and unfortunately my password appears clearly ... using does imply enabling TLS ? Regards Teoman ONAY P before printing this email, think about the environment. ******************************************************************************* This e-mail is intended only for the person or entity to which it is addressed. It may contain confidential and/or privileged information. Any copying, disclosure, distribution or other use of the content of this e-mail by persons or entities other than the intended recipient is prohibited. Please contact immediately the sender if you have received this e-mail in error and delete it from all locations of your computer. The company on behalf of which the present e-mail is sent is validly committed only if the rules on the delegation of powers, as set out in the appropriate documents, have been complied with. Furthermore, due to the risks inherent to the use of the Internet, the company is not liable for the content of this e-mail if altered, changed or falsified. *******************************************************************************

4 6

HashCat for {CRYPT}
by Selcuk Yazar 12 Sep '12

12 Sep '12

Hi, Can ve decrypt OpenLDAP userpassword object values with HasCat ? i try with md5 hash type but it gaves line length exception oclHashcat-plus64.exe --hash-type 500 C:\hashcat\oclHashcat-plus\example500.hash C:\rockyou.txt C:\hashcat\oclHashcat-plus\example.dict thanks in advance -- Selçuk YAZAR

2 1

mdb - no space left?
by Frank Swasey 11 Sep '12

11 Sep '12

I'm experimenting with mdb to replace hdb on my test/development set of servers. I've built 2.4.32 and the server is running RHEL 6.3. This morning, I got a confusing error. Attempting to perform a deletion of a member from a groupOfNames, the following was recorded in syslog: mdb_id2entry_put: mdb_put failed: No space left on device(28) "cn=GroupNameNotImportant,ou=groups,dc=uvm,dc=edu" and ldapmodify returned: modifying entry "cn=GroupNameNotImportant,ou=Groups,dc=uvm,dc=edu" ldap_modify: Other (e.g., implementation specific) error (80) additional info: entry update failed However, free shows memory left, df shows filesystem space left (in fact, it is only 22% used) and data.mdb is -rw------- 1 ldap ldap 1547292672 Sep 8 06:22 data.mdb while the maxsize parameter is set to: maxsize 85899345920 So, I am confused about which device mdb is telling me is out of space. What have I missed? -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900)

4 5

OpenLdap Proxy with CentOS 6.3
by GERF 11 Sep '12

11 Sep '12

Hello all, I have been working with this project for a straight two weeks and i feel lost or stuck. The goal is to query Windows AD from the linux box located in the DMZ So, in my virtual lab I have the following: Windows AD with ip 172.16.5.16 ldap1.gerf02.local CentOS 6.3 with ip 172.16.5.32 upildap01.gerf02.local So, my configuration files are as follows: -*-*-*-*-*-*-*-*-*/etc/openldap/ldap.conf:-*-*-*-*-*-*-*-*-*-* BASE dc=gerf02,dc=local URI ldap://172.16.5.16 ldap://172.16.5.16:636 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never #TLS_CACERTDIR /etc/openldap/certs TLS_CACERTDIR /etc/pki/tls/certs/stratus_cert.pem *-*--**-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* *-*-*-*-*-*-**-*-*-*-/etc/sysconfig/ldap-*-*-*-*-*-*-*-*-*-*-*-*-*-* SLAPD_LDAP=yes SLAPD_LDAPI=yes SLAPD_LDAPS=yes -**-*-**-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-**-*-*-* -*-*-*-*-*-*-*-*-**-*/etc/openldap/slapd.d/cn=config/olcDatabase={2}bdb.ldif-*-*-*-*-*-*-*-*-*-*-*-*** dn: olcDatabase={2}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {2}bdb olcSuffix: dc=gerf02,dc=local olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=Ldap Bind Account,dc=gerf02,dc=local olcSyncUseSubentry: FALSE olcMonitoring: TRUE olcDbDirectory: /var/lib/ldap olcDbCacheSize: 1000 olcDbCheckpoint: 1024 15 olcDbNoSync: FALSE olcDbDirtyRead: FALSE olcDbIDLcacheSize: 0 olcDbIndex: objectClass pres,eq olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbIndex: uidNumber pres,eq olcDbIndex: gidNumber pres,eq olcDbIndex: ou pres,eq,sub olcDbIndex: loginShell pres,eq olcDbIndex: mail pres,eq,sub olcDbIndex: sn pres,eq,sub olcDbIndex: givenName pres,eq,sub olcDbIndex: memberUid pres,eq,sub olcDbIndex: nisMapName pres,eq,sub olcDbIndex: nisMapEntry pres,eq,sub olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbSearchStack: 16 olcDbShmKey: 0 olcDbCacheFree: 1 olcDbDNcacheSize: 0 structuralObjectClass: olcBdbConfig entryUUID: 0a5111d8-8f04-1031-8728-33c9f43311c7 creatorsName: cn=config createTimestamp: 20120909195524Z entryCSN: 20120909195524.946151Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20120909195524Z olcRootPW: {SSHA}2LzGLoDUm/iPav9Ijm/nLfAtxn9WndvP olcTLSCertificateFile: /etc/pki/tls/certs/stratus_cert.pem olcTLSCertificateKeyFile: /etc/pki/tls/certs/stratus_key.pem -**--**-*-*--*-*-*-**-*-*-*-*--*-*-*-**-*-**-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-***-** -**-*-*-*-*-*-*-*-**-/etc/openldap/slapd.d/cn=config/olcDatabase={1}monitor.ldif-*-*-*-*-*-*-*-***-*-* dn: olcDatabase={1}monitor objectClass: olcDatabaseConfig olcDatabase: {1}monitor olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=externa l,cn=auth" read by dn.base="cn=Ldap Bind Account,dc=gerf02,dc=local" read by * break olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcSyncUseSubentry: FALSE olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: 0a5108dc-8f04-1031-8727-33c9f43311c7 creatorsName: cn=config createTimestamp: 20120909195524Z entryCSN: 20120909195524.946151Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20120909195524Z -**--**-*-*--*-*-*-**-*-*-*-*--*-*-*-**-*-**-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-***-**-*-*---*-*-** So, when I execute the following, I get this message ldapsearch -x -b dc=gerf02,dc=local -D cn=Ldap Bind Account,dc=gerf02,dc=local -W Enter LDAP Password: ldap_bind: Invalid credentials (49) additional info: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1 Thanks for your help, G

2 3

Re: Execute a Filter and get the boolean status true/false
by Puneet Khunteta 10 Sep '12

10 Sep '12

Hello, Basically i need the count how many SearchResultEntry responses you get from ldap_search_s(). Note : Pardon, i have mistakenly typed "ldap_search()" instead of "ldap_search_s() "true/false for the particular filter" means following : 1.) If execute a filter , respond with >0 entry ---> true 2.) If execute a filter , respond with = 0 entry --> false. Note : i have nothing to do with the attributes for the corresponding entries return for the search. So i am looking for a optimized way here which just let me know if any entry is available or not for particular filter. Regards, PKHUN On Wed, Sep 5, 2012 at 11:17 PM, Pierangelo Masarati < pierangelo.masarati(a)polimi.it> wrote: > > > Hello, > > > > I am facing an issue to get the result of a filter. > > > > Currently i have used the ldap_search () function to see whether AD has > > some entity corresponding to particular filter execution. > > But i am not able to find the function which returns the number of > entity > > for the particular filter execution. > > Please help me to get the correct function which return the number of > > entity for the particular filter execution and what pre-requesties it > has. > > You need to count how many SearchResultEntry responses you get from > ldap_search(). Or, if slapd is configured to use the "noopsrch" module, > which implements the "noopsrch" control > <http://www.openldap.org/faq/data/cache/1509.html>, you get no results but > a control response that indicates, among other things, how many entries > would be returned by that search. I'm not sure what you mean by > "pre-requesties". > > > If possible, please suggest function which just return true/false for the > > particular filter. > > Please specify what "true/false for the particular filter" means. > > p. > > -- > Pierangelo Masarati > Associate Professor > Dipartimento di Ingegneria Aerospaziale > Politecnico di Milano > >

3 9

RE: OPENLDAP 2.4.32 INSTALLATION TEST ERRORS
by Quanah Gibson-Mount 10 Sep '12

10 Sep '12

--On Friday, September 07, 2012 4:16 PM -0400 "Borresen, John - 0442 - MITLL" <john.borresen(a)ll.mit.edu> wrote: > Thanks, Quanah; > > I just noticed that memberof is set to yes and refint is set to mod. I > could try both as yes, and see if it happens that way, too. That would be worth a test, thanks. Your configure is awfully odd. Why such a mix of modules and built in? I'd just do everything modular myself. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

3 2

Failing syncrepl connections because of an older contextCSN on the master
by Ivan Nejgebauer 10 Sep '12

10 Sep '12

OpenLDAP version(s): 2.4.32 and recent git master (54a111907b48900e1ce5de12a9d87818a334423d) OS: CentOS 5, 32-bit In a master/slave delta-syncrepl configuration, syncrepl connections from the fully synchronized and restarted slave to the freshly loaded master will fail because the master uses an earlier contextCSN. This state persists until the first modification on the master, when the contextCSN will become newer than the consumer's, whose next syncrepl retry will then succeed. Details (master and slave configurations are attached to this message): The master is freshly loaded with the following LDIF: dn: dc=example,dc=com objectClass: locality objectClass: dcObject dc: example dn: ou=People,dc=example,dc=com objectClass: organizationalUnit ou: People When the master is started, there is only one entry in cn=accesslog: dn: cn=accesslog objectClass: auditContainer cn: accesslog structuralObjectClass: auditContainer entryDN: cn=accesslog subschemaSubentry: cn=Subschema contextCSN: 20120910091205.088888Z#000000#000#000000 hasSubordinates: FALSE The root entry of the main database looks like this: dn: dc=example,dc=com objectClass: locality objectClass: dcObject dc: example structuralObjectClass: locality entryUUID: 921f3734-24fc-4efa-ac52-10aa4d293332 creatorsName: cn=Manager,dc=example,dc=com createTimestamp: 20120910090757Z entryCSN: 20120910090757.483217Z#000000#000#000000 modifiersName: cn=Manager,dc=example,dc=com modifyTimestamp: 20120910090757Z entryDN: dc=example,dc=com subschemaSubentry: cn=Subschema auditContext: cn=accesslog contextCSN: 20120910091205.089003Z#000000#000#000000 hasSubordinates: TRUE When the slave server (with an empty database) is started, it connects to the master and synchronizes. Their synchronization dialog, captured with -d sync, looks like this: (master) 504db377 syncprov_search_response: cookie=rid=000,csn=20120910091205.089003Z#000000#000#000000 504db377 syncprov_search_response: cookie=rid=000,csn=20120910091205.088888Z#000000#000#000000 (slave) 504db370 syncrepl_message_to_entry: rid=000 DN: dc=example,dc=com, UUID: 921f3734-24fc-4efa-ac52-10aa4d293332 504db370 syncrepl_entry: rid=000 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) 504db370 syncrepl_entry: rid=000 inserted UUID 921f3734-24fc-4efa-ac52-10aa4d293332 504db370 syncrepl_entry: rid=000 be_search (32) 504db370 syncrepl_entry: rid=000 dc=example,dc=com 504db370 syncrepl_entry: rid=000 be_add dc=example,dc=com (0) 504db370 syncrepl_message_to_entry: rid=000 DN: ou=People,dc=example,dc=com, UUID: 08fe53fb-724a-4eca-a57e-3c271d99dd7e 504db370 syncrepl_entry: rid=000 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) 504db370 syncrepl_entry: rid=000 inserted UUID 08fe53fb-724a-4eca-a57e-3c271d99dd7e 504db370 syncrepl_entry: rid=000 be_search (0) 504db370 syncrepl_entry: rid=000 ou=People,dc=example,dc=com 504db370 syncrepl_entry: rid=000 be_add ou=People,dc=example,dc=com (0) 504db370 do_syncrep2: rid=000 LDAP_RES_SEARCH_RESULT 504db370 do_syncrep2: rid=000 cookie=rid=000,csn=20120910091205.089003Z#000000#000#000000 504db370 slap_queue_csn: queing 0x836dcf8 20120910091205.089003Z#000000#000#000000 504db370 slap_graduate_commit_csn: removing 0x8371328 20120910091205.089003Z#000000#000#000000 504db370 do_syncrep2: rid=000 LDAP_RES_INTERMEDIATE - REFRESH_DELETE 504db370 do_syncrep2: rid=000 cookie=rid=000,csn=20120910091205.088888Z#000000#000#000000 The master sends the cookie with the contextCSN belonging to cn=accesslog. If the slave is now restarted, what happens is this: 504db38d do_syncrep2: rid=000 LDAP_RES_SEARCH_RESULT 504db38d do_syncrep2: rid=000 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform 504db38d do_syncrep2: rid=000 (53) Server is unwilling to perform 504db38d do_syncrepl: rid=000 rc -2 retrying The slave sends csn=20120910091205.089003Z#000000#000#000000, but the master uses csn=20120910091205.088888Z#000000#000#000000. When the master is subsequently modified, it will use a newer contextCSN, and the slave's next retry will succeed. Is this worthy of an ITS, since the situation is unlikely to occur in practice, and will correct itself, only leaving the slave out of sync for the duration of the retry interval? i. include ../servers/slapd/schema/core.schema argsfile master/run/slapd.args pidfile master/run/slapd.pid database mdb suffix cn=accesslog directory master/accesslog index entryCSN,objectClass,reqEnd,reqResult,reqStart eq overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE database mdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw secret maxsize 256000000 directory master/main index objectClass eq index entryCSN,entryUUID eq overlay syncprov syncprov-checkpoint 1000 60 overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE logpurge 07+00:00 01+00:00 include ../servers/slapd/schema/core.schema argsfile replica/run/slapd.args pidfile replica/run/slapd.pid database mdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw secret maxsize 256000000 directory replica/main index objectClass eq index entryUUID eq syncrepl rid=0 provider=ldap://localhost:6389/ bindmethod=simple binddn="cn=Manager,dc=example,dc=com" credentials=secret searchbase="dc=example,dc=com" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" syncdata=accesslog updateref "ldap://localhost:6389"

1 0

Object class violation/assertion when adding dynamic chaining configuration
by Ivan Nejgebauer 10 Sep '12

10 Sep '12

OpenLDAP version(s): 2.4.32 and recent git master (54a111907b48900e1ce5de12a9d87818a334423d) OS: CentOS 5, 32-bit While preparing the test cases for ITS#7381 (q.v.) I encountered two issues when trying to add an instance of olcLDAPConfig below the chaining overlay entry. If the instance entry looks like this... dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap ...adding the entry (with ldapadd) fails with Error 65 (Object class violation). The server logs the following: 504717ff slapd-chain: subsequent underlying database "olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config" must contain attribute "olcDbURI". 504717ff conn=1000 op=2: config_add_internal: DN="olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config" no structural objectClass add function Note that converting a minimal chaining configuration with slaptest generates an olcLDAPConfig entry without an olcDbURI, and that olcDbURI is not listed as a MUST attribute for olcLDAPConfig. Furthermore, if I try to add an olcLDAPConfig entry with an empty olcDbURI... dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbURI: "" ...it triggers an assertion: slapd: chain.c:224: ldap_chain_uri_cmp: Assertion `li2->li_bvuri != ((void *)0)' failed. Should I file an ITS for those two issues (or maybe two separate ITSs), or is this a "don't do that" scenario? i.

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical