openldap-technical August 2009

openldap-technical@openldap.org

65 participants
73 discussions

Re: Cleaning slapcat(1) LDIF output
by masarati＠aero.polimi.it 14 Aug '09

14 Aug '09

Please keep replies to the list. >> Please carefully re-read the above text: "IT IS ALWAYS SAFE TO RUN >> SLAPCAT >> WITH THE SLAPD-BDB(5) BACKEND". > > Piero, > > I think I'm missing something but the question stills here: ¿is possible > to use slapcat(8) on the fly (which means with slapd running)? > Maybe the text you've quoted means: stop the slapd service and runs > slapcat(8) directly against bdb. You see, there's a first sentence, which states that it might not be always safe to run slapcat while slapd is running, as results might be inconsistent. Then there is a second sentence, stating that it is always safe when slapcat is used for slapd-bdb. So the answer is: yes, it is safe. p.

1 0

Re: OpenLDAP + Kerberos on FreeBSD 7.2, close to working but not quite
by Allan 13 Aug '09

13 Aug '09

Thank you for the response. I ran the command and it looks like there's none supported.. This is strange. How can I allow GSSAPI? frisbee# /usr/local/bin/ldapsearch -x -H ldap://localhost -b "" -s base supportedSaslMechanisms # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: supportedSaslMechanisms # # dn: # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 On Mon, Aug 10, 2009 at 9:29 AM, <cr4z3d(a)gmail.com> wrote: > I apologize for that it was early in the morning. Gmail likes to reply to > sender > ------Original Message------ > From: Dieter Kluenter > To: Allan > Subject: Re: OpenLDAP + Kerberos on FreeBSD 7.2, close to working but not > quite > Sent: Aug 10, 2009 8:46 AM > > Please no private mail, stay on the mailinglist, unless you want to > buy my professional support. > > -Dieter > > Allan <cr4z3d(a)gmail.com> writes: > > > Thank you for the response. I ran the command and it looks like there's > none > > supported.. This is strange. How can I allow GSSAPI? > > > > frisbee# /usr/local/bin/ldapsearch -x -H ldap://localhost -b "" -s base > > supportedSaslMechanisms > > # extended LDIF > > # > > # LDAPv3 > > # base <> with scope baseObject > > # filter: (objectclass=*) > > # requesting: supportedSaslMechanisms > > # > > > > # > > dn: > > > > # search result > > search: 2 > > result: 0 Success > > > > # numResponses: 2 > > # numEntries: 1 > > > -- > Dieter Klünter | Systemberatung > http://dkluenter.de > GPG Key ID:8EF7B6C6 > 53°08'09,95"N > 10°08'02,42"E > >

3 11

Re: Just organizationalUnits objects copied doing sync replication
by Yeray Gutiérrez Cedrés 13 Aug '09

13 Aug '09

On Wed, Aug 12, 2009 at 11:40 PM, Quanah Gibson-Mount<quanah(a)zimbra.com> wrote: > --On Wednesday, August 12, 2009 11:17 PM +0100 Yeray Gutiérrez Cedrés > <ycedres(a)gmail.com> wrote: > >> I'm trying to replicate an openldap database from a consumer like this: >> >> index objectClass,entryCSN,entryUUID eq >> overlay syncprov >> syncprov-checkpoint 100 10 >> syncprov-sessionlog 100 >> >> >> To a provider like this: >> >> >> index objectClass,entryCSN,entryUUID eq >> >> syncrepl rid=123 >> provider=ldap://10.140.200.3:389 >> type=refreshOnly >> interval=00:00:00:01 >> searchbase="dc=example,dc=org" >> scope=sub >> attrs="*" >> schemachecking=off >> bindmethod=simple >> binddn="cn=admin,dc=example,dc=org" >> credentials="mypassword" >> >> The provider database is completely emtpy and I want the provider to >> copy the whole database. The only objects that are copied are the >> organizationalUnit class objects. The objects that are "under" the >> organizationalUnits (like for example a 'person' objetct) are not >> being copied. What could be the reason for that? > > > I think you are confused about the differences between "provider" and > "consumer". The provider is what starts with the full database. The > consumer is what gets the database from the provider. So the provider does > *not* copy the database, the consumer does. > I'm sorry for mixing my e-mail up a little bit. I read it three times before sending but at certain hours your brain doesn't work as you expect :-). > In any case, your "attrs" line is wrong. You really shouldn't set it at all > and just use the default unless you really know what you're doing. > Well I tried first leaving those lines at their default value. According to the openldap documentation: "The scope defaults to sub, the filter defaults to (objectclass=*), attrs defaults to "*,+" to replicate all user and operational attributes, and attrsonly is unset by default." I try this in the consumer: syncrepl rid=123 provider=ldap://10.140.209.254:389 type=refreshOnly interval=00:00:00:01 searchbase="dc=example,dc=org" schemachecking=off bindmethod=simple binddn="cn=admin,dc=example,dc=org" credentials="secret" Then I check the slapd.con file: # slaptest /etc/ldap/slapd.conf: line 152: rootdn is always granted unlimited privileges. /etc/ldap/slapd.conf: line 174: rootdn is always granted unlimited privileges. config file testing succeeded Then I restart: # /etc/init.d/slapd restart I see this in the logfile slapd[22700]: slapd starting slapd[22700]: syncrepl_entry: rid=123 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) slapd[22700]: syncrepl_entry: rid=123 inserted UUID ead90d7a-c02b-102c-8c00-cb58049f9ef6 slapd[22700]: syncrepl_entry: rid=123 be_search (32) slapd[22700]: syncrepl_entry: rid=123 dc=example,dc=org slapd[22700]: syncrepl_entry: rid=123 be_add (0) If does the same for "cn=admin,dc=example,dc=org", "ou=users,dc=example,dc=org", "ou=groups,dc=groups,dc=org","ou=postfix,dc=example,dc=org", "ou=alias,ou=postfix,dc=example,dc=org","cn=vmail,ou=groups,dc=example,dc=org" and finally I get this message: slapd[22700]: syncrepl_message_to_entry: rid=123 mods check (objectClass: value #0 invalid per syntax) slapd[22700]: do_syncrepl: rid=123 quitting When I try with ldapsearch (from the consumer to the provider, the provider IP is 10.140.200.3): # ldapsearch -D "cn=admin,dc=example,dc=org" -W -x -h 10.140.200.3 objectClass=* attr=*,+ it does return all entries: # numResponses: 705 # numEntries: 704 As additional information, when I do slapcat, I get this (apart from the objects that were created before, as I said): dn: objectClass: top objectClass: dcObject objectClass: organization o: corp.example.org dn: objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin I think this objects are there as a result of starting slapd in the first moment with a wrong configuration file (for example, the suffix line was incorrectly set to corp.example.com insted of example.com). But I don't know how to delete those entries. And I also don't know if this is affecting to the correct behaviour of the replication. > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

1 1

Just organizationalUnits objects copied doing sync replication
by Yeray Gutiérrez Cedrés 12 Aug '09

12 Aug '09

I'm trying to replicate an openldap database from a consumer like this: index objectClass,entryCSN,entryUUID eq overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 To a provider like this: index objectClass,entryCSN,entryUUID eq syncrepl rid=123 provider=ldap://10.140.200.3:389 type=refreshOnly interval=00:00:00:01 searchbase="dc=example,dc=org" scope=sub attrs="*" schemachecking=off bindmethod=simple binddn="cn=admin,dc=example,dc=org" credentials="mypassword" The provider database is completely emtpy and I want the provider to copy the whole database. The only objects that are copied are the organizationalUnit class objects. The objects that are "under" the organizationalUnits (like for example a 'person' objetct) are not being copied. What could be the reason for that? Regards.

2 1

syncrepl findbase failed! 32 errors
by Barry Colston 12 Aug '09

12 Aug '09

I'm running OpenLDAP 2.4.17 with 3 servers configured in multi-master mode (server 1 replicates to server 2 and server 3, server 2 replicates to server 1 and server 3, and server 3 replicates to server 1 and server 2). While executing shell scripts to test replication, all 3 slapd instances began returning error code 32 to all requests. No information could be retrieved from any of the 3 LDAP servers using ldapsearch, Apache Directory Studio, LDAP Administrator tool, or the LDAP Browser tool. The slapd log records with debug level = sync contained numerous "findbase failed! 32" errors. Starting and restarting the slapd instances still resulted in error code 32 being returned for any LDAP request. I had to restore the LDAP databases to be able to view/update records in any of the 3 LDAP databases. Server 1 configuration snippet: overlay syncprov syncprov-checkpoint 100 15 syncprov-sessionlog 5000 syncrepl rid=001 provider=ldap://localhost:3892 type=refreshAndPersist retry="60 60 300 +" searchbase="dc=authentx" scope=sub schemachecking=off bindmethod=simple binddn="cn=xroot,dc=authentx" credentials="980170contact" syncrepl rid=002 provider=ldap://localhost:3893 type=refreshAndPersist retry="60 60 300 +" searchbase="dc=authentx" scope=sub schemachecking=off bindmethod=simple binddn="cn=xroot,dc=authentx" credentials="980170contact" mirrormode on Server 2 configuration snippet: overlay syncprov syncprov-checkpoint 100 15 syncprov-sessionlog 5000 syncrepl rid=001 provider=ldap://localhost:3891 type=refreshAndPersist retry="60 60 300 +" searchbase="dc=authentx" scope=sub schemachecking=off bindmethod=simple binddn="cn=xroot,dc=authentx" credentials="980170contact" syncrepl rid=002 provider=ldap://localhost:3893 type=refreshAndPersist retry="60 60 300 +" searchbase="dc=authentx" scope=sub schemachecking=off bindmethod=simple binddn="cn=xroot,dc=authentx" credentials="980170contact" mirrormode on Server 3 configuration snippet: overlay syncprov syncprov-checkpoint 100 15 syncprov-sessionlog 5000 syncrepl rid=001 provider=ldap://localhost:3891 type=refreshAndPersist retry="60 60 300 +" searchbase="dc=authentx" scope=sub schemachecking=off bindmethod=simple binddn="cn=xroot,dc=authentx" credentials="980170contact" syncrepl rid=002 provider=ldap://localhost:3892 type=refreshAndPersist retry="60 60 300 +" searchbase="dc=authentx" scope=sub schemachecking=off bindmethod=simple binddn="cn=xroot,dc=authentx" credentials="980170contact" mirrormode on Snippets from log file from server 1 around the slapd error 32 problem time: syncprov_sendresp: to=002, cookie=rid=001,sid=001,csn=20090811143737.466654Z#000000#001#000000 syncprov_sendresp: to=003, cookie=rid=001,sid=001,csn=20090811143737.466654Z#000000#001#000000 slap_queue_csn: queing 0xa2452d98 20090811143737.567781Z#000000#001#000000 syncprov_sendresp: to=002, cookie=rid=001,sid=001,csn=20090811143737.567781Z#000000#001#000000 slap_graduate_commit_csn: removing 0xa17098a8 20090811143737.567781Z#000000#001#000000 syncprov_sendresp: to=003, cookie=rid=001,sid=001,csn=20090811143737.567781Z#000000#001#000000 findbase failed! 32 findbase failed! 32 findbase failed! 32 findbase failed! 32 findbase failed! 32 findbase failed! 32 findbase failed! 32 findbase failed! 32 findbase failed! 32 findbase failed! 32 findbase failed! 32 findbase failed! 32 findbase failed! 32 findbase failed! 32 findbase failed! 32 findbase failed! 32 connection_input: conn=456 deferring operation: binding findbase failed! 32 findbase failed! 32 findbase failed! 32 findbase failed! 32 findbase failed! 32 findbase failed! 32 connection_input: conn=461 deferring operation: binding Snippets from log file from server 2 around the slapd error 32 problem time: slap_queue_csn: queing 0xa1709520 20090811143737.567781Z#000000#001#000000 slap_graduate_commit_csn: removing 0xa1709650 20090811143737.567781Z#000000#001#000000 syncrepl_updateCookie: rid=001 be_modify failed (32) do_syncrepl: rid=001 rc 32 retrying (59 retries left) syncprov_sendresp: to=003, cookie=rid=002,sid=002,csn=20090811143737.567781Z#000000#001#000000 do_syncrep2: cookie=rid=002,sid=003,csn=20090811143737.567781Z#000000#001#000000 syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_DELETE) syncrepl_entry: rid=002 be_search (32) syncrepl_entry: rid=002 (null) slap_queue_csn: queing 0xa1714320 20090811143737.567781Z#000000#001#000000 slap_graduate_commit_csn: removing 0xa1716558 20090811143737.567781Z#000000#001#000000 do_syncrepl: rid=002 rc 32 retrying (59 retries left) findbase failed! 32 do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT (32) No such object do_syncrep2: rid=001 (32) No such object do_syncrepl: rid=001 rc -2 retrying (59 retries left) do_syncrep2: rid=002 LDAP_RES_SEARCH_RESULT do_syncrep2: rid=002 LDAP_RES_SEARCH_RESULT (32) No such object do_syncrep2: rid=002 (32) No such object do_syncrepl: rid=002 rc -2 retrying (59 retries left) findbase failed! 32 Snippets from log file from server 3 around the slapd error 32 problem time: slap_graduate_commit_csn: removing 0x835e498 20090811143737.466654Z#000000#001#000000 do_syncrep2: cookie=rid=001,sid=001,csn=20090811143737.567781Z#000000#001#000000 syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_DELETE) syncrepl_entry: rid=001 be_search (0) syncrepl_entry: rid=001 dc=authentx slap_queue_csn: queing 0xa160ee80 20090811143737.567781Z#000000#001#000000 syncprov_matchops: skipping original sid 001 slap_graduate_commit_csn: removing 0xa16134f8 20090811143737.567781Z#000000#001#000000 syncrepl_entry: rid=001 be_delete dc=authentx (0) slap_queue_csn: queing 0xa160ee80 20090811143737.567781Z#000000#001#000000 slap_graduate_commit_csn: removing 0xa16134f8 20090811143737.567781Z#000000#001#000000 syncrepl_updateCookie: rid=001 be_modify failed (32) do_syncrepl: rid=001 rc 32 retrying (59 retries left) syncprov_sendresp: to=002, cookie=rid=002,sid=003,csn=20090811143737.567781Z#000000#001#000000 do_syncrep2: cookie=rid=002,sid=002,csn=20090811143737.567781Z#000000#001#000000 syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_DELETE) syncrepl_entry: rid=002 be_search (32) syncrepl_entry: rid=002 (null) slap_queue_csn: queing 0x8338688 20090811143737.567781Z#000000#001#000000 slap_graduate_commit_csn: removing 0x8360318 20090811143737.567781Z#000000#001#000000 do_syncrepl: rid=002 rc 32 retrying (59 retries left) do_syncrep2: rid=002 LDAP_RES_SEARCH_RESULT do_syncrep2: rid=002 LDAP_RES_SEARCH_RESULT (32) No such object do_syncrep2: rid=002 (32) No such object do_syncrepl: rid=002 rc -2 retrying (59 retries left) findbase failed! 32 I have been unable to reproduce this problem. Any suggestions on how to prevent this problem from occurring and how to recover when this problem occurs? Thanks, Barry Colston

2 3

Changing the top object
by Yeray Gutiérrez Cedrés 12 Aug '09

12 Aug '09

In the slapd.conf file of a provider server I have the following suffix parameter: suffix "dc=example,dc=org" And with slapcat I see the followind: dn: dc=example,dc=org objectClass: top objectClass: dcObject objectClass: organization o: example.org dc: example structuralObjectClass: organization entryUUID: ead90d7a-c02b-102c-8c00-cb58049f9ef6 creatorsName: modifiersName: createTimestamp: 20080527112930Z modifyTimestamp: 20080527112930Z entryCSN: 20080527112930.000000Z#000000#000#000000 I wanted to set a consumer but I set the suffix parameter wrong: suffix "dc=corp,dc=example,dc=org" So this was created: dn: objectClass: top objectClass: dcObject objectClass: organization o: corp.example.org dc: corp structuralObjectClass: organization entryUUID: 29af5532-1abb-102e-9f19-896497a83f9b creatorsName: createTimestamp: 20090811120636Z entryCSN: 20090811120636.425151Z#000000#000#000000 modifiersName: modifyTimestamp: 20090811120636Z Is there any way to change this? I also don't know why the dn in the second case is empty (I thought it should be dc=corp,dc=example,dc=org). If this can't be easily fixed, is there any way of starting from scratch? Regards.

4 13

RE: syncrepl findbase failed! 32 errors
by Quanah Gibson-Mount 12 Aug '09

12 Aug '09

--On Wednesday, August 12, 2009 3:29 PM -0400 Barry Colston <bcolston(a)xtec.com> wrote: > BDB 4.6.21. I'm checking with the person who built BDB/LDAP to see what > patches have been applied. > Please keep replies on the list, thanks. :) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

unique
by Márcio Luciano Donada 12 Aug '09

12 Aug '09

Hi, Currently I'm using the unique to the mail, but I would also add other attributes, is this possible? overlay unique unique_uri ldap:///?mail?sub? -- Márcio Luciano Donada <mdonada at auroraalimentos dot com dot br> Aurora Alimentos - Cooperativa Central Oeste Catarinense Departamento de T.I.

2 1

Entry not listed when requesting all entries with ldapsearch
by Yeray Gutiérrez Cedrés 12 Aug '09

12 Aug '09

I've added a new entry with ldapadd like this: I've got this in a file (myfile.ldif): dn: mail=someone(a)example.com,ou=alias,ou=postfix,dc=example,dc=com cn: Mr Someone mail: someone(a)example.com maildrop: someone(a)corporative.example.com sn: Boss objectClass: CourierMailAlias objectClass: person objectClass: top objectClass: inetOrgPerson $>ldapadd -D "cn=admin,dc=example,dc=com" -w secret -x -h "localhost" -f myfile.ldif I can see it if I search specifically for it with ldapsearch (no problem with this): $> ldapsearch -x -b "mail=someone(a)example.com,ou=alias,ou=postfix,dc=example,dc=com" # extended LDIF # # LDAPv3 # base <mail=someone(a)example.com,ou=alias,ou=postfix,dc=example,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # someone(a)example.com, alias, postfix, someone.com dn: mail=someone(a)example.com,ou=alias,ou=postfix,dc=someone,dc=com cn: Mr Someone mail: someone(a)example.com sn: Boss objectClass: CourierMailAlias objectClass: person objectClass: top objectClass: inetOrgPerson maildrop: someone(a)corporative.example.com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Howerver, when I try to search for this entry with ldapsearch I can't see it if I list all the entries: $> ldapsearch -x -b "ou=alias,ou=postfix,dc=example,dc=com" | grep "someone" $> I have some other entries that were previously there and they are all listed. It's very extrange that in the complete list the new etnry doesn't get listed. Any idea? Regards.

2 1

openldap 2.4.16, rwm, syncrepl
by mkappe 12 Aug '09

12 Aug '09

Hello everybody, I'm front a problem with my openldap 2.4.16 server and i hope you can give me help to solve it. The problem is the following one: I use a schema for email addresses but i need to make it compliant with another one. I found some matching fields from my current model to the other one but i wouldn't like to duplicate them or define a schema for the new model. I tried to use rwm module in this way: include /usr/local/../schema/core.schema include /usr/local/../schema/cosine.schema include /usr/local/../schema/inetorgperson.schema include /usr/local/../schema/my_email.schema ... ... database bdb suffix "dc=mydomain,dc=it" rootdn "cn=manager,dc=mydomain,dc=it" rootpw xxxxxx directory /openldap/data/mydomain index objectClass,uid eq index entryCSN eq index entryUUId eq overlay rwm rwm-map attribute myemail theNewEmail rwm-map attribute mypassword theNewPassword ... Searching for theNewEmail in dc=mydomain,dc=it nothing appears. What do i wrong? Another question: are there any problem if i use rwm overlay in a delta-syncrepl mode? Thank you! M.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical August 2009