Segmentation Fault appearing while doing the sync.-OpenLDAP 2.4.22
by rahul.manchanda＠bt.com
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
13 years, 4 months
Problem with syncrepl and deletion on openldap 2.4.21
by Mark Cave-Ayland
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
13 years, 4 months
multiple structural object class issue while migrating from sun one to openldap
by mani chandel
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
13 years, 4 months
FW: OpenLDAP: contextCSN check across mirrors
by rahul.manchanda＠bt.com
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/
13 years, 4 months
PAM Authentication
by Miha Krajnc
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.
13 years, 4 months
Custom Logging
by Marco Pizzoli
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
13 years, 4 months
rewriting (invalid) bindDN ?
by g-openldap-technical-list＠lachenal.net
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.-
13 years, 4 months
OpenLDAP: contextCSN check across mirrors
by rahul.manchanda＠bt.com
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
13 years, 4 months
Re: LDAP/PAM First time
by zoolook
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
13 years, 4 months
Encrypting passwords
by Miha Krajnc
Greetings,
some time ago i saw a command (i'm guessing from the ldap-utils package)
that would encrypt text into one of the encryptions supported by openldap
(md5, crypt etc...) anyone know what that command is?
Thanks!
--
Lep pozdrav, Miha Krajnc.
13 years, 4 months
