openldap-technical

openldap-technical@openldap.org

14 participants
9796 discussions

RE: Segmentation Fault appearing while doing the sync.-OpenLDAP 2.4.22
by masarati＠aero.polimi.it 19 May '10

19 May '10

> Thanks for the suggestion. > > No I didn't run the core with gdb. Please see <http://www.openldap.org/faq/data/cache/56.html>. In any case, you don't need sync_use_subentry, unless your database's suffix is "". > The owner of the files is root and I am running the slapd process with > root only. > > Have rearranged the directives in the config. Please check the attached. > But it is still throwing the same error. > > Can you please suggest on this? > > Rahul Manchanda > > GS Selfcare > Platform Build Team > > Tel: +91 02066018100 Extn: 6178 > SMTP: rahul.manchanda(a)bt.com > > Office: Sharda Center ,6th Floor Annex > Off Karve Road, Erandwana ,Pune-04 > > -----Original Message----- > From: Dieter Kluenter [mailto:dieter@dkluenter.de] > Sent: Wednesday, May 19, 2010 10:09 AM > To: Manchanda,RK,Rahul,DKE C > Cc: openldap-technical(a)openldap.org > Subject: Re: Segmentation Fault appearing while doing the sync.-OpenLDAP > 2.4.22 > > <rahul.manchanda(a)bt.com> writes: > >> Hi , >> >> I have added sync_use_subentry in the ldap configuration and it started >> throwing the core dump while performing the sync from other running >> server and >> stops the LDAP process. > > Did you run the core within gdb? >> >> Here is the error seen the in the debug logs. >> >> <= index_entry_add( 114, "ou=New NetIQ StAlbans / >> Glasgow,ou=ChartReports,ou= >> services,o=BT" ) success >> >> => entry_encode(0x00000072): ou=New NetIQ StAlbans / Glasgow,ou= >> ChartReports,ou=services,o=BT >> >> <= entry_encode(0x00000072): ou=New NetIQ StAlbans / Glasgow,ou= >> ChartReports,ou=services,o=BT >> >> bdb_add: added id=00000072 dn="ou=New NetIQ StAlbans / Glasgow,ou= >> ChartReports,ou=services,o=BT" >> >> send_ldap_result: conn=-1 op=0 p=0 >> >> send_ldap_result: err=0 matched="" text="" >> >> bdb_modify: cn=ldapsync,o=bt >> >> bdb_dn2entry("cn=ldapsync,o=bt") >> >> => bdb_dn2id("cn=ldapsync,o=bt") >> >> <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found >> (-30988) >> >> bdb_modify: dn2entry failed (-30988) > > who is running slapd and who is the owner of dn2id.bdb and dn2entry.bdb? > >> send_ldap_result: conn=-1 op=0 p=0 >> >> send_ldap_result: err=10 matched="o=BT" text="" > > error 10 indicates that the referral is not available. Error 10 is there because the internal modification can't find the entry it's looking for, thus tries to send a referral according to updateref. p. >> ./start_ldap.sh: line 3: 14900 Segmentation Fault (core dumped) >> /software >> /openldap2.4.22/libexec/slapd -f /software/openldap2.4.22/etc/openldap/ >> slapd.conf -h ldap://tardis02.nat.bt.com:489/ -d -1 >> >> Have attached the slapd.conf file. >> >> Could you please suggest? > > Your slapd.conf is completely bogus, don't mix global configuration > parameters with database specific parameters, and vice versa. Overlay > declarations have to follow all database configuration parameters. > > >> >> overlay syncprov >> syncprov-checkpoint 100 5 >> syncprov-sessionlog 100 >> >> sync_use_subentry TRUE > ^^^^^^^^^^^^^^^^^^^^^^^^ > > this is a database specific parameter > > >> # Index Definition > [...] > > Indices are database specific > >> ############################# >> ###### ACL definitions ###### >> ############################# > > ACL's are partly global and database specific > > -Dieter > > -- > Dieter KlÃŒnter | Systemberatung > sip: +49.40.20932173 > http://www.dpunkt.de/buecher/2104.html > GPG Key ID:8EF7B6C6 >

1 0

Segmentation Fault appearing while doing the sync.-OpenLDAP 2.4.22
by rahul.manchanda＠bt.com 19 May '10

19 May '10

Hi , I have added sync_use_subentry in the ldap configuration and it started throwing the core dump while performing the sync from other running server and stops the LDAP process. Here is the error seen the in the debug logs. <= index_entry_add( 114, "ou=New NetIQ StAlbans / Glasgow,ou=ChartReports,ou=services,o=BT" ) success => entry_encode(0x00000072): ou=New NetIQ StAlbans / Glasgow,ou=ChartReports,ou=services,o=BT <= entry_encode(0x00000072): ou=New NetIQ StAlbans / Glasgow,ou=ChartReports,ou=services,o=BT bdb_add: added id=00000072 dn="ou=New NetIQ StAlbans / Glasgow,ou=ChartReports,ou=services,o=BT" send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=0 matched="" text="" bdb_modify: cn=ldapsync,o=bt bdb_dn2entry("cn=ldapsync,o=bt") => bdb_dn2id("cn=ldapsync,o=bt") <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) bdb_modify: dn2entry failed (-30988) send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=10 matched="o=BT" text="" ./start_ldap.sh: line 3: 14900 Segmentation Fault (core dumped) /software/openldap2.4.22/libexec/slapd -f /software/openldap2.4.22/etc/openldap/slapd.conf -h ldap://tardis02.nat.bt.com:489/ -d -1 Have attached the slapd.conf file. Could you please suggest? Many Thanks in advance. Rahul Manchanda GS Selfcare Platform Build Team Tel: +91 02066018100 Extn: 6178 SMTP: rahul.manchanda(a)bt.com Office: Sharda Center ,6th Floor Annex Off Karve Road, Erandwana ,Pune-04

2 2

Problem with syncrepl and deletion on openldap 2.4.21
by Mark Cave-Ayland 19 May '10

19 May '10

Hi folks, We've been running the latest openldap stable on one of our client sites and have hit an issue earlier in the day with syncrepl changes not being propagated to all consumers. The live system is configured with one master and 4 slaves connected across various LAN/WAN links with all servers running 2.4.21, db-4.7 on RHEL4. Earlier in the day, we renamed a corrupted ou (that was accidentally created with hidden control characters) to ou=salvage. Since the slapd.conf backend on the master was set to "database bdb", this was done by cloning the data into a new ou=salvage and deleting the old version. This data was cleaned up by the client by copying from ou=salvage into its correct location, and then finally they attempted to delete the complete ou=salvage part of the tree. However, after the deletion phase we found that 2 of our slaves were inconsistent with the master. As an example, on one slave we noticed that one DN with cn=001901717 had not been deleted from ou=salvage. The relevant parts of the log on the master and slave look like this: master: May 17 12:35:08 master slapd[3692]: conn=222514 op=3089 SRCH attr=objectclass May 17 12:35:08 master slapd[3692]: conn=222514 op=3089 SEARCH RESULT tag=101 err=0 nentries=0 text= May 17 12:35:08 master slapd[3692]: conn=222514 op=3090 DEL dn="cn=001801489,ou=People,ou=salvage,ou=Access Groups,dc=client,dc=com" May 17 12:35:08 master slapd[3692]: slap_queue_csn: queing 0x824fee10 20100517113508.089178Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: syncprov_sendresp: cookie=rid=149,csn=20100517113508.089178Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: conn=222514 op=3090 RESULT tag=107 err=0 text= May 17 12:35:08 master slapd[3692]: slap_graduate_commit_csn: removing 0x82f2e250 20100517113508.089178Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: syncprov_sendresp: cookie=rid=107,csn=20100517113508.089178Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: syncprov_sendresp: cookie=rid=136,csn=20100517113508.089178Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: syncprov_sendresp: cookie=rid=103,csn=20100517113508.089178Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: syncprov_sendresp: cookie=rid=154,csn=20100517113508.089178Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: conn=222514 op=3091 SRCH base="cn=001800462,ou=People,ou=salvage,ou=Access Groups,dc=client,dc=com" scope=1 deref=2 filter="(objectClass=*)" May 17 12:35:08 master slapd[3692]: conn=222514 op=3091 SRCH attr=objectclass May 17 12:35:08 master slapd[3692]: conn=222514 op=3091 SEARCH RESULT tag=101 err=0 nentries=0 text= May 17 12:35:08 master slapd[3692]: conn=222514 op=3092 DEL dn="cn=001800462,ou=People,ou=salvage,ou=Access Groups,dc=client,dc=com" May 17 12:35:08 master slapd[3692]: slap_queue_csn: queing 0x8e151e10 20100517113508.144277Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: syncprov_sendresp: cookie=rid=149,csn=20100517113508.144277Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: conn=222514 op=3092 RESULT tag=107 err=0 text= May 17 12:35:08 master slapd[3692]: slap_graduate_commit_csn: removing 0x7d00cc58 20100517113508.144277Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: syncprov_sendresp: cookie=rid=107,csn=20100517113508.144277Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: syncprov_sendresp: cookie=rid=136,csn=20100517113508.144277Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: syncprov_sendresp: cookie=rid=103,csn=20100517113508.144277Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: syncprov_sendresp: cookie=rid=154,csn=20100517113508.144277Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: conn=222514 op=3093 SRCH base="cn=001801399,ou=People,ou=salvage,ou=Access Groups,dc=client,dc=com" scope=1 deref=2 filter="(objectClass=*)" May 17 12:35:08 master slapd[3692]: conn=222514 op=3093 SRCH attr=objectclass May 17 12:35:08 master slapd[3692]: conn=222514 op=3093 SEARCH RESULT tag=101 err=0 nentries=0 text= May 17 12:35:08 master slapd[3692]: conn=222514 op=3094 DEL dn="cn=001801399,ou=People,ou=salvage,ou=Access Groups,dc=client,dc=com" May 17 12:35:08 master slapd[3692]: slap_queue_csn: queing 0x8c6f6e10 20100517113508.192643Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: syncprov_sendresp: cookie=rid=149,csn=20100517113508.192643Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: conn=222514 op=3094 RESULT tag=107 err=0 text= May 17 12:35:08 master slapd[3692]: slap_graduate_commit_csn: removing 0x82588ca0 20100517113508.192643Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: syncprov_sendresp: cookie=rid=107,csn=20100517113508.192643Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: syncprov_sendresp: cookie=rid=136,csn=20100517113508.192643Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: syncprov_sendresp: cookie=rid=103,csn=20100517113508.192643Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: syncprov_sendresp: cookie=rid=154,csn=20100517113508.192643Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: conn=222514 op=3095 SRCH base="cn=001800467,ou=People,ou=salvage,ou=Access Groups,dc=client,dc=com" scope=1 deref=2 filter="(objectClass=*)" May 17 12:35:08 master slapd[3692]: conn=222514 op=3095 SRCH attr=objectclass May 17 12:35:08 master slapd[3692]: conn=222514 op=3095 SEARCH RESULT tag=101 err=0 nentries=0 text= May 17 12:35:08 master slapd[3692]: conn=222514 op=3096 DEL dn="cn=001800467,ou=People,ou=salvage,ou=Access Groups,dc=client,dc=com" May 17 12:35:08 master slapd[3692]: slap_queue_csn: queing 0x8cffae10 20100517113508.234887Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: syncprov_sendresp: cookie=rid=107,csn=20100517113508.234887Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: syncprov_sendresp: cookie=rid=136,csn=20100517113508.234887Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: syncprov_sendresp: cookie=rid=103,csn=20100517113508.234887Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: syncprov_sendresp: cookie=rid=154,csn=20100517113508.234887Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: syncprov_sendresp: cookie=rid=149,csn=20100517113508.234887Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: conn=222514 op=3096 RESULT tag=107 err=0 text= May 17 12:35:08 master slapd[3692]: slap_graduate_commit_csn: removing 0x7d802e90 20100517113508.234887Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: conn=222514 op=3097 SRCH base="cn=001901714,ou=People,ou=salvage,ou=Access Groups,dc=client,dc=com" scope=1 deref=2 filter="(objectClass=*)" May 17 12:35:08 master slapd[3692]: conn=222514 op=3097 SRCH attr=objectclass May 17 12:35:08 master slapd[3692]: conn=222514 op=3097 SEARCH RESULT tag=101 err=0 nentries=0 text= May 17 12:35:08 master slapd[3692]: conn=222514 op=3098 DEL dn="cn=001901714,ou=People,ou=salvage,ou=Access Groups,dc=client,dc=com" May 17 12:35:08 master slapd[3692]: slap_queue_csn: queing 0x87ef3e10 20100517113508.277430Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: syncprov_sendresp: cookie=rid=149,csn=20100517113508.277430Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: conn=222514 op=3098 RESULT tag=107 err=0 text= May 17 12:35:08 master slapd[3692]: slap_graduate_commit_csn: removing 0x7e95abe8 20100517113508.277430Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: syncprov_sendresp: cookie=rid=107,csn=20100517113508.277430Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: syncprov_sendresp: cookie=rid=136,csn=20100517113508.277430Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: syncprov_sendresp: cookie=rid=103,csn=20100517113508.277430Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: syncprov_sendresp: cookie=rid=154,csn=20100517113508.277430Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: conn=222514 op=3099 SRCH base="cn=001901717,ou=People,ou=salvage,ou=Access Groups,dc=client,dc=com" scope=1 deref=2 filter="(objectClass=*)" May 17 12:35:08 master slapd[3692]: conn=222514 op=3099 SRCH attr=objectclass May 17 12:35:08 master slapd[3692]: conn=222514 op=3099 SEARCH RESULT tag=101 err=0 nentries=0 text= May 17 12:35:08 master slapd[3692]: conn=222514 op=3100 DEL dn="cn=001901717,ou=People,ou=salvage,ou=Access Groups,dc=client,dc=com" May 17 12:35:08 master slapd[3692]: slap_queue_csn: queing 0x81cfce10 20100517113508.331930Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: conn=222514 op=3101 ABANDON msg=3101 May 17 12:35:08 master slapd[3692]: conn=222514 op=3102 UNBIND May 17 12:35:08 master slapd[3692]: slap_graduate_commit_csn: removing 0x7e550d68 20100517113508.331930Z#000000#000#000000 May 17 12:35:08 master slapd[3692]: conn=222514 fd=411 closed slave: May 17 12:35:32 slave slapd[2393]: slap_graduate_commit_csn: removing 0x8b867e0 20100517113508.192643Z#000000#000#000000 May 17 12:35:32 slave slapd[2393]: syncrepl_entry: rid=149 be_delete cn=001801399,ou=People,ou=salvage,ou=Access Groups,dc=client,dc=com (0) May 17 12:35:32 slave slapd[2393]: slap_queue_csn: queing 0x89bfb70 20100517113508.192643Z#000000#000#000000 May 17 12:35:32 slave slapd[2393]: slap_graduate_commit_csn: removing 0x8b69c68 20100517113508.192643Z#000000#000#000000 May 17 12:35:32 slave slapd[2393]: do_syncrep2: rid=149 cookie=rid=149,csn=20100517113508.234887Z#000000#000#000000 May 17 12:35:32 slave slapd[2393]: syncrepl_entry: rid=149 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_DELETE) May 17 12:35:32 slave slapd[2393]: syncrepl_entry: rid=149 be_search (0) May 17 12:35:32 slave slapd[2393]: syncrepl_entry: rid=149 cn=001800467,ou=People,ou=salvage,ou=Access Groups,dc=client,dc=com May 17 12:35:32 slave slapd[2393]: slap_queue_csn: queing 0x8af8bf0 20100517113508.234887Z#000000#000#000000 May 17 12:35:32 slave slapd[2393]: slap_graduate_commit_csn: removing 0x86d0a60 20100517113508.234887Z#000000#000#000000 May 17 12:35:32 slave slapd[2393]: syncrepl_entry: rid=149 be_delete cn=001800467,ou=People,ou=salvage,ou=Access Groups,dc=client,dc=com (0) May 17 12:35:32 slave slapd[2393]: slap_queue_csn: queing 0x8af8bf0 20100517113508.234887Z#000000#000#000000 May 17 12:35:32 slave slapd[2393]: slap_graduate_commit_csn: removing 0x86893e8 20100517113508.234887Z#000000#000#000000 May 17 12:35:32 slave slapd[2393]: do_syncrep2: rid=149 cookie=rid=149,csn=20100517113508.277430Z#000000#000#000000 May 17 12:35:32 slave slapd[2393]: syncrepl_entry: rid=149 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_DELETE) May 17 12:35:32 slave slapd[2393]: syncrepl_entry: rid=149 be_search (0) May 17 12:35:32 slave slapd[2393]: syncrepl_entry: rid=149 cn=001901714,ou=People,ou=salvage,ou=Access Groups,dc=client,dc=com May 17 12:35:32 slave slapd[2393]: slap_queue_csn: queing 0x86c0a38 20100517113508.277430Z#000000#000#000000 May 17 12:35:32 slave slapd[2393]: slap_graduate_commit_csn: removing 0x8abc018 20100517113508.277430Z#000000#000#000000 May 17 12:35:32 slave slapd[2393]: syncrepl_entry: rid=149 be_delete cn=001901714,ou=People,ou=salvage,ou=Access Groups,dc=client,dc=com (0) May 17 12:35:32 slave slapd[2393]: slap_queue_csn: queing 0x86c0a38 20100517113508.277430Z#000000#000#000000 May 17 12:35:32 slave slapd[2393]: slap_graduate_commit_csn: removing 0x8aedb68 20100517113508.277430Z#000000#000#000000 (logging stops for about 3s before another connection is made) AFAICT it seems that something happened between the master and slave that caused an ABANDON to be issued and the connection dropped to that slave. The deletion was successful on the master, but the cn=001901717 entry still remains on the slave. My questions would therefore be: 1) Are there any known issues with syncrepl and deletion in 2.4.21 that may be fixed in 2.4.22? 2) What does an ABANDON actually mean? Did the client or server terminate the connection and can we find out why? When slave reconnected back to the master, why was the incomplete transaction from the master not pushed back to the slave? 3) Would a simple restart of slapd on the slave cause it to resynchronise correctly with the master? 4) Is there any more information that we can provide from the logs on the 2 inconsistent slaves? Note I'm not sure whether to open an ITS on this since it is a live system and hence the scope for testing/debugging is much more limited. But I can try my best to obtain extra information if asked. Many thanks, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

2 2

multiple structural object class issue while migrating from sun one to openldap
by mani chandel 17 May '10

17 May '10

Hello, I am trying to do a migration from Sun one directory server 5.2 to openldap 2.2.29 (installed on windows). I did an export of data from sun one and now doing the import of data into openldap. But while importing I am running into the following errors. LDAP: error code 65 - invalid structural object class chain (st-person/inetOrgPerson) LDAP: error code 65 - invalid structural object class chain (st-person/fw1person) LDAP: error code 65 - invalid structural object class chain (st-person/st-extranetuser) LDAP: error code 65 - invalid structural object class chain (st-person/mailrecipient) Since all the above classes are structural so I tried making st-person auxiliary but then it threw error in other entries that no structural class provided which included only st-person as their object class. Object class mailrecipient was also conflicting with some other object classes so I tried making it auxiliary but it gave this error "LDAP: error code 80 - structuralObjectClass 'mailRecipient' is not STRUCTURAL" Is there any way so that I could allow multiple allow multiple structural object classes in openldap ? If not could anyone please suggest a solution to this problem. I would be really thankful if somebody could help me over this as I need to do this migration as soon as possible. Thanks a lot in advance, Mani

1 0

FW: OpenLDAP: contextCSN check across mirrors
by rahul.manchanda＠bt.com 17 May '10

17 May '10

Hi, Thanks for the reply. Can you please help me in understanding the two updates that has come in the two new LDAP releases "slapd-bdb contextCSN updates from updatedn" & " slapd syncrepl contextCSN storing in subentry". Can you please suggest what configurations are required to frequently change the contextCSN in slapd.conf so that my script can pick the latest one? I am also attaching the python script which I am using to check the sync status across mirrors? Could you please assist? Many Thanks. Rahul Manchanda GS Selfcare Platform Build Team Tel: +91 02066018100 Extn: 6178 SMTP: rahul.manchanda(a)bt.com Office: Sharda Center ,6th Floor Annex Off Karve Road, Erandwana ,Pune-04 -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Monday, May 10, 2010 6:32 PM To: Manchanda,RK,Rahul,DKE C Cc: quanah(a)zimbra.com; openldap-technical(a)openldap.org Subject: Re: OpenLDAP: contextCSN check across mirrors rahul.manchanda(a)bt.com wrote: > Thanks for the reply. > > "Added slapd syncrepl contextCSN storing in subentry (ITS#6373)". In > this point what I can understand is that contextCSN will also get > stored in suffix entries as well as to sub entries as well. Please > correct if wrong. That's wrong. Read the manpage and/or the ITS for the actual behavior. > I have some doubts if you can please help in making it more clear: > > 1) Can the contextCSN entry differ at the sub entry level if compared > with suffix(root) entry level? It will only be in one place or the other, not both. > 2) If this is the case then a check will be required to each and every > entry if the sync is there at the dn level across mirrors and scripts > need to be modified so as to put a loop till all the entries has been > checked in that particular LDAP tree. Please correct if wrong. No. > 3) how will the contextCSN entries will get changed. Does checkpoint > plays a role in changing the contextCSN value or not? No. > 4) provider will not change the contextCSN until the whole data get > synched False. but will consumer will still be able to do so. Is this still the > scenario in the new version? I don't understand the question. > > Many Thanks in advance!! > > Rahul Manchanda > > GS Selfcare > Platform Build Team > > Tel: +91 02066018100 Extn: 6178 > SMTP: rahul.manchanda(a)bt.com > > Office: Sharda Center ,6th Floor Annex Off Karve Road, Erandwana > ,Pune-04 > > > -----Original Message----- > From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] > Sent: Friday, May 07, 2010 4:48 PM > To: Manchanda,RK,Rahul,DKE C; openldap-technical(a)openldap.org > Subject: RE: OpenLDAP: contextCSN check across mirrors > > --On Friday, May 07, 2010 7:50 AM +0100 rahul.manchanda(a)bt.com wrote: > >> Hi, >> >> It is 2.4.19. > > Please update your servers to 2.4.22 and see if it still occurs. > Numerous > fixes have occurred since the 2.4.19 release. I've noted some > specific ones below that are likely of interest. > > OpenLDAP 2.4.20 Release (2009/11/27) > Added slapd syncrepl contextCSN storing in subentry (ITS#6373) > Fixed slapd syncrepl deletes in MirrorMode (ITS#6368) > Fixed slapd syncrepl to use correct SID (ITS#6367) > Fixed slapo-syncprov checkpoint conversion (ITS#6370) > Fixed slapo-syncprov deadlock (ITS#6335) > Fixed slapo-syncprov memory leak (ITS#6376) > Fixed slapo-syncprov out of order changes (ITS#6346) > Fixed slapo-syncprov psearch with stale cookie (ITS#6397) > > OpenLDAP 2.4.21 Release (2009/12/20) > Fixed slapd syncrepl freeing tasks from queue (ITS#6413) > Fixed slapd syncrepl parsing of tls defaults (ITS#6419) > Fixed slapd syncrepl uninitialized variables (ITS#6425) > > OpenLDAP 2.4.22 Release (2010/04/24) > Fixed slapd-bdb contextCSN updates from updatedn (ITS#6469) > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 3

PAM Authentication
by Miha Krajnc 15 May '10

15 May '10

I have set up 2 servers, a web server and a database server. The database server has mysql and OpenLDAP (configured, with 1 Posix user). The web server has apache, php, etc. I want to connect with the web server to the database server with PAM (libpam-ldap) and use creditentials from the database server for user logins. I have set up libpam-ldap, but the authentecation doesnt work. Further investegation (/var/log/auth.log ) shows that the teh web server cant contact the database server. However, i also ha ve phpLDAPadmin installed aon the web server, and i can connect to the database server from there. Anyone know what could be wrong? Here is the auth.log: May 11 10:57:33 web sudo: nss_ldap: could not connect to any LDAP server as cn=admin,dc=stef,dc=si - Can't contact LDAP server May 11 10:57:33 web sudo: nss_ldap: failed to bind to LDAP server ldap:/// 192.168.1.107:389/: Can't contact LDAP server May 11 10:57:33 web sudo: nss_ldap: reconnecting to LDAP server... May 11 10:57:33 web sudo: nss_ldap: could not connect to any LDAP server as cn=admin,dc=stef,dc=si - Can't contact LDAP server May 11 10:57:33 web sudo: nss_ldap: failed to bind to LDAP server ldap:/// 192.168.1.107:389/: Can't contact LDAP server -- Lep pozdrav, Miha Krajnc.

5 7

Custom Logging
by Marco Pizzoli 11 May '10

11 May '10

Hi list, Is there a way to log some specific client (choosen by IP or by binddn) to log to some specific log-file? I would like to have both the "general" log file written by syslogd, and a special log file to write only some specific clients . Thanks in advance Marco -- _________________________________________ Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison

2 1

rewriting (invalid) bindDN ?
by g-openldap-technical-list＠lachenal.net 11 May '10

11 May '10

Hi list, I've just set up a ldap proxy on witch I wish users may bind with their cn instead of dn. Some reading let me say it's possible - slapo-rwm (5) - http://blogs.turmzimmer.net/2008/06/26#ldap-3 - http://www.openldap.org/lists/openldap-software/201004/msg00065.html and some more I run slapd 2.4.11 from Debian Lenny. Here is slapd.conf : slapd.conf> ################################################################## slapd.conf> # Global Directives: slapd.conf> disallow bind_anon slapd.conf> require authc slapd.conf> include /etc/ldap/schema/core.schema slapd.conf> include /etc/ldap/schema/cosine.schema slapd.conf> include /etc/ldap/schema/nis.schema slapd.conf> include /etc/ldap/schema/inetorgperson.schema slapd.conf> pidfile /var/run/slapd/slapd.pid slapd.conf> argsfile /var/run/slapd/slapd.args slapd.conf> loglevel -1 slapd.conf> modulepath /usr/lib/ldap slapd.conf> moduleload back_ldap slapd.conf> moduleload rwm slapd.conf> sizelimit 500 slapd.conf> tool-threads 1 slapd.conf> ################################################################## slapd.conf> # Specific Directives for database #1 slapd.conf> slapd.conf> database ldap slapd.conf> suffix "o=MyO" slapd.conf> uri "ldap://MyLDAP" slapd.conf> readonly on slapd.conf> overlay rwm slapd.conf> rwm-rewriteEngine on slapd.conf> rwm-rewriteContext bindDN slapd.conf> rwm-rewriteRule "(.*)" "cn=$1,ou=SubOU,ou=OU,o=MyO" ":" When trying to bind from Thunderbird as client with just "MyCN", connection fail with "invalid dn". I expected some info about rwm rewriting syslog> slapd[11027]: conn=5 op=0 do_bind syslog> slapd[11027]: >>> dnPrettyNormal: <MyCN> syslog> slapd[11027]: conn=5 op=0 do_bind: invalid dn (glachenal) syslog> slapd[11027]: send_ldap_result: conn=5 op=0 p=3 syslog> slapd[11027]: send_ldap_result: err=34 matched="" text="invalid DN" syslog> slapd[11027]: send_ldap_response: msgid=1 tag=97 err=34 syslog> slapd[11027]: conn=5 op=0 RESULT tag=97 err=34 text=invalid DN When trying to bind with a valid DN, rwm works as expected. (And of course bind failed because of unexistent rewritten DN) syslog> slapd[11135]: >>> dnPrettyNormal: <cn=MyCN,ou=SubOU,ou=OU,o=MyO> syslog> slapd[11135]: <<< dnPrettyNormal: <cn=MyCN,ou=SubOU,ou=OU,o=MyO>, <cn=MyCN,ou=SubOU,ou=OU,o=MyO> syslog> slapd[11135]: conn=1 op=0 BIND dn="cn=MyCN,ou=SubOU,ou=OU,o=MyO" method=128 syslog> slapd[11135]: do_bind: version=3 dn="cn=MyCN,ou=SubOU,ou=OU,o=MyO" method=128 syslog> slapd[11135]: [rw] bindDN: "cn=MyCN,ou=SubOU,ou=OU,o=MyO" -> "cn=cn=MyCN,ou=SubOU,ou=OU,o=MyO,ou=SubOU,ou=OU,o=MyO" syslog> slapd[11135]: >>> dnPrettyNormal: <cn=cn=MyCN,ou=SubOU,ou=OU,o=MyO,ou=SubOU,ou=OU,o=MyO> syslog> slapd[11135]: <<< dnPrettyNormal: <cn=cn\3DMyCN,ou=SubOU,ou=OU,o=MyO,ou=SubOU,ou=OU,o=MyO>, <cn=cn\3DMyCN,ou=SubOU,ou=OU,o=MyO,ou=SubOU,ou=OU,o=MyO> So, why isn't rwm not used when supplying an invalid dn ? Regards, -G.-

3 2

OpenLDAP: contextCSN check across mirrors
by rahul.manchanda＠bt.com 10 May '10

10 May '10

Hello, I have configured three mirrors and am using a python script (ldapSynchCheck.py) which check the sync status on retrieving the contextCSN from both Provider and consumer I tried deleting a tree from directory and checked what is the output of the script and can still see "All of them are in sync". I believe this is happening because contextCSN is not getting updated on the respective directories and hence it will showing all in sync. However sometimes I am getting below error and it seems one of the consumer changed its contextCSN while provider was synching the data and it also confirms that provider will not change the contextCSN until it completes the sync to the consumer. 2010-05-06 15:15:51,459 - ldapSynchCheck.py - INFO - Provider is: tardis03.nat.bt.com:389 2010-05-06 15:15:51,462 - ldapSynchCheck.py - DEBUG - Connecting to ldap://tardis03.nat.bt.com:389 2010-05-06 15:15:51,464 - ldapSynchCheck.py - DEBUG - LDAP protocol version 3 2010-05-06 15:15:51,465 - ldapSynchCheck.py - DEBUG - Binding with o=BT 2010-05-06 15:15:51,469 - ldapSynchCheck.py - INFO - Checking if consumer tardis02.nat.bt.com:9011 is in SYNCH with provider 2010-05-06 15:15:51,470 - ldapSynchCheck.py - DEBUG - Connecting to ldap://tardis02.nat.bt.com:9011 2010-05-06 15:15:51,471 - ldapSynchCheck.py - DEBUG - LDAP protocol version 3 2010-05-06 15:15:51,472 - ldapSynchCheck.py - DEBUG - Binding with o=BT 2010-05-06 15:15:51,475 - ldapSynchCheck.py - DEBUG - Retrieving Provider contextCSN 2010-05-06 15:15:51,482 - ldapSynchCheck.py - DEBUG - contextCSN = 20100506141551.044268Z#000000#003#000000 2010-05-06 15:15:51,483 - ldapSynchCheck.py - DEBUG - Retrieving Consumer contextCSN 2010-05-06 15:15:51,513 - ldapSynchCheck.py - DEBUG - contextCSN = 20100506141551.044268Z#000000#003#000000 2010-05-06 15:15:51,515 - ldapSynchCheck.py - INFO - Provider and consumer exactly in SYNCH 2010-05-06 15:15:51,516 - ldapSynchCheck.py - INFO - Checking if consumer tardis01.nat.bt.com:9022 is in SYNCH with provider 2010-05-06 15:15:51,517 - ldapSynchCheck.py - DEBUG - Connecting to ldap://tardis01.nat.bt.com:9022 2010-05-06 15:15:51,519 - ldapSynchCheck.py - DEBUG - LDAP protocol version 3 2010-05-06 15:15:51,520 - ldapSynchCheck.py - DEBUG - Binding with o=BT 2010-05-06 15:15:51,523 - ldapSynchCheck.py - DEBUG - Retrieving Provider contextCSN 2010-05-06 15:15:51,525 - ldapSynchCheck.py - DEBUG - contextCSN = 20100506141551.044268Z#000000#003#000000 2010-05-06 15:15:51,526 - ldapSynchCheck.py - DEBUG - Retrieving Consumer contextCSN 2010-05-06 15:15:51,573 - ldapSynchCheck.py - DEBUG - contextCSN = 20100506141549.755004Z#000000#003#000000 <here it goes different> Traceback (most recent call last): File "./ldapSynchCheck.py", line 258, in <module> main() File "./ldapSynchCheck.py", line 253, in main is_insynch(ldapprov, ldapcons, options.basedn, options.threshold, logger) File "./ldapSynchCheck.py", line 188, in is_insynch delta = contextCSN_to_datetime(provcontextCSN) - contextCSN_to_datetime(conscontextCSN) File "./ldapSynchCheck.py", line 155, in contextCSN_to_datetime return datetime.datetime.fromtimestamp(time.mktime(time.strptime(gentime,"%Y%m% d%H%M%S"))) File "/software/python/lib/python2.6/_strptime.py", line 454, in _strptime_time return _strptime(data_string, format)[0] File "/software/python/lib/python2.6/_strptime.py", line 328, in _strptime data_string[found.end():]) ValueError: unconverted data remains: .044268 As I know putting a frequent checkpoint will generate a large amount of checkpoint log file and will cause issues while database recovery during crash/corrupt situations. Can someone please suggest how make this more precise? Is there any other way contextCSN keeps on changing frequently? Please suggest. Many Thanks in advance!! Rahul Manchanda GS Selfcare Platform Build Team Tel: +91 02066018100 Extn: 6178 SMTP: rahul.manchanda(a)bt.com Office: Sharda Center ,6th Floor Annex Off Karve Road, Erandwana ,Pune-04

4 6

Re: LDAP/PAM First time
by zoolook 10 May '10

10 May '10

2010/5/4 Quanah Gibson-Mount <quanah(a)zimbra.com>: > --On Tuesday, May 04, 2010 11:01 AM +0100 Rus Foster <vaserv(a)gmail.com> >> What have I missed? > > Use the correct -b option to ldapsearch. and/or configure /etc/ldap/ldap.conf or whatever your distro uses

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