openldap-technical

openldap-technical@openldap.org

14 participants
9795 discussions

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

Translucent problem
by Frank Rust 22 May '16

22 May '16

Hi all, I want to try a translucent configuration: The local ldap shall overlay the central ldap with local information on mail routing. I only have read access to the central ldap server. Generally it works fine, when using bind with a locally known user. But when I try bind with a user of the central ldap (for mail user authentication) it fails. Example: $ ldapsearch -LLL -w pass -b cn=sendmail,dc=some,dc=local,dc=company,dc=de -H ldap://localhost/ -b ou=People,dc=company,dc=de uid=myUID cn uid mailLocalAddress returns me absolutely correct: dn: uid=myUID,ou=people,dc=company,dc=de uid: nyUID cn: Firstname Name mailLocalAddress: firstname.name(a)some.local.company.de mailLocalAddress: f.name(a)some.local.company.de mailLocalAddress: myUID(a)some.local.company.de $ ldapsearch -LLL -w myPass -b uid=myUID,ou=People,dc=company,dc=de -H ldap://localhost/ -b ou=People,dc=company,dc=de uid=myUID cn did mailLocalAddress returns no results. When tcpdumping network traffic to central ldap I can see that the correct result is returned. What am I possibly doing wrong? Thanks in advance for any hints. Best regards, Frank ### Relevant parts of my configuration: # {2}mdb, config dn: olcDatabase={2}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {2}mdb olcDbDirectory: /var/lib/ldap/translucent olcSuffix: ou=People,dc=company,dc=de olcRootDN: cn=local-admin,ou=People,dc=company,dc=de olcRootPW:: secret... olcDbIndex: objectClass eq olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonym ous auth by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to dn.children="ou=People,dc=company,dc=de" by dn="cn=sendmail,dc =some,dc=local,dc=company,dc=de" read # {0}translucent, {2}mdb, config dn: olcOverlay={0}translucent,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcTranslucentConfig olcOverlay: {0}translucent olcTranslucentLocal: mailLocalAddress,mailRoutingAddress,mailHost # {0}ldap, {0}translucent, {2}mdb, config dn: olcDatabase={0}ldap,olcOverlay={0}translucent,olcDatabase={2}mdb,cn=config objectClass: olcLDAPConfig objectClass: olcTranslucentDatabase olcDatabase: {0}ldap olcDbURI: "ldap://ldap.company.de" olcDbStartTLS: none starttls=no olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: FALSE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0 ### Logfile on failed request: May 22 13:46:24 ldap slapd[493]: daemon: activity on 1 descriptor May 22 13:46:24 ldap slapd[493]: daemon: activity on: May 22 13:46:24 ldap slapd[493]: May 22 13:46:24 ldap slapd[493]: slap_listener_activate(10): May 22 13:46:24 ldap slapd[493]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 22 13:46:24 ldap slapd[493]: daemon: epoll: listen=10 busy May 22 13:46:24 ldap slapd[493]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 22 13:46:24 ldap slapd[493]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 22 13:46:24 ldap slapd[493]: daemon: epoll: listen=13 active_threads=0 tvp=zero May 22 13:46:24 ldap slapd[493]: >>> slap_listener(ldap:///) May 22 13:46:24 ldap slapd[493]: daemon: listen=10, new connection on 22 May 22 13:46:24 ldap slapd[493]: daemon: added 22r (active) listener=(nil) May 22 13:46:24 ldap slapd[493]: conn=1874 fd=22 ACCEPT from IP=[::1]:49124 (IP=[::]:389) May 22 13:46:24 ldap slapd[493]: daemon: activity on 1 descriptor May 22 13:46:24 ldap slapd[493]: daemon: activity on: May 22 13:46:24 ldap slapd[493]: May 22 13:46:24 ldap slapd[493]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 22 13:46:24 ldap slapd[493]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 22 13:46:24 ldap slapd[493]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 22 13:46:24 ldap slapd[493]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 22 13:46:24 ldap slapd[493]: daemon: epoll: listen=13 active_threads=0 tvp=zero May 22 13:46:24 ldap slapd[493]: daemon: activity on 1 descriptor May 22 13:46:24 ldap slapd[493]: daemon: activity on: May 22 13:46:24 ldap slapd[493]: 22r May 22 13:46:24 ldap slapd[493]: May 22 13:46:24 ldap slapd[493]: daemon: read active on 22 May 22 13:46:24 ldap slapd[493]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 22 13:46:24 ldap slapd[493]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 22 13:46:24 ldap slapd[493]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 22 13:46:24 ldap slapd[493]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 22 13:46:24 ldap slapd[493]: daemon: epoll: listen=13 active_threads=0 tvp=zero May 22 13:46:24 ldap slapd[493]: connection_get(22) May 22 13:46:24 ldap slapd[493]: connection_get(22): got connid=1874 May 22 13:46:24 ldap slapd[493]: connection_read(22): checking for input on id=1874 May 22 13:46:24 ldap slapd[493]: op tag 0x60, time 1463917584 May 22 13:46:24 ldap slapd[493]: conn=1874 op=0 do_bind May 22 13:46:24 ldap slapd[493]: >>> dnPrettyNormal: <uid=myUID,ou=People,dc=company,dc=de> May 22 13:46:24 ldap slapd[493]: <<< dnPrettyNormal: <uid=myUID,ou=People,dc=company,dc=de>, <uid=myUID,ou=people,dc=company,dc=de> May 22 13:46:24 ldap slapd[493]: conn=1874 op=0 BIND dn="uid=myUID,ou=People,dc=company,dc=de" method=128 May 22 13:46:24 ldap slapd[493]: do_bind: version=3 dn="uid=myUID,ou=People,dc=company,dc=de" method=128 May 22 13:46:24 ldap slapd[493]: translucent_bind: <uid=myUID,ou=People,dc=company,dc=de> method 128 May 22 13:46:24 ldap slapd[493]: =>ldap_back_getconn: conn=1874 op=0: lc=0x7f3d44133a60 inserted refcnt=1 rc=0 May 22 13:46:24 ldap slapd[493]: daemon: activity on 1 descriptor May 22 13:46:24 ldap slapd[493]: daemon: activity on: May 22 13:46:24 ldap slapd[493]: May 22 13:46:24 ldap slapd[493]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 22 13:46:24 ldap slapd[493]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 22 13:46:24 ldap slapd[493]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 22 13:46:24 ldap slapd[493]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 22 13:46:24 ldap slapd[493]: daemon: epoll: listen=13 active_threads=0 tvp=zero May 22 13:46:25 ldap slapd[493]: conn=1874 op=0 BIND dn="uid=myUID,ou=People,dc=company,dc=de" mech=SIMPLE ssf=0 May 22 13:46:25 ldap slapd[493]: do_bind: v3 bind: "uid=myUID,ou=People,dc=company,dc=de" to "uid=myUID,ou=People,dc=company,dc=de" May 22 13:46:25 ldap slapd[493]: send_ldap_result: conn=1874 op=0 p=3 May 22 13:46:25 ldap slapd[493]: send_ldap_result: err=0 matched="" text="" May 22 13:46:25 ldap slapd[493]: send_ldap_response: msgid=1 tag=97 err=0 May 22 13:46:25 ldap slapd[493]: conn=1874 op=0 RESULT tag=97 err=0 text= May 22 13:46:25 ldap slapd[493]: daemon: activity on 1 descriptor May 22 13:46:25 ldap slapd[493]: daemon: activity on: May 22 13:46:25 ldap slapd[493]: 22r May 22 13:46:25 ldap slapd[493]: May 22 13:46:25 ldap slapd[493]: daemon: read active on 22 May 22 13:46:25 ldap slapd[493]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 22 13:46:25 ldap slapd[493]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 22 13:46:25 ldap slapd[493]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 22 13:46:25 ldap slapd[493]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 22 13:46:25 ldap slapd[493]: daemon: epoll: listen=13 active_threads=0 tvp=zero May 22 13:46:25 ldap slapd[493]: connection_get(22) May 22 13:46:25 ldap slapd[493]: connection_get(22): got connid=1874 May 22 13:46:25 ldap slapd[493]: connection_read(22): checking for input on id=1874 May 22 13:46:25 ldap slapd[493]: op tag 0x63, time 1463917585 May 22 13:46:25 ldap slapd[493]: conn=1874 op=1 do_search May 22 13:46:25 ldap slapd[493]: >>> dnPrettyNormal: <ou=People,dc=company,dc=de> May 22 13:46:25 ldap slapd[493]: <<< dnPrettyNormal: <ou=People,dc=company,dc=de>, <ou=people,dc=company,dc=de> May 22 13:46:25 ldap slapd[493]: SRCH "ou=People,dc=company,dc=de" 2 0 May 22 13:46:25 ldap slapd[493]: 0 0 0 May 22 13:46:25 ldap slapd[493]: begin get_filter May 22 13:46:25 ldap slapd[493]: EQUALITY May 22 13:46:25 ldap slapd[493]: end get_filter 0 May 22 13:46:25 ldap slapd[493]: filter: (uid=myUID) May 22 13:46:25 ldap slapd[493]: attrs: May 22 13:46:25 ldap slapd[493]: cn May 22 13:46:25 ldap slapd[493]: uid May 22 13:46:25 ldap slapd[493]: mailLocalAddress May 22 13:46:25 ldap slapd[493]: userPassword May 22 13:46:25 ldap slapd[493]: May 22 13:46:25 ldap slapd[493]: conn=1874 op=1 SRCH base="ou=People,dc=company,dc=de" scope=2 deref=0 filter="(uid=myUID)" May 22 13:46:25 ldap slapd[493]: conn=1874 op=1 SRCH attr=cn uid mailLocalAddress userPassword May 22 13:46:25 ldap slapd[493]: ==> limits_get: conn=1874 op=1 self="uid=myUID,ou=people,dc=company,dc=de" this="ou=people,dc=company,dc=de" May 22 13:46:25 ldap slapd[493]: ==> translucent_search: <ou=People,dc=company,dc=de> (uid=myUID) May 22 13:46:25 ldap slapd[493]: =>ldap_back_getconn: conn 0x7f3d44133a60 fetched refcnt=1. May 22 13:46:25 ldap slapd[493]: => ldap_back_munge_filter "(uid=myUID)" May 22 13:46:25 ldap slapd[493]: <= ldap_back_munge_filter "(uid=myUID)" (0) May 22 13:46:25 ldap slapd[493]: daemon: activity on 1 descriptor May 22 13:46:25 ldap slapd[493]: daemon: activity on: May 22 13:46:25 ldap slapd[493]: May 22 13:46:25 ldap slapd[493]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 22 13:46:25 ldap slapd[493]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 22 13:46:25 ldap slapd[493]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 22 13:46:25 ldap slapd[493]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 22 13:46:25 ldap slapd[493]: daemon: epoll: listen=13 active_threads=0 tvp=zero May 22 13:46:25 ldap slapd[493]: >>> dnPrettyNormal: <uid=myUID,ou=people,dc=company,dc=de> May 22 13:46:25 ldap slapd[493]: <<< dnPrettyNormal: <uid=myUID,ou=people,dc=company,dc=de>, <uid=myUID,ou=people,dc=company,dc=de> May 22 13:46:25 ldap slapd[493]: >>> dnPretty: <cn=ldaproot,dc=company,dc=de> May 22 13:46:25 ldap slapd[493]: <<< dnPretty: <cn=ldaproot,dc=company,dc=de> May 22 13:46:25 ldap slapd[493]: >>> dnNormalize: <cn=ldaproot,dc=company,dc=de> May 22 13:46:25 ldap slapd[493]: <<< dnNormalize: <cn=ldaproot,dc=company,dc=de> May 22 13:46:25 ldap slapd[493]: >>> dnPretty: <cn=ldaproot,dc=company,dc=de> May 22 13:46:25 ldap slapd[493]: <<< dnPretty: <cn=ldaproot,dc=company,dc=de> May 22 13:46:25 ldap slapd[493]: >>> dnNormalize: <cn=ldaproot,dc=company,dc=de> May 22 13:46:25 ldap slapd[493]: <<< dnNormalize: <cn=ldaproot,dc=company,dc=de> May 22 13:46:25 ldap slapd[493]: ==> translucent_search_cb: uid=myUID,ou=people,dc=company,dc=de May 22 13:46:25 ldap slapd[493]: => mdb_entry_get: ndn: "uid=myUID,ou=people,dc=company,dc=de" May 22 13:46:25 ldap slapd[493]: => mdb_entry_get: oc: "(null)", at: "(null)" May 22 13:46:25 ldap slapd[493]: mdb_dn2entry("uid=myUID,ou=people,dc=company,dc=de") May 22 13:46:25 ldap slapd[493]: => mdb_dn2id("uid=myUID,ou=people,dc=company,dc=de") May 22 13:46:25 ldap slapd[493]: <= mdb_dn2id: got id=0x2 May 22 13:46:25 ldap slapd[493]: => mdb_entry_decode: May 22 13:46:25 ldap slapd[493]: <= mdb_entry_decode May 22 13:46:25 ldap slapd[493]: => mdb_entry_get: found entry: "uid=myUID,ou=people,dc=company,dc=de" May 22 13:46:25 ldap slapd[493]: mdb_entry_get: rc=0 May 22 13:46:25 ldap slapd[493]: => test_filter May 22 13:46:25 ldap slapd[493]: EQUALITY May 22 13:46:25 ldap slapd[493]: => access_allowed: search access to "uid=myUID,ou=people,dc=company,dc=de" "uid" requested May 22 13:46:25 ldap slapd[493]: => dn: [2] May 22 13:46:25 ldap slapd[493]: => dn: [3] ou=people,dc=company,dc=de May 22 13:46:25 ldap slapd[493]: => acl_get: [3] matched May 22 13:46:25 ldap slapd[493]: => acl_get: [3] attr uid May 22 13:46:25 ldap slapd[493]: => acl_mask: access to entry "uid=myUID,ou=people,dc=company,dc=de", attr "uid" requested May 22 13:46:25 ldap slapd[493]: => acl_mask: to value by "uid=myUID,ou=people,dc=company,dc=de", (=0) May 22 13:46:25 ldap slapd[493]: <= check a_dn_pat: cn=sendmail,dc=some,dc=local,dc=company,dc=de May 22 13:46:25 ldap slapd[493]: <= acl_mask: no more <who> clauses, returning =0 (stop) May 22 13:46:25 ldap slapd[493]: => slap_access_allowed: search access denied by =0 May 22 13:46:25 ldap slapd[493]: => access_allowed: no more rules May 22 13:46:25 ldap slapd[493]: <= test_filter 50 May 22 13:46:25 ldap slapd[493]: send_ldap_result: conn=1874 op=1 p=3 May 22 13:46:25 ldap slapd[493]: send_ldap_result: err=0 matched="" text="" May 22 13:46:25 ldap slapd[493]: send_ldap_response: msgid=2 tag=101 err=0 May 22 13:46:25 ldap slapd[493]: conn=1874 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= May 22 13:46:25 ldap slapd[493]: daemon: activity on 1 descriptor May 22 13:46:25 ldap slapd[493]: daemon: activity on: May 22 13:46:25 ldap slapd[493]: 22r May 22 13:46:25 ldap slapd[493]: May 22 13:46:25 ldap slapd[493]: daemon: read active on 22 May 22 13:46:25 ldap slapd[493]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 22 13:46:25 ldap slapd[493]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 22 13:46:25 ldap slapd[493]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 22 13:46:25 ldap slapd[493]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 22 13:46:25 ldap slapd[493]: daemon: epoll: listen=13 active_threads=0 tvp=zero May 22 13:46:25 ldap slapd[493]: connection_get(22) May 22 13:46:25 ldap slapd[493]: connection_get(22): got connid=1874 May 22 13:46:25 ldap slapd[493]: connection_read(22): checking for input on id=1874 May 22 13:46:25 ldap slapd[493]: op tag 0x42, time 1463917585 May 22 13:46:25 ldap slapd[493]: ber_get_next on fd 22 failed errno=0 (Success) May 22 13:46:25 ldap slapd[493]: connection_read(22): input error=-2 id=1874, closing. May 22 13:46:25 ldap slapd[493]: connection_closing: readying conn=1874 sd=22 for close May 22 13:46:25 ldap slapd[493]: connection_close: deferring conn=1874 sd=22 May 22 13:46:25 ldap slapd[493]: conn=1874 op=2 do_unbind May 22 13:46:25 ldap slapd[493]: conn=1874 op=2 UNBIND May 22 13:46:25 ldap slapd[493]: connection_resched: attempting closing conn=1874 sd=22 May 22 13:46:25 ldap slapd[493]: connection_close: conn=1874 sd=22 May 22 13:46:25 ldap slapd[493]: translucent_connection_destroy May 22 13:46:25 ldap slapd[493]: =>ldap_back_conn_destroy: fetching conn 1874 May 22 13:46:25 ldap slapd[493]: =>ldap_back_conn_destroy: destroying conn 1874 refcnt=0 flags=0x00000101 May 22 13:46:25 ldap slapd[493]: daemon: removing 22 May 22 13:46:25 ldap slapd[493]: conn=1874 fd=22 closed May 22 13:46:25 ldap slapd[493]: daemon: activity on 1 descriptor May 22 13:46:25 ldap slapd[493]: daemon: activity on: May 22 13:46:25 ldap slapd[493]: May 22 13:46:25 ldap slapd[493]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 22 13:46:25 ldap slapd[493]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 22 13:46:25 ldap slapd[493]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 22 13:46:25 ldap slapd[493]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 22 13:46:25 ldap slapd[493]: daemon: epoll: listen=13 active_threads=0 tvp=zero

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