November 2007 - openldap-software

by Gavin Henry

<quote who="Howard Chu"> > Greg Martin wrote: >> I loaded up 2.4.6 for my small home network use. It and the apps >> (phpldapadmin, tikiwiki, Webcalendar) that use it are running fine. >> Sweet! >> >> Now I want to convert to cn=config. I ran: >> >> slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d This is a conversion step. You are converting slapd.conf to slapd.d. ALl you new config is in slapd.d. Nothing more is needed.

15 years, 10 months

2
1
0 / 0

Re: OpenLDAP 2.4

by Pierangelo Masarati

[please keep replies on the list] Allan E. Johannesen wrote: >>>>>> "ando" == Pierangelo Masarati <ando(a)sys-net.it> writes: > >> Allan E. Johannesen wrote: >>> Hmmm. Looking at the code as I type this, perhaps the only evil one is the >>> one with colons and the "0x" hex field. If I change >>> >>> entryCSN: 2002120818:17:53Z#0x0061#0#0000 > > ando> This really looks evil. I think that assert needs to be relaxed into a > ando> run-time error, but I don't really see how that data could have made it > ando> into your database. The old syntax should be allowed, as far as I can > ando> remember. In any case, slapadd should tell you exactly what entry > ando> couldn't be imported, you should be able to check what the offending > ando> entryCSN looks like. > > I don't think it's "evil", but simply "old". I think it's evil because I don't recall the CSN syntax ever being like that. > Unless I was typing in my sleep, > I never put any CSN into the database. I'm not blaming you. > Some version of slapd must have done it. Well, unless you imported that data from some other DSA, I agree it had to be slapd at some point. > I looked at what 2.4.6 does with "old", but "not THAT old", CSNs, That's my point: "THAT old" should not be, that's the reason of that assert: make sure only known formats get there during CSN handling development. Of course, in production a run-time error would be better, since one can never know how and why garbage gets there. In any case, I believe rewriting those CSNs according to either old or new format should solve your problem. Of course, if entryCSN's like that surface again, there must be some piece of software that generates them. In that case, further investigation will be required. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

15 years, 10 months

2
1
0 / 0

OpenLDAP 2.4

by Howard Chu

The Admin Guide still has not been updated with all of the relevant changes, so here are some notes on new features in the 2.4 release... I believe all of the manpages are up to date, so you can get specifics from them. More complete cn=config functionality: There is a new slapd-config(5) manpage for the cn=config backend. the original design called for auto-renaming of config entries when you insert or delete entries with ordered names, but that was not implemented in 2.3. It is now in 2.4. This means, e.g., if you have olcDatabase={1}bdb,cn=config olcSuffix: dc=example,dc=com and you want to add a new subordinate, now you can: ldapadd olcDatabase={1}bdb,cn=config olcSuffix: dc=foo,dc=example,dc=com this will insert a new BDB database in slot 1 and bump all following databases down one, so the original BDB database will now be named olcDatabase={2}bdb,cn=config olcSuffix: dc=example,dc=com In 2.3 you were only able to add new schema elements, not delete or modify existing elements. In 2.4 you can modify schema at will. (Except for the hardcoded system schema, of course.) More sophisticated syncrepl configurations: the original implementation of syncrepl in OpenLDAP 2.2 was intended to support multiple consumers within the same database, but that feature never worked and was removed from OpenLDAP 2.3. I.e., you could only configure a single consumer in any database. In 2.4 you can configure multiple consumers in a single database. The configuration possibilities here are quite complex and numerous. You can configure consumers over arbitrary subtrees of a database (disjoint or overlapping). Any portion of the database may in turn be provided to other consumers using the syncprov overlay. The syncprov overlay works with any number of consumers over a single database or over arbitrarily many glued databases. As a consequence of the work to support multiple consumer contexts, the syncrepl system now supports full N-way multimaster replication with entry-level conflict resolution. There are some important constraints, of course: In order to maintain consistent results across all servers, you must maintain tightly synchronized clocks across all participating servers (e.g., you must use NTP on all servers). The entryCSNs used for replication now record timestamps with microsecond resolution, instead of just seconds. The delta-syncrepl code has not been updated to support multimaster usage yet, that will come later in the 2.4 cycle. On a related note, syncrepl was explicitly disabled on cn=config in 2.3. It is now fully supported in 2.4; you can use syncrepl to replicate an entire server configuration from one server to arbitrarily many other servers. It's possible to clone an entire running slapd using just a small (less than 10 lines) seed configuration, or you can just replicate the schema subtrees, etc. Tests 049 and 050 in the test suite provide working examples of these capabilities. In 2.3 you could configure syncrepl as a full push-mode replicator by using it in conjunction with a back-ldap pointed at the target server. But because the back-ldap database needs to have a suffix corresponding to the target's suffix, you could only configure one instance per slapd. In 2.4 you can define a database to be "hidden" which means that its suffix is ignored when checking for name collisions, and the database will never be used to answer requests received by the frontend. Using this hidden database feature allows you to configure multiple databases with the same suffix, allowing you to set up multiple back-ldap instances for pushing replication of a single database to multiple targets. There may be other uses for hidden databases as well (e.g., using a syncrepl consumer to maintain a *local* mirror of a database on a separate filesystem). More extensive TLS configuration control: In 2.3, the TLS configuration in slapd was only used by the slapd listeners. For outbound connections used by e.g. back-ldap or syncrepl their TLS parameters came from the system's ldap.conf file. In 2.4 all of these sessions inherit their settings from the main slapd configuration but settings can be individually overridden on a per-config-item basis. This is particularly helpful if you use certificate-based authentication and need to use a different client certificate for different destinations. Various performance enhancements: Too many to list. Some notable changes - ldapadd used to be a couple of orders of magnitude slower than "slapadd -q". It's now at worst only about half the speed of slapadd -q. A few weeks ago I did some comparisons of all the 2.x OpenLDAP releases; the results are in the slides from my SCALE presentation and you can find a copy here: http://www.highlandsun.com/hyc/scale2007.pdf That compared 2.0.27, 2.1.30, 2.2.30, 2.3.33, and HEAD (as of a couple weeks ago). Toward the latter end of the "Cached Search Performance" chart it gets hard to see the difference because the runtimes are so small, but the new code is about 25% faster than 2.3, which was about 20% faster than 2.2, which was about 100% faster than 2.1, which was about 100% faster than 2.0, in that particular search scenario. That test basically searched a 1.3GB DB of 380836 entries (all in the slapd entry cache) in under 1 second. i.e., on a 2.4GHz CPU with DDR400 ECC/Registered RAM we can search over 500 thousand entries per second. The search was on an unindexed attribute using a filter that would not match any entry, forcing slapd to examine every entry in the DB, testing the filter for a match. Essentially the slapd entry cache in back-bdb/back-hdb is so efficient the search processing time is almost invisible; the runtime is limited only by the memory bandwidth of the machine. (The search data rate corresponds to about 3.5GB/sec; the memory bandwidth on the machine is only about 4GB/sec due to ECC and register latency.) I think it goes without saying that no other Directory Server in the world is this fast or this efficient. Couple that with the scalability, manageability, flexibility, and just the sheer know-how behind this software, and nothing else is even remotely comparable. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

15 years, 10 months

7
12
0 / 0

how to edit cn=config

by Scott Classen

Hello openldap community, I am using openldap 2.4.6 (recently migrated directly from 2.3.37). I am using this for a very small community of users. I will have maybe 50-60 users. I have recently converted from using slapd.conf to using the slapd.d backend ldap database for configuring my openldap server. I am, however, unclear on the proper method to make changes to my configuration. When using slapd.conf it was fairly straight forward: edit the file with vi and restart slapd. When using slapd.d should I directly edit the various LDIF files within the slapd.d/cn=config folder? This doesn't really seem like the proper way to do things so I haven't done this. I'm fairly certain that I should make ldapmodify style LDIF files, but that can be a bit cumbersome for quick configuration changes. So I've started experimenting with various ldap GUI interfaces (phpldapadmin and JXplorer), thinking that they might display the entire cn=config databse in a human-readable form, but neither returns information about cn=config. Indeed a simple ldapsearch doesn't return any information either. ldapsearch -x -D "uid=bigcheese,dc=my,dc=domain" -W "cn=config" I know that my slapd.d backend is working because I've renamed the slapd.conf file so it is no longer recognized by slapd. Any help or advice would be greatly appreciated. Scott ps I've read both the version 2.3 and 2.4 Administrator's Guide several times.

15 years, 10 months

4
3
0 / 0

matching on inherited attributes

by Maykel Moya

I had created a custom attribute sldMailForwardTo describe mail recipients for a given alias. As sldMailForwardTo is just an email address I made it inherits from mail. The problem is that now, whenever I do a search on mail=foo, entries having foo on sldMailForwardTo are matched too. Do exists a way to avoid that? If no, what are the effective benefits then of having inherited attributes? Using OL 2.3.38. Regards, maykel

15 years, 11 months

2
3
0 / 0

RE: LDAP provisioning error.

by Clowser, Jeff (Contractor)

Just as a refresher, here's your logs from a previous post (had to go back and look em up): Nov 2 11:15:07 pen slapd[18902]: conn=8 op=0 BIND dn="cn=Manager,dc=ncl,dc=ac,dc=uk" method=128 Nov 2 11:15:07 pen slapd[18902]: conn=8 op=0 BIND dn="cn=Manager,dc=ncl,dc=ac,dc=uk" mech=SIMPLE ssf=0 Nov 2 11:15:07 pen slapd[18902]: conn=8 op=0 RESULT tag=97 err=0 text= Nov 2 11:15:07 pen slapd[18902]: conn=8 op=1 SRCH base="ou=people,dc=ncl,dc=ac,dc=uk" scope=2 deref=3 filter="(&(uid=groupersystem)(objectClass=eduPerson))" Nov 2 11:15:07 pen slapd[18902]: conn=8 op=1 SRCH attr=cn cn uid Nov 2 11:15:07 pen slapd[18902]: conn=8 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= Your app is doing a search under "ou=people,dc=ncl,dc=ac,dc=uk" for all entries matching "(&(uid=groupersystem)(objectClass=eduPerson))", and you find no matching entries (which is not surprising, since none of your sample entries match this search criteria). >From your slapcat output below, none of your entries have the uid "groupersystem", so I'm not sure how you expected this to find any matches to put into groups... You say that in another directory server, this worked? With the exact same data? This same data in another ldap server would yield the same results - basically, that there is nothing there to match what you want to find. Given the above search filter "Grouper" performed, and looking at your data from slapcat, which entries do you expect to match, and how do you expect them to match that filter (i.e. in your mind, which entries have a uid of groupersystem AND an objectclass of eduPerson)? Maybe export some matching sample users from the "other" directory server that got put into groups to see the differences, and why that search filter matches on that server and not in OpenLDAP. My guess is that the data is not really the same in both servers. - Jeff -----Original Message----- From: openldap-software-bounces+jeff_clowser=fanniemae.com(a)openldap.org [mailto:openldap-software-bounces+jeff_clowser=fanniemae.com@openldap.or g] On Behalf Of Sanjay Vivek Sent: Tuesday, November 06, 2007 11:28 AM To: Buchan Milne Cc: openldap-software(a)openldap.org Subject: RE: LDAP provisioning error. ... I also did a slapcat and the results are given below: [root@pen openldap]# slapcat dn: dc=ncl,dc=ac,dc=uk description: Top level LDAP for ncl.ac.uk objectClass: top objectClass: dcObject objectClass: organization o: ncl dc: ncl structuralObjectClass: organization entryUUID: 958bf658-d39a-102b-925e-4d93d2b0c899 creatorsName: cn=Manager,dc=ncl,dc=ac,dc=uk createTimestamp: 20070731101436Z entryCSN: 20070731101436Z#000000#00#000000 modifiersName: cn=Manager,dc=ncl,dc=ac,dc=uk modifyTimestamp: 20070731101436Z dn: ou=people,dc=ncl,dc=ac,dc=uk ou: people objectClass: top objectClass: organizationalUnit structuralObjectClass: organizationalUnit entryUUID: 958c9568-d39a-102b-925f-4d93d2b0c899 creatorsName: cn=Manager,dc=ncl,dc=ac,dc=uk createTimestamp: 20070731101436Z entryCSN: 20070731101436Z#000001#00#000000 modifiersName: cn=Manager,dc=ncl,dc=ac,dc=uk modifyTimestamp: 20070731101436Z dn: ou=grouper,dc=ncl,dc=ac,dc=uk objectClass: top objectClass: organizationalUnit ou: grouper structuralObjectClass: organizationalUnit entryUUID: a5afe04c-0b8c-102c-985e-95f106e50073 creatorsName: cn=Manager,dc=ncl,dc=ac,dc=uk createTimestamp: 20071010145555Z description: location in which to root provisioned groups entryCSN: 20071015081104Z#000000#00#000000 modifiersName: cn=Manager,dc=ncl,dc=ac,dc=uk modifyTimestamp: 20071015081104Z dn: uid=gene.wilder(a)hotmail.com,ou=people,dc=ncl,dc=ac,dc=uk objectClass: top objectClass: person objectClass: eduPerson objectClass: organizationalPerson objectClass: inetOrgPerson uid: gene.wilder(a)hotmail.com cn: Gene Wilder sn: Wilder structuralObjectClass: inetOrgPerson entryUUID: 82227ea6-0d20-102c-907a-f35c0beda954 creatorsName: cn=Manager,dc=ncl,dc=ac,dc=uk createTimestamp: 20071012150652Z eduPersonPrincipalName: gene.wilder(a)hotmail.com entryCSN: 20071015124554Z#000000#00#000000 modifiersName: cn=Manager,dc=ncl,dc=ac,dc=uk modifyTimestamp: 20071015124554Z dn: uid=lionel.messi(a)hotmail.com,ou=people,dc=ncl,dc=ac,dc=uk objectClass: top objectClass: person objectClass: eduPerson objectClass: organizationalPerson objectClass: inetOrgPerson uid: lionel.messi(a)hotmail.com cn: Lionel Messi sn: Messi structuralObjectClass: inetOrgPerson entryUUID: 82542780-0d20-102c-907b-f35c0beda954 creatorsName: cn=Manager,dc=ncl,dc=ac,dc=uk createTimestamp: 20071012150652Z eduPersonPrincipalName: lionel.messi(a)hotmail.com entryCSN: 20071015124543Z#000000#00#000000 modifiersName: cn=Manager,dc=ncl,dc=ac,dc=uk modifyTimestamp: 20071015124543Z dn: uid=michael.owen(a)hotmail.com,ou=people,dc=ncl,dc=ac,dc=uk objectClass: top objectClass: person objectClass: eduPerson objectClass: organizationalPerson objectClass: inetOrgPerson uid: michael.owen(a)hotmail.com cn: Michael Owen sn: Owen structuralObjectClass: inetOrgPerson entryUUID: 82850904-0d20-102c-907c-f35c0beda954 creatorsName: cn=Manager,dc=ncl,dc=ac,dc=uk createTimestamp: 20071012150653Z eduPersonPrincipalName: michael.owen(a)hotmail.com entryCSN: 20071015124522Z#000000#00#000000 modifiersName: cn=Manager,dc=ncl,dc=ac,dc=uk modifyTimestamp: 20071015124522Z dn: uid=mariah.carey(a)hotmail.com,ou=people,dc=ncl,dc=ac,dc=uk objectClass: top objectClass: person objectClass: eduPerson objectClass: organizationalPerson objectClass: inetOrgPerson uid: mariah.carey(a)hotmail.com cn: Mariah Carey sn: Carey structuralObjectClass: inetOrgPerson entryUUID: 82b47dba-0d20-102c-907d-f35c0beda954 creatorsName: cn=Manager,dc=ncl,dc=ac,dc=uk createTimestamp: 20071012150653Z eduPersonPrincipalName: mariah.carey(a)hotmail.com entryCSN: 20071015124533Z#000000#00#000000 modifiersName: cn=Manager,dc=ncl,dc=ac,dc=uk modifyTimestamp: 20071015124533Z dn: uid=zizou(a)hotmail.com,ou=people,dc=ncl,dc=ac,dc=uk objectClass: top objectClass: person objectClass: eduPerson objectClass: organizationalPerson objectClass: inetOrgPerson uid: zizou(a)hotmail.com cn: Zinedine Zindane sn: Zindane structuralObjectClass: inetOrgPerson entryUUID: 82dfb08e-0d20-102c-907e-f35c0beda954 creatorsName: cn=Manager,dc=ncl,dc=ac,dc=uk createTimestamp: 20071012150653Z eduPersonPrincipalName: zizou(a)hotmail.com entryCSN: 20071015124432Z#000000#00#000000 modifiersName: cn=Manager,dc=ncl,dc=ac,dc=uk modifyTimestamp: 20071015124432Z dn: uid=carlos.tevez(a)hotmail.com,ou=people,dc=ncl,dc=ac,dc=uk objectClass: top objectClass: person objectClass: eduPerson objectClass: organizationalPerson objectClass: inetOrgPerson uid: carlos.tevez(a)hotmail.com cn: Carlos Tevez sn: Tevez structuralObjectClass: inetOrgPerson entryUUID: 83166124-0d20-102c-907f-f35c0beda954 creatorsName: cn=Manager,dc=ncl,dc=ac,dc=uk createTimestamp: 20071012150653Z eduPersonPrincipalName: carlos.tevez(a)hotmail.com entryCSN: 20071015124621Z#000000#00#000000 modifiersName: cn=Manager,dc=ncl,dc=ac,dc=uk modifyTimestamp: 20071015124621Z dn: uid=gael.clichy(a)hotmail.com,ou=people,dc=ncl,dc=ac,dc=uk objectClass: top objectClass: person objectClass: eduPerson objectClass: organizationalPerson objectClass: inetOrgPerson uid: gael.clichy(a)hotmail.com cn: Gael Clichy sn: Clichy structuralObjectClass: inetOrgPerson entryUUID: 834a1a50-0d20-102c-9080-f35c0beda954 creatorsName: cn=Manager,dc=ncl,dc=ac,dc=uk createTimestamp: 20071012150654Z eduPersonPrincipalName: gael.clichy(a)hotmail.com entryCSN: 20071015124610Z#000000#00#000000 modifiersName: cn=Manager,dc=ncl,dc=ac,dc=uk modifyTimestamp: 20071015124610Z dn: uid=obi.martins(a)hotmail.com,ou=people,dc=ncl,dc=ac,dc=uk objectClass: top objectClass: person objectClass: eduPerson objectClass: organizationalPerson objectClass: inetOrgPerson uid: obi.martins(a)hotmail.com structuralObjectClass: inetOrgPerson entryUUID: 8376746a-0d20-102c-9081-f35c0beda954 creatorsName: cn=Manager,dc=ncl,dc=ac,dc=uk createTimestamp: 20071012150654Z eduPersonPrincipalName: obi.martins(a)hotmail.com sn: Martins cn: Obi Martins entryCSN: 20071015124507Z#000000#00#000000 modifiersName: cn=Manager,dc=ncl,dc=ac,dc=uk modifyTimestamp: 20071015124507Z As the results above indicate, there are 2 ou's (ou=grouper and ou=people). And there are 8 sample users under ou=people. So basically what's supposed to happen is for the provisioning program to provision the Grouper groups to "ou=grouper,dc=ncl,dc=ac,dc=uk" and it looks for the users in each group under "ou=people,dc=ncl,dc=ac,dc=uk". This is where the LDAP search filter comes in. The search filter looks for the users under "ou=people,dc=ncl,dc=ac,dc=uk". Something stops Grouper from provisioning the groups over to the LDAP server and I still believe it's something to do with my openLDAP configuration. My Grouper installation/configuration has been replicated on another server and everything seems to be working fine. Cheers. Regards Sanjay >-----Original Message----- >From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net] >Sent: 06 November 2007 15:27 >To: Sanjay Vivek >Cc: openldap-software(a)openldap.org >Subject: Re: LDAP provisioning error. > >On Tuesday 06 November 2007 16:49:29 Sanjay Vivek wrote: >> Hi again, >> >> I don't think the errors have anything to with the LDAP >search filter >> because it works perfectly fine with a similar installation with >> another LDAP server. The only difference between both installions is >> the LDAP server. So something about my openLDAP configuration is >> messing up the LDAP provisioning. > >But thus far you haven't provided anything that anyone can use >to try and find out what is wrong with your configuration. >Please try and include logs relating to all the operations on >a connection, where an ADD, MOD, or DEL operation is done on >the connection. A connection with one bind and one search, is >almost useless (unless you can show the data in the directory >that should be found by that search). > >> >> I did a "ps -fade | grep slapd" >> >> [root@pen openldap]# ps -fade | grep slapd >> ldap 29465 1 0 11:51 ? 00:00:00 /usr/sbin/slapd -h >> ldap:/// -u ldap >> root 29616 28950 0 13:53 pts/0 00:00:00 grep slapd >> >> So this means that only one instance of slapd is running. > >BUT YOU ARE NOW ABOUT TO TRY TO START A SECOND ONE!!!!! > >> So why do I >> get a "daemon: bind(7) failed errno=98 (Address already in >use)" error >> when I run "slapd -d acl" as shown below: >> >> [root@pen openldap]# slapd -d acl > >But, this is starting slapd. By default, it will try and bind >to port 389 on all IPs. So, you should stop this one, if you >*really* want to start a slapd as above. Instead, maybe you should add: > >loglevel acl > >and restart the ldap service ('service ldap restart'), and >then (if your syslog is configured to log for slapd) you >should end up with acl-related entries in your log files. > > >Regards, >Buchan >

15 years, 11 months

1
0
0 / 0

LDAP provisioning error.

by Sanjay Vivek

Hello everyone, I'm involved in a project whereby access groups (with users) are provisioned to a LDAP server. In a nutshell, the groups should be provisioned under ""ou=groups,dc=ncl,dc=ac,dc=uk" while the users in each group are found in ""ou=people,dc=ncl,dc=ac,dc=uk". However, the groups are not being provisioned over to our LDAP server. Among the dubious looking lines in the log files include: bdb_search: 134 does not match filter (the above entry should match the filter. And similiarly for other entries) I'm guessing this has something to do with the ACL control list in slapd.conf. The relevant section in slapd.conf is given below: # Allow anyone to write and read to ou=people access to dn.one="ou=people,dc=ncl,dc=ac,dc=uk" attr=children by anonymous read by anonymous write # Allow anyone to write and read to ou=grouper access to dn.one="ou=grouper,dc=ncl,dc=ac,dc=uk" attr=children by anonymous read by anonymous write So basically what the above configuration is meant to do is that anyone can read or write to one level below both people and grouper. I realise this is highly insecure but it's merely for testing purposes. Any suggestions or help would be greatly appreciated. The complete logs of this transaction is given below. Thanks again. Cheers Sanjay Oct 16 15:13:34 pen slapd[9559]: daemon: activity on 1 descriptor Oct 16 15:13:34 pen slapd[9559]: daemon: activity on: Oct 16 15:13:34 pen slapd[9559]: Oct 16 15:13:34 pen slapd[9559]: daemon: listen=8, new connection on 13 Oct 16 15:13:34 pen slapd[9559]: daemon: added 13r Oct 16 15:13:34 pen slapd[9559]: conn=8 fd=13 ACCEPT from IP=128.240.2.3:51855 (IP=0.0.0.0:389) Oct 16 15:13:34 pen slapd[9559]: daemon: select: listen=7 active_threads=0 tvp=NULL Oct 16 15:13:34 pen slapd[9559]: daemon: select: listen=8 active_threads=0 tvp=NULL Oct 16 15:13:34 pen slapd[9559]: daemon: activity on 1 descriptor Oct 16 15:13:34 pen slapd[9559]: daemon: activity on: Oct 16 15:13:34 pen slapd[9559]: 13r Oct 16 15:13:34 pen slapd[9559]: Oct 16 15:13:34 pen slapd[9559]: daemon: read active on 13 Oct 16 15:13:34 pen slapd[9559]: connection_get(13) Oct 16 15:13:34 pen slapd[9559]: connection_get(13): got connid=8 Oct 16 15:13:34 pen slapd[9559]: connection_read(13): checking for input on id=8 Oct 16 15:13:34 pen slapd[9559]: ber_get_next on fd 13 failed errno=11 (Resource temporarily unavailable) Oct 16 15:13:34 pen slapd[9559]: daemon: select: listen=7 active_threads=0 tvp=NULL Oct 16 15:13:34 pen slapd[9559]: daemon: select: listen=8 active_threads=0 tvp=NULL Oct 16 15:13:34 pen slapd[9559]: do_bind Oct 16 15:13:34 pen slapd[9559]: >>> dnPrettyNormal: <cn=Manager,dc=ncl,dc=ac,dc=uk> Oct 16 15:13:34 pen slapd[9559]: <<< dnPrettyNormal: <cn=Manager,dc=ncl,dc=ac,dc=uk>, <cn=manager,dc=ncl,dc=ac,dc=uk> Oct 16 15:13:34 pen slapd[9559]: do_bind: version=3 dn="cn=Manager,dc=ncl,dc=ac,dc=uk" method=128 Oct 16 15:13:34 pen slapd[9559]: conn=8 op=0 BIND dn="cn=Manager,dc=ncl,dc=ac,dc=uk" method=128 Oct 16 15:13:34 pen slapd[9559]: ==> bdb_bind: dn: cn=Manager,dc=ncl,dc=ac,dc=uk Oct 16 15:13:34 pen slapd[9559]: conn=8 op=0 BIND dn="cn=Manager,dc=ncl,dc=ac,dc=uk" mech=SIMPLE ssf=0 Oct 16 15:13:34 pen slapd[9559]: do_bind: v3 bind: "cn=Manager,dc=ncl,dc=ac,dc=uk" to "cn=Manager,dc=ncl,dc=ac,dc=uk" Oct 16 15:13:34 pen slapd[9559]: send_ldap_result: conn=8 op=0 p=3 Oct 16 15:13:34 pen slapd[9559]: send_ldap_result: err=0 matched="" text="" Oct 16 15:13:34 pen slapd[9559]: send_ldap_response: msgid=1 tag=97 err=0 Oct 16 15:13:34 pen slapd[9559]: conn=8 op=0 RESULT tag=97 err=0 text= Oct 16 15:13:34 pen slapd[9559]: daemon: activity on 1 descriptor Oct 16 15:13:34 pen slapd[9559]: daemon: activity on: Oct 16 15:13:34 pen slapd[9559]: Oct 16 15:13:34 pen slapd[9559]: daemon: listen=8, new connection on 15 Oct 16 15:13:34 pen slapd[9559]: daemon: added 15r Oct 16 15:13:34 pen slapd[9559]: conn=9 fd=15 ACCEPT from IP=128.240.2.3:36766 (IP=0.0.0.0:389) Oct 16 15:13:34 pen slapd[9559]: daemon: select: listen=7 active_threads=0 tvp=NULL Oct 16 15:13:34 pen slapd[9559]: daemon: select: listen=8 active_threads=0 tvp=NULL Oct 16 15:13:34 pen slapd[9559]: daemon: activity on 1 descriptor Oct 16 15:13:34 pen slapd[9559]: daemon: activity on: Oct 16 15:13:34 pen slapd[9559]: 15r Oct 16 15:13:34 pen slapd[9559]: Oct 16 15:13:34 pen slapd[9559]: daemon: read active on 15 Oct 16 15:13:34 pen slapd[9559]: connection_get(15) Oct 16 15:13:34 pen slapd[9559]: connection_get(15): got connid=9 Oct 16 15:13:34 pen slapd[9559]: connection_read(15): checking for input on id=9 Oct 16 15:13:34 pen slapd[9559]: ber_get_next on fd 15 failed errno=11 (Resource temporarily unavailable) Oct 16 15:13:34 pen slapd[9559]: daemon: select: listen=7 active_threads=0 tvp=NULL Oct 16 15:13:34 pen slapd[9559]: daemon: select: listen=8 active_threads=0 tvp=NULL Oct 16 15:13:34 pen slapd[9559]: do_bind Oct 16 15:13:34 pen slapd[9559]: >>> dnPrettyNormal: <cn=Manager,dc=ncl,dc=ac,dc=uk> Oct 16 15:13:34 pen slapd[9559]: <<< dnPrettyNormal: <cn=Manager,dc=ncl,dc=ac,dc=uk>, <cn=manager,dc=ncl,dc=ac,dc=uk> Oct 16 15:13:34 pen slapd[9559]: do_bind: version=3 dn="cn=Manager,dc=ncl,dc=ac,dc=uk" method=128 Oct 16 15:13:34 pen slapd[9559]: conn=9 op=0 BIND dn="cn=Manager,dc=ncl,dc=ac,dc=uk" method=128 Oct 16 15:13:34 pen slapd[9559]: ==> bdb_bind: dn: cn=Manager,dc=ncl,dc=ac,dc=uk Oct 16 15:13:34 pen slapd[9559]: conn=9 op=0 BIND dn="cn=Manager,dc=ncl,dc=ac,dc=uk" mech=SIMPLE ssf=0 Oct 16 15:13:34 pen slapd[9559]: do_bind: v3 bind: "cn=Manager,dc=ncl,dc=ac,dc=uk" to "cn=Manager,dc=ncl,dc=ac,dc=uk" Oct 16 15:13:34 pen slapd[9559]: send_ldap_result: conn=9 op=0 p=3 Oct 16 15:13:34 pen slapd[9559]: send_ldap_result: err=0 matched="" text="" Oct 16 15:13:34 pen slapd[9559]: send_ldap_response: msgid=1 tag=97 err=0 Oct 16 15:13:34 pen slapd[9559]: conn=9 op=0 RESULT tag=97 err=0 text= Oct 16 15:13:34 pen slapd[9559]: daemon: activity on 1 descriptor Oct 16 15:13:34 pen slapd[9559]: daemon: activity on: Oct 16 15:13:34 pen slapd[9559]: 15r Oct 16 15:13:34 pen slapd[9559]: Oct 16 15:13:34 pen slapd[9559]: daemon: read active on 15 Oct 16 15:13:34 pen slapd[9559]: connection_get(15) Oct 16 15:13:34 pen slapd[9559]: connection_get(15): got connid=9 Oct 16 15:13:34 pen slapd[9559]: connection_read(15): checking for input on id=9 Oct 16 15:13:34 pen slapd[9559]: ber_get_next on fd 15 failed errno=0 (Success) Oct 16 15:13:34 pen slapd[9559]: connection_read(15): input error=-2 id=9, closing. Oct 16 15:13:34 pen slapd[9559]: connection_closing: readying conn=9 sd=15 for close Oct 16 15:13:34 pen slapd[9559]: connection_close: deferring conn=9 sd=15 Oct 16 15:13:34 pen slapd[9559]: daemon: select: listen=7 active_threads=0 tvp=NULL Oct 16 15:13:34 pen slapd[9559]: daemon: select: listen=8 active_threads=0 tvp=NULL Oct 16 15:13:34 pen slapd[9559]: daemon: activity on 1 descriptor Oct 16 15:13:34 pen slapd[9559]: daemon: activity on: Oct 16 15:13:34 pen slapd[9559]: Oct 16 15:13:34 pen slapd[9559]: daemon: select: listen=7 active_threads=0 tvp=NULL Oct 16 15:13:34 pen slapd[9559]: daemon: select: listen=8 active_threads=0 tvp=NULL Oct 16 15:13:34 pen slapd[9559]: do_unbind Oct 16 15:13:34 pen slapd[9559]: conn=9 op=1 UNBIND Oct 16 15:13:34 pen slapd[9559]: connection_resched: attempting closing conn=9 sd=15 Oct 16 15:13:34 pen slapd[9559]: connection_close: conn=9 sd=15 Oct 16 15:13:34 pen slapd[9559]: daemon: removing 15 Oct 16 15:13:34 pen slapd[9559]: conn=9 fd=15 closed Oct 16 15:13:35 pen slapd[9559]: daemon: activity on 1 descriptor Oct 16 15:13:35 pen slapd[9559]: daemon: activity on: Oct 16 15:13:35 pen slapd[9559]: Oct 16 15:13:35 pen slapd[9559]: daemon: listen=8, new connection on 15 Oct 16 15:13:35 pen slapd[9559]: daemon: added 15r Oct 16 15:13:35 pen slapd[9559]: conn=10 fd=15 ACCEPT from IP=128.240.2.3:50097 (IP=0.0.0.0:389) Oct 16 15:13:35 pen slapd[9559]: daemon: select: listen=7 active_threads=0 tvp=NULL Oct 16 15:13:35 pen slapd[9559]: daemon: select: listen=8 active_threads=0 tvp=NULL Oct 16 15:13:35 pen slapd[9559]: daemon: activity on 1 descriptor Oct 16 15:13:35 pen slapd[9559]: daemon: activity on: Oct 16 15:13:35 pen slapd[9559]: 15r Oct 16 15:13:35 pen slapd[9559]: Oct 16 15:13:35 pen slapd[9559]: daemon: read active on 15 Oct 16 15:13:35 pen slapd[9559]: connection_get(15) Oct 16 15:13:35 pen slapd[9559]: connection_get(15): got connid=10 Oct 16 15:13:35 pen slapd[9559]: connection_read(15): checking for input on id=10 Oct 16 15:13:35 pen slapd[9559]: ber_get_next on fd 15 failed errno=11 (Resource temporarily unavailable) Oct 16 15:13:35 pen slapd[9559]: daemon: select: listen=7 active_threads=0 tvp=NULL Oct 16 15:13:35 pen slapd[9559]: daemon: select: listen=8 active_threads=0 tvp=NULL Oct 16 15:13:35 pen slapd[9559]: do_bind Oct 16 15:13:35 pen slapd[9559]: >>> dnPrettyNormal: <cn=Manager,dc=ncl,dc=ac,dc=uk> Oct 16 15:13:35 pen slapd[9559]: <<< dnPrettyNormal: <cn=Manager,dc=ncl,dc=ac,dc=uk>, <cn=manager,dc=ncl,dc=ac,dc=uk> Oct 16 15:13:35 pen slapd[9559]: do_bind: version=3 dn="cn=Manager,dc=ncl,dc=ac,dc=uk" method=128 Oct 16 15:13:35 pen slapd[9559]: conn=10 op=0 BIND dn="cn=Manager,dc=ncl,dc=ac,dc=uk" method=128 Oct 16 15:13:35 pen slapd[9559]: ==> bdb_bind: dn: cn=Manager,dc=ncl,dc=ac,dc=uk Oct 16 15:13:35 pen slapd[9559]: conn=10 op=0 BIND dn="cn=Manager,dc=ncl,dc=ac,dc=uk" mech=SIMPLE ssf=0 Oct 16 15:13:35 pen slapd[9559]: do_bind: v3 bind: "cn=Manager,dc=ncl,dc=ac,dc=uk" to "cn=Manager,dc=ncl,dc=ac,dc=uk" Oct 16 15:13:35 pen slapd[9559]: send_ldap_result: conn=10 op=0 p=3 Oct 16 15:13:35 pen slapd[9559]: send_ldap_result: err=0 matched="" text="" Oct 16 15:13:35 pen slapd[9559]: send_ldap_response: msgid=1 tag=97 err=0 Oct 16 15:13:35 pen slapd[9559]: conn=10 op=0 RESULT tag=97 err=0 text= Oct 16 15:13:35 pen slapd[9559]: daemon: activity on 1 descriptor Oct 16 15:13:35 pen slapd[9559]: daemon: activity on: Oct 16 15:13:35 pen slapd[9559]: 15r Oct 16 15:13:35 pen slapd[9559]: Oct 16 15:13:35 pen slapd[9559]: daemon: read active on 15 Oct 16 15:13:35 pen slapd[9559]: connection_get(15) Oct 16 15:13:35 pen slapd[9559]: connection_get(15): got connid=10 Oct 16 15:13:35 pen slapd[9559]: connection_read(15): checking for input on id=10 Oct 16 15:13:35 pen slapd[9559]: ber_get_next on fd 15 failed errno=11 (Resource temporarily unavailable) Oct 16 15:13:35 pen slapd[9559]: daemon: select: listen=7 active_threads=0 tvp=NULL Oct 16 15:13:35 pen slapd[9559]: daemon: select: listen=8 active_threads=0 tvp=NULL Oct 16 15:13:35 pen slapd[9559]: do_search Oct 16 15:13:35 pen slapd[9559]: >>> dnPrettyNormal: <ou=people,dc=ncl,dc=ac,dc=uk> Oct 16 15:13:35 pen slapd[9559]: <<< dnPrettyNormal: <ou=people,dc=ncl,dc=ac,dc=uk>, <ou=people,dc=ncl,dc=ac,dc=uk> Oct 16 15:13:35 pen slapd[9559]: SRCH "ou=people,dc=ncl,dc=ac,dc=uk" 2 3 Oct 16 15:13:35 pen slapd[9559]: 0 0 0 Oct 16 15:13:35 pen slapd[9559]: begin get_filter Oct 16 15:13:35 pen slapd[9559]: AND Oct 16 15:13:35 pen slapd[9559]: begin get_filter_list Oct 16 15:13:35 pen slapd[9559]: begin get_filter Oct 16 15:13:35 pen slapd[9559]: EQUALITY Oct 16 15:13:35 pen slapd[9559]: end get_filter 0 Oct 16 15:13:35 pen slapd[9559]: begin get_filter Oct 16 15:13:35 pen slapd[9559]: EQUALITY Oct 16 15:13:35 pen slapd[9559]: end get_filter 0 Oct 16 15:13:35 pen slapd[9559]: end get_filter_list Oct 16 15:13:35 pen slapd[9559]: end get_filter 0 Oct 16 15:13:35 pen slapd[9559]: filter: (&(eduPersonPrincipalName=groupersystem)(objectClass=eduPerson)) Oct 16 15:13:35 pen slapd[9559]: => get_ctrls Oct 16 15:13:35 pen slapd[9559]: => get_ctrls: oid="2.16.840.1.113730.3.4.2" (noncritical) Oct 16 15:13:35 pen slapd[9559]: <= get_ctrls: n=1 rc=0 err="" Oct 16 15:13:35 pen slapd[9559]: attrs: Oct 16 15:13:35 pen slapd[9559]: cn Oct 16 15:13:35 pen slapd[9559]: cn Oct 16 15:13:35 pen slapd[9559]: eduPersonPrincipalName Oct 16 15:13:35 pen slapd[9559]: Oct 16 15:13:35 pen slapd[9559]: conn=10 op=1 SRCH base="ou=people,dc=ncl,dc=ac,dc=uk" scope=2 deref=3 filter="(&(eduPersonPrincipalName=groupersystem)(objectClass=eduPerson)) " Oct 16 15:13:35 pen slapd[9559]: conn=10 op=1 SRCH attr=cn cn eduPersonPrincipalName Oct 16 15:13:35 pen slapd[9559]: slap_global_control: unavailable control: 2.16.840.1.113730.3.4.2 Oct 16 15:13:35 pen slapd[9559]: => bdb_search Oct 16 15:13:35 pen slapd[9559]: bdb_dn2entry("ou=people,dc=ncl,dc=ac,dc=uk") Oct 16 15:13:35 pen slapd[9559]: search_candidates: base="ou=people,dc=ncl,dc=ac,dc=uk" (0x0000004d) scope=2 Oct 16 15:13:35 pen slapd[9559]: => bdb_filter_candidates Oct 16 15:13:35 pen slapd[9559]: EQUALITY Oct 16 15:13:35 pen slapd[9559]: => bdb_equality_candidates (objectClass) Oct 16 15:13:35 pen slapd[9559]: => key_read Oct 16 15:13:35 pen slapd[9559]: bdb_idl_fetch_key: [01872a84] Oct 16 15:13:35 pen slapd[9559]: <= bdb_index_read: failed (-30989) Oct 16 15:13:35 pen slapd[9559]: <= bdb_equality_candidates: id=0, first=0, last=0 Oct 16 15:13:35 pen slapd[9559]: <= bdb_filter_candidates: id=0 first=0 last=0 Oct 16 15:13:35 pen slapd[9559]: => bdb_dn2idl("ou=people,dc=ncl,dc=ac,dc=uk") Oct 16 15:13:35 pen slapd[9559]: bdb_idl_fetch_key: @ou=people,dc=ncl,dc=ac,dc=uk Oct 16 15:13:35 pen slapd[9559]: <= bdb_dn2idl: id=9 first=77 last=135 Oct 16 15:13:35 pen slapd[9559]: => bdb_filter_candidates Oct 16 15:13:35 pen slapd[9559]: AND Oct 16 15:13:35 pen slapd[9559]: => bdb_list_candidates 0xa0 Oct 16 15:13:35 pen slapd[9559]: => bdb_filter_candidates Oct 16 15:13:35 pen slapd[9559]: AND Oct 16 15:13:35 pen slapd[9559]: => bdb_list_candidates 0xa0 Oct 16 15:13:35 pen slapd[9559]: => bdb_filter_candidates Oct 16 15:13:35 pen slapd[9559]: EQUALITY Oct 16 15:13:35 pen slapd[9559]: => bdb_equality_candidates (eduPersonPrincipalName) Oct 16 15:13:35 pen slapd[9559]: <= bdb_equality_candidates: (eduPersonPrincipalName) index_param failed (18) Oct 16 15:13:35 pen slapd[9559]: <= bdb_filter_candidates: id=-1 first=1 last=135 Oct 16 15:13:35 pen slapd[9559]: => bdb_filter_candidates Oct 16 15:13:35 pen slapd[9559]: EQUALITY Oct 16 15:13:35 pen slapd[9559]: => bdb_equality_candidates (objectClass) Oct 16 15:13:35 pen slapd[9559]: => key_read Oct 16 15:13:35 pen slapd[9559]: bdb_idl_fetch_key: [aef9a643] Oct 16 15:13:35 pen slapd[9559]: <= bdb_index_read 8 candidates Oct 16 15:13:35 pen slapd[9559]: <= bdb_equality_candidates: id=8, first=128, last=135 Oct 16 15:13:35 pen slapd[9559]: <= bdb_filter_candidates: id=8 first=128 last=135 Oct 16 15:13:35 pen slapd[9559]: <= bdb_list_candidates: id=-1 first=128 last=135 Oct 16 15:13:35 pen slapd[9559]: <= bdb_filter_candidates: id=-1 first=128 last=135 Oct 16 15:13:35 pen slapd[9559]: <= bdb_list_candidates: id=8 first=128 last=135 Oct 16 15:13:35 pen slapd[9559]: <= bdb_filter_candidates: id=8 first=128 last=135 Oct 16 15:13:35 pen slapd[9559]: bdb_search_candidates: id=8 first=128 last=135 Oct 16 15:13:35 pen slapd[9559]: => test_filter Oct 16 15:13:35 pen slapd[9559]: AND Oct 16 15:13:35 pen slapd[9559]: => test_filter_and Oct 16 15:13:35 pen slapd[9559]: => test_filter Oct 16 15:13:35 pen slapd[9559]: EQUALITY Oct 16 15:13:35 pen slapd[9559]: => access_allowed: search access to "uid=gene.wilder(a)hotmail.com,ou=people,dc=ncl,dc=ac,dc=uk" "eduPersonPrincipalName" requested Oct 16 15:13:35 pen slapd[9559]: <= root access granted Oct 16 15:13:35 pen slapd[9559]: <= test_filter 5 Oct 16 15:13:35 pen slapd[9559]: <= test_filter_and 5 Oct 16 15:13:35 pen slapd[9559]: <= test_filter 5 Oct 16 15:13:35 pen slapd[9559]: bdb_search: 128 does not match filter Oct 16 15:13:35 pen slapd[9559]: => test_filter Oct 16 15:13:35 pen slapd[9559]: AND Oct 16 15:13:35 pen slapd[9559]: => test_filter_and Oct 16 15:13:35 pen slapd[9559]: => test_filter Oct 16 15:13:35 pen slapd[9559]: EQUALITY Oct 16 15:13:35 pen slapd[9559]: => access_allowed: search access to "uid=lionel.messi(a)hotmail.com,ou=people,dc=ncl,dc=ac,dc=uk" "eduPersonPrincipalName" requested Oct 16 15:13:35 pen slapd[9559]: <= root access granted Oct 16 15:13:35 pen slapd[9559]: <= test_filter 5 Oct 16 15:13:35 pen slapd[9559]: <= test_filter_and 5 Oct 16 15:13:35 pen slapd[9559]: <= test_filter 5 Oct 16 15:13:35 pen slapd[9559]: bdb_search: 135 does not match filter Oct 16 15:13:35 pen slapd[9559]: send_ldap_result: conn=10 op=1 p=3 Oct 16 15:13:35 pen slapd[9559]: send_ldap_result: err=0 matched="" text="" Oct 16 15:13:35 pen slapd[9559]: send_ldap_response: msgid=2 tag=101 err=0 Oct 16 15:13:35 pen slapd[9559]: conn=10 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= Oct 16 15:13:35 pen slapd[9559]: daemon: activity on 1 descriptor Oct 16 15:13:35 pen slapd[9559]: daemon: activity on: Oct 16 15:13:35 pen slapd[9559]: 15r Oct 16 15:13:35 pen slapd[9559]: Oct 16 15:13:35 pen slapd[9559]: daemon: read active on 15 Oct 16 15:13:35 pen slapd[9559]: connection_get(15) Oct 16 15:13:35 pen slapd[9559]: connection_get(15): got connid=10 Oct 16 15:13:35 pen slapd[9559]: connection_read(15): checking for input on id=10 Oct 16 15:13:35 pen slapd[9559]: ber_get_next on fd 15 failed errno=0 (Success) Oct 16 15:13:35 pen slapd[9559]: connection_read(15): input error=-2 id=10, closing. Oct 16 15:13:35 pen slapd[9559]: connection_closing: readying conn=10 sd=15 for close Oct 16 15:13:35 pen slapd[9559]: connection_close: deferring conn=10 sd=15 Oct 16 15:13:35 pen slapd[9559]: daemon: select: listen=7 active_threads=0 tvp=NULL Oct 16 15:13:35 pen slapd[9559]: daemon: select: listen=8 active_threads=0 tvp=NULL Oct 16 15:13:35 pen slapd[9559]: daemon: activity on 1 descriptor Oct 16 15:13:35 pen slapd[9559]: daemon: activity on: Oct 16 15:13:35 pen slapd[9559]: Oct 16 15:13:35 pen slapd[9559]: daemon: select: listen=7 active_threads=0 tvp=NULL Oct 16 15:13:35 pen slapd[9559]: daemon: select: listen=8 active_threads=0 tvp=NULL Oct 16 15:13:35 pen slapd[9559]: do_unbind Oct 16 15:13:35 pen slapd[9559]: conn=10 op=2 UNBIND Oct 16 15:13:35 pen slapd[9559]: connection_resched: attempting closing conn=10 sd=15 Oct 16 15:13:35 pen slapd[9559]: connection_close: conn=10 sd=15 Oct 16 15:13:35 pen slapd[9559]: daemon: removing 15 Oct 16 15:13:35 pen slapd[9559]: conn=10 fd=15 closed Oct 16 15:13:35 pen slapd[9559]: daemon: activity on 1 descriptor Oct 16 15:13:35 pen slapd[9559]: daemon: activity on: Oct 16 15:13:35 pen slapd[9559]: 13r Oct 16 15:13:35 pen slapd[9559]: Oct 16 15:13:35 pen slapd[9559]: daemon: read active on 13 Oct 16 15:13:35 pen slapd[9559]: connection_get(13) Oct 16 15:13:35 pen slapd[9559]: connection_get(13): got connid=8 Oct 16 15:13:35 pen slapd[9559]: connection_read(13): checking for input on id=8 Oct 16 15:13:35 pen slapd[9559]: ber_get_next on fd 13 failed errno=11 (Resource temporarily unavailable) Oct 16 15:13:35 pen slapd[9559]: daemon: select: listen=7 active_threads=0 tvp=NULL Oct 16 15:13:35 pen slapd[9559]: daemon: select: listen=8 active_threads=0 tvp=NULL Oct 16 15:13:35 pen slapd[9559]: do_unbind Oct 16 15:13:35 pen slapd[9559]: conn=8 op=1 UNBIND Oct 16 15:13:35 pen slapd[9559]: connection_closing: readying conn=8 sd=13 for close Oct 16 15:13:35 pen slapd[9559]: connection_resched: attempting closing conn=8 sd=13 Oct 16 15:13:35 pen slapd[9559]: connection_close: conn=8 sd=13 Oct 16 15:13:35 pen slapd[9559]: daemon: removing 13 Oct 16 15:13:35 pen slapd[9559]: conn=8 fd=13 closed Oct 16 15:13:35 pen slapd[9559]: daemon: activity on 1 descriptor Oct 16 15:13:35 pen slapd[9559]: daemon: activity on: Oct 16 15:13:35 pen slapd[9559]: 13r Oct 16 15:13:35 pen slapd[9559]: Oct 16 15:13:35 pen slapd[9559]: daemon: read active on 13 Oct 16 15:13:35 pen slapd[9559]: connection_get(13) Oct 16 15:13:35 pen slapd[9559]: connection_get(13): connection not used Oct 16 15:13:35 pen slapd[9559]: connection_read(13): no connection! Oct 16 15:13:35 pen slapd[9559]: daemon: select: listen=7 active_threads=0 tvp=NULL Oct 16 15:13:35 pen slapd[9559]: daemon: select: listen=8 active_threads=0 tvp=NULL Oct 16 15:13:35 pen slapd[9559]: daemon: activity on 1 descriptor Oct 16 15:13:35 pen slapd[9559]: daemon: activity on: Oct 16 15:13:35 pen slapd[9559]: Oct 16 15:13:35 pen slapd[9559]: daemon: select: listen=7 active_threads=0 tvp=NULL Oct 16 15:13:35 pen slapd[9559]: daemon: select: listen=8 active_threads=0 tvp=NULL Regards -------------- Sanjay Vivek Middleware Team ISS University of Newcastle Upon Tyne

15 years, 11 months

5
11
0 / 0

Atomicity of on-the-fly updates of ACL entries (using ldapmodify)?

by Romain Komorn

How atomic are changes made to database entries with the following type of LDIFs: dn: olcDatabase={1}bdb,cn=config changetype: modify add: olcAccess olcAccess: {100}to <what> by <who> read olcAccess: {65000}to <what> by <who> none Does ldapmodify simply add/remove attributes on the fly, or does it get the whole entry, then update a new one in? This may become significant if there are a large number of ACLs. If the update is not atomic, is there a potential for problems if the list of ACLs becomes large (ie: 200 <whats> with an average of 10 <whos> each) ? Background: The aim here is to leverage nss_ldap and olcAccess entries to manage access to servers while maintaining control of which accounts appear on which servers via OpenLDAP, rather than filters on the client side. This is to prevent servers that have been misconfigured or (maliciously) modified from being able to gain read access to user entries other than the ones explicitly allowed by the directory. IMO, a client server being able to pick who should be allowed to log on defeats the purpose of centrally managed logins. Romain Komorn

15 years, 11 months

3
3
0 / 0

OpenLDAP as a SASL backend

by Zohar Lev Shani

Hello list I am trying to use OpenLDAP also as a repository of the user and password to the SASL mechanism. The problem I am facing is that it only works if the userPassword is kept in clear text and not in a hashed form. I would like to use the hashed form because my application has a proprietary backend where the data goes over the wire and for that I need userPassword attribute to be not in clear text. Below is what I tried to do, based on OpenLDAP 2.3.24 running on RH4 U3 (Nahant). Any help will be appreciated. Zohar > ./configure --prefix=`pwd` I added to the default slapd.conf with this entry authz-regexp "uid=([^,]*)" "cn=$1,cn=users,dc=my-domain,dc=com" The run command > ./slapd -f slapd.conf -d -1 -h ldap://localhost:9999 1>& slapd.log 2>&1 & Available SASL mechanism > ldapsearch -h localhost:9999 -x -b '' supportedSASLMechanisms -s base -LLL dn: supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: NTLM Data I am going to add > cat ./new_user.ldif dn: dc=my-domain,dc=com objectclass: dcObject objectclass: organization o: my-org dc: my-domain dn: cn=Manager,dc=my-domain,dc=com objectclass: organizationalRole cn: Manager dn: cn=users,dc=my-domain,dc=com objectclass: organizationalRole cn: users dn: cn=user1,cn=users,dc=my-domain,dc=com objectclass: organizationalRole objectclass: simpleSecurityObject cn: user1 userPassword: {MD5}pyLGPbjshiWvbPccuMLZOQ== #password: pass1 dn: cn=user3,cn=users,dc=my-domain,dc=com objectclass: organizationalRole objectclass: simpleSecurityObject cn: user3 userPassword: {CLEARTEXT}pass3 > ldapadd -h localhost:9999 -x -w secret -D cn=Manager,dc=my-domain,dc=com -f ./new_user.ldif > ldapsearch -h localhost:9999 -x -LLL -b cn=user1,cn=users,dc=my-domain,dc=com dn: cn=user1,cn=users,dc=my-domain,dc=com objectClass: organizationalRole objectClass: simpleSecurityObject cn: user1 userPassword:: e01ENX1weUxHUGJqc2hpV3ZiUGNjdU1MWk9RPT0= > ldapsearch -h localhost:9999 -Y DIGEST-MD5 -U user1 -w pass1 -LLL -b cn=user1,cn=users,dc=my-domain,dc=com SASL/DIGEST-MD5 authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): user not found: no secret in database > ldapsearch -h localhost:9999 -Y DIGEST-MD5 -U user3 -w pass3 -LLL -b cn=user1,cn=users,dc=my-domain,dc=com SASL/DIGEST-MD5 authentication started SASL username: user3 SASL SSF: 128 SASL installing layers dn: cn=user1,cn=users,dc=my-domain,dc=com objectClass: organizationalRole objectClass: simpleSecurityObject cn: user1 userPassword:: e01ENX1weUxHUGJqc2hpV3ZiUGNjdU1MWk9RPT0=

15 years, 11 months

5
9
0 / 0

SLES 9.3 spec file for building openldap 2.3.38

by Keagle, Chuck

Are there any available openldap-2.3.38.spec files out there for SLES 9.3? openldap2-client-2.2.24 is already installed on SLES 9.3 and doesn't support syncrepl. I'm just getting started with LDAP and syncrepl seems to be a better way to go than slurpd in a 7x24 environment. Downloaded openldap-2.3.38.tgz from http://www.openldap.org/software/download/ and it's not ready for RPM. Since openldap2-client-2.2.24.rpm is already installed, and removing it would require removing a whole bunch of other stuff in order to just do a "make install", I'm looking for a cleaner way to get it updated. rpm -F. Any other ideas? ---- Not all who wander are lost. | ---- ___o | chuck.keagle(a)boeing.com Chuck Keagle | ------- \ <, | Work: (425) 865-1488 Enterprise Servers: HPC | ----- ( )/ ( ) | Cell: (425) 417-3434

15 years, 11 months

4
3
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software November 2007