openldap-technical

openldap-technical@openldap.org

13 participants
9906 discussions

ABI report for LMDB
by Ponomarenko Andrey 26 May '16

26 May '16

Hello, The LMDB library is now tracked by the ABI tracker project: http://abi-laboratory.pro/tracker/timeline/lmdb/ One can look at the recent changes in the API/ABI and analysis of backward compatibility and navigate over the history of API/ABI changes in the library. The reports are generated daily by the abi-compliance-checker and abi-tracker tools: https://github.com/lvc/abi-tracker Thank you.

1 0

Re: entryCSN is larger (later) in consumer node than in provider node
by Frank Luo 25 May '16

25 May '16

same error if I try to update this ppolicy attribute "changetype: modify replace: pwdMinLength pwdMinLength: 9" ldap_modify: Server is unwilling to perform (53) additional info: shadow context; no update referral On Wed, May 25, 2016 at 4:26 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Wednesday, May 25, 2016 5:21 PM -0400 Frank Luo <frank.luoy(a)gmail.com> > wrote: > >> yes >> >> overlay ppolicy > > > So ppolicy maintains various data internally to the server. That's likely > what is giving you #000# items. > > --Quanah > > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > A division of Synacor, Inc

1 0

Re: entryCSN is larger (later) in consumer node than in provider node
by Frank Luo 25 May '16

25 May '16

yes overlay ppolicy and overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 So it looks like on node 3 I have both syncprov and syncrepl defined? "overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncrepl rid=003 ..... " But actully when I try to write to node 3 directly, I have a error like this, "ldap_modify: Server is unwilling to perform (53) additional info: shadow context; no update referral " Thanks Frank On Tue, May 24, 2016 at 7:31 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > Do you have any overlays on the replicas? > > --Quanah > > --On Tuesday, May 24, 2016 4:55 PM -0400 Frank Luo <frank.luoy(a)gmail.com> > wrote: > >> but we always have two masters - and you can tell that this is pretty >> current time tag. >> >> contextCSN: 20160521215740.310825Z#000000#000#000000 >> >> Does this mean the slave gets updated from some other source in >> additional to the two masters. >> >> I am attache the replication portion of the slaver sever 3, >> server2.u.com is one of the two masters >> >> >> syncrepl rid=003 >> provider=ldap://server2.u.com >> bindmethod=simple >> binddn="cn=Manager,dc=u,dc=com" >> credentials=password >> searchbase="dc=u,dc=com" >> schemachecking=on >> type=refreshAndPersist >> retry="60 +" >> >> Thanks >> >> Frank >> >> >> >> On Tue, May 24, 2016 at 12:54 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> >> wrote: >>> >>> Sure -- 000 is from when things were single master. >>> >>> --Quanah >>> >>> --On Tuesday, May 24, 2016 12:37 PM -0400 Frank Luo >>> <frank.luoy(a)gmail.com> wrote: >>> >>>> Thanks. The two servers were off by 15 seconds >>>> >>>> I also checked contextCSN and see there were more than 1 values - any >>>> idea there are multiple? >>>> >>>> To help you understand we have a multiple(2) masters and three slaves. >>>> >>>> on two masters (node1 and node 2), each has two contextCSN like this, >>>> I can understand since they are in mirror mode, it get updates from >>>> each other >>>> >>>> node 1: >>>> contextCSN: 20160524152519.525094Z#000000#001#000000 >>>> contextCSN: 20160524152340.159717Z#000000#002#000000 >>>> >>>> node 2: >>>> contextCSN: 20160524152519.525094Z#000000#001#000000 >>>> contextCSN: 20160524152340.159717Z#000000#002#000000 >>>> >>>> >>>> on three slavers (nodes3,4 and5), each has 3 contextCSN. Where does >>>> the third contextCSN come from - you can see the third one is out of >>>> sync with each other. >>>> >>>> node 3: >>>> contextCSN: 20160524152519.525094Z#000000#001#000000 >>>> contextCSN: 20160521215740.310825Z#000000#000#000000 >>>> contextCSN: 20160524152340.159717Z#000000#002#000000 >>>> >>>> node 4: >>>> contextCSN: 20160524152519.525094Z#000000#001#000000 >>>> contextCSN: 20160524152558.806951Z#000000#000#000000 >>>> contextCSN: 20160524152340.159717Z#000000#002#000000 >>>> >>>> node 5: >>>> contextCSN: 20150723095205.352520Z#000000#000#000000 >>>> contextCSN: 20160524152519.525094Z#000000#001#000000 >>>> contextCSN: 20160524152340.159717Z#000000#002#000000 >>>> >>>> THanks >>>> >>>> Frank >>>> >>>> >>>> On Mon, May 23, 2016 at 5:11 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> >>>> wrote: >>>>> >>>>> >>>>> --On Monday, May 23, 2016 5:56 PM -0400 Frank Luo >>>>> <frank.luoy(a)gmail.com> wrote: >>>>> >>>>>> All, >>>>>> >>>>>> I am having a out-of sync situation now with some entries' entryCSN >>>>>> is larger (later) in consumer node than in provider node. So the >>>>>> consumer never gets updated since it thinks it has the latest value. >>>>> >>>>> >>>>> >>>>> >>>>> Check the clocks on each server. It is required that your clocks be >>>>> tightly sync'd. >>>>> >>>>> --Quanah >>>>> >>>>> >>>>> -- >>>>> >>>>> Quanah Gibson-Mount >>>>> Platform Architect >>>>> Zimbra, Inc. >>>>> -------------------- >>>>> Zimbra :: the leader in open source messaging and collaboration >>>>> A division of Synacor, Inc >>> >>> >>> >>> >>> >>> -- >>> >>> Quanah Gibson-Mount >>> Platform Architect >>> Zimbra, Inc. >>> -------------------- >>> Zimbra :: the leader in open source messaging and collaboration >>> A division of Synacor, Inc > > > > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > A division of Synacor, Inc

2 1

Partial SyncRepl replication
by Frank Swasey 25 May '16

25 May '16

I am running OpenLDAP 2.4.44 locally built on RHEL7 using mdb as the database backend. I am attempting to replicate just the inetLocalMailRecipient objectclass and the DSA attributes to a new set of replicas that will be in charge of delivering mail. I would like the DSA attributes (creator, modifier, contextCSN, entryCSN, entryUUID - etc) to be included, so I can more easily tell if the partial replica is actually staying sync'd to the master. My reading of the man pages for slapd.conf and slapd.access have me part way there, but setting up a replication DN and using acls to limit its access to the inetLocalMailRecipient objectclass. What I'm not finding is a way to specify all of (what I'm calling) the DSA attributes (without naming them all individually) - have I missed something in the man pages or is the source code (or the benevolence of one of you good folks) my only hope? -- 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 8

Re: entryCSN is larger (later) in consumer node than in provider node
by Frank Luo 25 May '16

25 May '16

but we always have two masters - and you can tell that this is pretty current time tag. contextCSN: 20160521215740.310825Z#000000#000#000000 Does this mean the slave gets updated from some other source in additional to the two masters. I am attache the replication portion of the slaver sever 3, server2.u.com is one of the two masters syncrepl rid=003 provider=ldap://server2.u.com bindmethod=simple binddn="cn=Manager,dc=u,dc=com" credentials=password searchbase="dc=u,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" Thanks Frank On Tue, May 24, 2016 at 12:54 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > Sure -- 000 is from when things were single master. > > --Quanah > > --On Tuesday, May 24, 2016 12:37 PM -0400 Frank Luo <frank.luoy(a)gmail.com> > wrote: > >> Thanks. The two servers were off by 15 seconds >> >> I also checked contextCSN and see there were more than 1 values - any >> idea there are multiple? >> >> To help you understand we have a multiple(2) masters and three slaves. >> >> on two masters (node1 and node 2), each has two contextCSN like this, >> I can understand since they are in mirror mode, it get updates from >> each other >> >> node 1: >> contextCSN: 20160524152519.525094Z#000000#001#000000 >> contextCSN: 20160524152340.159717Z#000000#002#000000 >> >> node 2: >> contextCSN: 20160524152519.525094Z#000000#001#000000 >> contextCSN: 20160524152340.159717Z#000000#002#000000 >> >> >> on three slavers (nodes3,4 and5), each has 3 contextCSN. Where does >> the third contextCSN come from - you can see the third one is out of >> sync with each other. >> >> node 3: >> contextCSN: 20160524152519.525094Z#000000#001#000000 >> contextCSN: 20160521215740.310825Z#000000#000#000000 >> contextCSN: 20160524152340.159717Z#000000#002#000000 >> >> node 4: >> contextCSN: 20160524152519.525094Z#000000#001#000000 >> contextCSN: 20160524152558.806951Z#000000#000#000000 >> contextCSN: 20160524152340.159717Z#000000#002#000000 >> >> node 5: >> contextCSN: 20150723095205.352520Z#000000#000#000000 >> contextCSN: 20160524152519.525094Z#000000#001#000000 >> contextCSN: 20160524152340.159717Z#000000#002#000000 >> >> THanks >> >> Frank >> >> >> On Mon, May 23, 2016 at 5:11 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> >> wrote: >>> >>> --On Monday, May 23, 2016 5:56 PM -0400 Frank Luo <frank.luoy(a)gmail.com> >>> wrote: >>> >>>> All, >>>> >>>> I am having a out-of sync situation now with some entries' entryCSN >>>> is larger (later) in consumer node than in provider node. So the >>>> consumer never gets updated since it thinks it has the latest value. >>> >>> >>> >>> Check the clocks on each server. It is required that your clocks be >>> tightly sync'd. >>> >>> --Quanah >>> >>> >>> -- >>> >>> Quanah Gibson-Mount >>> Platform Architect >>> Zimbra, Inc. >>> -------------------- >>> Zimbra :: the leader in open source messaging and collaboration >>> A division of Synacor, Inc > > > > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > A division of Synacor, Inc

3 2

Re: entryCSN is larger (later) in consumer node than in provider node
by Frank Luo 24 May '16

24 May '16

Thanks. The two servers were off by 15 seconds I also checked contextCSN and see there were more than 1 values - any idea there are multiple? To help you understand we have a multiple(2) masters and three slaves. on two masters (node1 and node 2), each has two contextCSN like this, I can understand since they are in mirror mode, it get updates from each other node 1: contextCSN: 20160524152519.525094Z#000000#001#000000 contextCSN: 20160524152340.159717Z#000000#002#000000 node 2: contextCSN: 20160524152519.525094Z#000000#001#000000 contextCSN: 20160524152340.159717Z#000000#002#000000 on three slavers (nodes3,4 and5), each has 3 contextCSN. Where does the third contextCSN come from - you can see the third one is out of sync with each other. node 3: contextCSN: 20160524152519.525094Z#000000#001#000000 contextCSN: 20160521215740.310825Z#000000#000#000000 contextCSN: 20160524152340.159717Z#000000#002#000000 node 4: contextCSN: 20160524152519.525094Z#000000#001#000000 contextCSN: 20160524152558.806951Z#000000#000#000000 contextCSN: 20160524152340.159717Z#000000#002#000000 node 5: contextCSN: 20150723095205.352520Z#000000#000#000000 contextCSN: 20160524152519.525094Z#000000#001#000000 contextCSN: 20160524152340.159717Z#000000#002#000000 THanks Frank On Mon, May 23, 2016 at 5:11 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Monday, May 23, 2016 5:56 PM -0400 Frank Luo <frank.luoy(a)gmail.com> > wrote: > >> All, >> >> I am having a out-of sync situation now with some entries' entryCSN >> is larger (later) in consumer node than in provider node. So the >> consumer never gets updated since it thinks it has the latest value. > > > Check the clocks on each server. It is required that your clocks be tightly > sync'd. > > --Quanah > > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > A division of Synacor, Inc

2 1

back-ldap and Proxy operation retry failed
by Abdelkader Chelouah 24 May '16

24 May '16

(Sorry for posting this message again, but it's better with a Subject) OpenLDAP 2.4.44 under RHEL 7.1 I'm using back-ldap to proxy a back-mdb instance with 1K users. The relevant part of the proxy configuration is dn: olcDatabase={2}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {2}ldap olcSuffix: dc=example,dc=com olcDbURI: "ldap://ldap-server.example.com:389/" olcDbIDAssertBind: bindmethod=none olcDbIDAssertAuthzFrom: {0}"*" olcDbRebindAsUser: TRUE olcDbChaseReferrals: TRUE I'm using slamd for doing performance tests. According to the back-ldap man page, sessions that explicitly Bind to the back-ldap database always create their own private connection to the remote LDAP server. However, it seems that the private connections are not reused for further BIND with the same user since the available file descriptors (8192) on remote server are quickly exhausted (recall that my LDAP server has only 1K users, BINDs with slamd are performed randomly). The private connections are closed after the remote LDAP server idletimeout (15mn), but remain stuck in a CLOSE_WAIT status. Using the parameter olcDbSingleConn: TRUE improves the situation (the number of connections open on the remote server and the proxy are more or less identical), but slapd logs show errors 2016-05-23T11:18:50.100499+02:00 proxy-ldap slapd-proxy_ldap[18402]: conn=1419 op=7201 ldap_back_retry: retrying URI="ldap:// mirror.example.com:389" DN="" 2016-05-23T11:18:50.100542+02:00 proxy-ldap slapd-proxy_ldap[18402]: conn=1419 op=7201 RESULT tag=97 err=52 text=Proxy operation retry failed The encountred problem seems to be related to ITS#4387 ( http://www.openldap.org/its/index.cgi/Archive.Software%20Bugs?id=4387;selec…) and ITS#4420 ( http://www.openldap.org/its/index.cgi/Archive.Incoming?id=4420;selectid=442… ) Do I have to file an ITS ?

1 0

issue with filter string for numerical uid
by Rene Zeipelt 24 May '16

24 May '16

Hello , I hope this is the right point for my problem: we have a 2.4.40 slapd running on Debian Jessie with inetOrgPerson entries that have (indexed) numerical uid values. No problems if the user login on our web app (moodle) but some users get input mistakes and use superscripted first letter which also works. Here an example: uid=1228849 and uid=¹228849 works also. If I check the debug output for the superscripted version I got: May 24 09:44:23 rldapd slapd[600]: begin get_filter May 24 09:44:23 rldapd slapd[600]: EQUALITY May 24 09:44:23 rldapd slapd[600]: end get_filter 0 May 24 09:44:23 rldapd slapd[600]: filter: (uid=1228849) May 24 09:44:23 rldapd slapd[600]: attrs: If I trace the network traffic data there is a difference between the queries 0x0090: 0375 6964 0407 3132 3238 3834 3930 00 .uid..12288490. 0x0090: 0375 6964 0408 c2b9 3232 3838 3439 3000 .uid....2288490. The command line tool "ldapsearch" do the same. So for the web app the superscripted version is a different user and for slapd it is not. Why slapd is interpreted the superscripted 1 as 1? Is this a bug or must check the input before it is send to slapd? Thanks for any help. Best regards Rene --

1 0

entryCSN is larger (later) in consumer node than in provider node
by Frank Luo 23 May '16

23 May '16

All, I am having a out-of sync situation now with some entries' entryCSN is larger (later) in consumer node than in provider node. So the consumer never gets updated since it thinks it has the latest value. provider: entryCSN: 20160520164908.960158Z#000000#001#000000 consumer: entryCSN: 20160521191401.646572Z#000000#000#000000 slapd.conf in consumer: overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncrepl rid=003 provider=ldap://server.u.edu bindmethod=simple binddn="cn=Manager,dc=u,dc=com" credentials=password searchbase="dc=u,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" Any hint about this? Thanks a lot! Frank

2 1

(no subject)
by Abdelkader Chelouah 23 May '16

23 May '16

OpenLDAP 2.4.44 under RHEL 7.1 I'm using back-ldap to proxy a back-mdb instance with 1K users. The relevant part of the proxy configuration is dn: olcDatabase={2}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {2}ldap olcSuffix: dc=example,dc=com olcDbURI: "ldap://ldap-server.example.com:389/" olcDbIDAssertBind: bindmethod=none olcDbIDAssertAuthzFrom: {0}"*" olcDbRebindAsUser: TRUE olcDbChaseReferrals: TRUE I'm using slamd for doing performance tests. According to the back-ldap man page, sessions that explicitly Bind to the back-ldap database always create their own private connection to the remote LDAP server. The private connections are closed after the remote LDAP server idletimeout (15mn), but remain stuck in a CLOSE_WAIT status. Moreover, it seems that the private connections are not reused for further BIND with the same user since the available file descriptors (8192) on remote server are quickly exhausted (only 1K users). Using the parameter olcDbSingleConn: TRUE improves the situation (the number of connections open on the remote server and the proxy are more or less identical), but slapd logs show errors 2016-05-23T11:18:50.100499+02:00 proxy-ldap slapd-proxy_ldap[18402]: conn=1419 op=7201 ldap_back_retry: retrying URI="ldap:// mirror.example.com:389" DN="" 2016-05-23T11:18:50.100542+02:00 proxy-ldap slapd-proxy_ldap[18402]: conn=1419 op=7201 RESULT tag=97 err=52 text=Proxy operation retry failed The encountred problem seems to be related to ITS#4387 ( http://www.openldap.org/its/index.cgi/Archive.Software%20Bugs?id=4387;selec…) and ITS#4420 ( http://www.openldap.org/its/index.cgi/Archive.Incoming?id=4420;selectid=442… )

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