August 2007 - openldap-software

using slapo-pcache with an empty attr list

by Toby Blake

Hi all, I'm doing a bit of playing with slapo-pcache and have it working fairly well (particularly once I realised that an individual attr can live in only one proxyattrset). However, there's one bit that I can't get working - is there any way to define a template that will match a search which doesn't provide an attr list? i.e. I can see quite a few searches (presumably from amd) of the following form (spacing and formatting changed by me to make it more readable): Jul 23 14:54:16 host1 slapd[26671]: conn=49 op=1 SRCH base="dc=inf,dc=ed,dc=ac,dc=uk" scope=2 deref=0 filter="(&(objectClass=amdmap)(amdmapName=home)(amdmapKey=root))" Jul 23 14:54:16 host1 slapd[26671]: query template of incoming query = (&(objectClass=)(amdmapName=)(amdmapKey=)) Jul 23 14:54:16 host1 slapd[26671]: QUERY NOT ANSWERABLE Jul 23 14:54:16 host1 slapd[26671]: QUERY NOT CACHEABLE Jul 23 14:54:16 host1 slapd[26671]: conn=49 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= Note that there's no 'SRCH attr=' line. I've tried proxyattrset of the following forms... proxyattrset 1 * proxyattrset 1 (both of which crash slapd) And also proxyattrset 1 <full list of attrs returned when none specified> .... but this didn't work either. Thanks in advance for any advice, Cheers Toby Blake School of Informatics University of Edinburgh

15 years, 3 months

3
8
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

RE: ldapsearch on local attributes with slapo-translucent

by Srilakshmanan, Kumuthiny

Are you missing a bracket? "(&(object Class=AsteriskSIPUser)(AstAccountName=600))" -----Original Message----- From: openldap-software-bounces+kumuthiny.srilakshmanan=auspost.com.au(a)OpenLDAP.or g [mailto:openldap-software-bounces+kumuthiny.srilakshmanan=auspost.com.au@Ope nLDAP.org] On Behalf Of Gavin Henry Sent: Friday, 20 July 2007 7:26 AM To: openldap-software(a)openldap.org Subject: ldapsearch on local attributes with slapo-translucent Dear All, I'm doing some work with Asterisk and translucent, trying to overlay some attributes to an existing remote account, locally. These attributes have been added by entries in the local database before being presented to me via ldapsearch, whilst searching for attributes present in the remote directory: objectClass: AsteriskExtension objectClass: AsteriskSIPUser AstAccountName: 600 AstAccountType: friend AstAccountSecret: 600 AstAccountQualify: yes AstAccountPort: 5060 AstAccountNAT: never AstAccountMailbox: 600@device AstAccountHost: dynamic AstAccountDTMFMode: rfc2833 AstAccountContext: from-internal AstAccountCanReinvite: no AstAccountCallerID: Gavin <502> Should I expect to be able to search for the above attributes and get a result? Currently I am not. A filter like: "(&(objectClass=AsteriskSIPUser)(AstAccountName=600)" returns: ldapsearch: ldap_search_ext: Bad search filter (-7) So I guess that answers my question. If slapo-translucent did return results for searches against the local attributes, would this be defeating the purpose/design of the overlay? Thanks, Gavin. Australia Post is committed to providing our customers with excellent service. If we can assist you in any way please telephone 13 13 18 or visit our website. The information contained in this e-mail communication may be proprietary, confidential or legally professionally privileged. It is intended exclusively for the individual or entity to which it is addressed. You should only read, disclose, re-transmit, copy, distribute, act in reliance on or commercialise the information if you are authorised to do so. Australia Post does not represent, warrant or guarantee the integrity of this e-mail communication has been maintained nor that the communication is free of errors, virus or interference. If you are not the addressee or intended recipient please notify us by replying direct to the sender and then destroy any electronic or paper copy of this message. Any views expressed in this e-mail communication are taken to be those of the individual sender, except where the sender specifically attributes those views to Australia Post and is authorised to do so.

15 years, 11 months

4
4
0 / 0

slapo-unique. several unique_base with different unique_attributes sets

by Dmitriy Kirhlarov

Hi, list I have container in my tree 'ou=cyrus,ou=mail,o=domain' and I need check 'uniqueMember' attribute -- user can be membered only in one group. Also, for 'ou=web,ou=groups,o=domain' with same types of objects, as 'ou=cyrus,ou=mail,o=domain' user can be membered in several groups, but I need uniques check for 'gidNumber' inside 'ou=groups,o=domain'. I need something: unique_base ou=users,o=domain uidNumber mail mailLocalAddress unique_base ou=groups,o=domain gidNumber unique_base ou=cyrus,ou=mail,o=domain uniqueMember I'm using openldap 2.3.35 Is it possible with this version or, may be, with 2.4.x? WBR. Dmitriy

15 years, 12 months

3
4
0 / 0

Multiple Schema

by Suhel Momin

Hi, I am planning to have multiple DIT's. These DIT's may use different customised Schema. Now my problem is to store these schema such that DIT's will use their respective schema definition. This is because the attributetype or objectclass in these different schemas might overlap. Hence I want to keep them seperate and use them for a particular DIT. Is this possible? Or, If I have to make changes in the existing openldap code how should I go about it? I have observed that attributetype, objectclass etc are stored in AVL. do I need to maintain different AVL for my schemas to work? Any help regarding how I should proceed is appreciated. If I am on wrong mailing list please redirect me. Thanks and Regards, Suhel

16 years

3
3
0 / 0

High availability

by Taymour A. El Erian

Hi, I have been searching for a long time to find a solution to give me high availability on the writing. We have 2 ldap servers running as multi master (I know it is not considered a good thing and it is very old 2.0.x), this way if one is down the other will accept writes (add/modify/delete). If we do the normal single master multiple slaves, we will get more performance and high availability for reads but if the master is down no updates. Also, we can not separate writes from reads and we can not use referrals (not all applications we have can chase referrals). I though of having a standby master and use heartbeat but it doesnt look like a stable solution, any ideas ? maybe shared disk ? -- Taymour A El Erian System Division Manager RHCE, LPIC, CCNA, MCSE, CNA TE Data E-mail: taymour.elerian(a)tedata.net Web: www.tedata.net Tel: +(202)-33320700 Fax: +(202)-33320800 Ext: 1101

16 years

6
28
0 / 0

Requesting advice for repairing a syncRepl issue

by Benjamin Lewis

Hello, I have a pair of OpenLDAP servers that had been replicating flawlessly with delta syncRepl for about 10 months. Just the other day, I saw that modifications were no longer being replicated and these messages were appearing in the syslog on the master server immediately after the MOD line: [ID 651871 local0.debug] => bdb_idl_insert_key: c_get next_dup failed: DB_NOTFOUND: No matching key/data pair found (-30990) [ID 809268 local0.debug] => bdb_dn2id_add: parent (cn=log) insert failed: -30990 I assume that something has become corrupted in the BDB database for cn=log on the master. Does that seem correct? I'm definitely not seeing any new entries in the cn=log database since those messages began appearing. If it is a corrupted index, I think that running "slapindex -b cn=log -f .... " after stopping the slapd process will fix that. After that completes, I should be able to restart the slapd and test that writes to entries under the baseDN do cause new entries to appear in the cn=log database. If it's not an index, I have no idea how to repair this. I found the error message in the sources (servers/slapd/back-bdb/idl.c:789 in version 2.3.30) but honestly, I have no idea what that code is doing. Once (if) I can repair things, I can begin worrying about getting changes to the replica again. Since there are changes missing from the cn=log database on the master, I assume that I'll need to cause a complete re-sync. Is there a better way to accomplish that than removing the entire database on the replica, using slapadd to import a recent backup of the master, and restarting the replica? Some specifics in case they matter: Master: Solaris10 amd64 BDB 4.2.52 + 5 patches OpenLDAP 2.3.30 Replica: Solaris10 amd64 BDB 4.2.52 + 5 patches OpenLDAP 2.3.38 (upgraded from 2.3.33 the day before the problem began on the Master) (What I believe to be the) Relevant portions of slapd.conf file from the Master (slightly obfuscated) are included at the end of this message. Thank you for any help, -Ben # access log database (used by syncprov-delta replication) database bdb suffix "cn=log" directory /var/openldap/data/prod/logdb rootdn "cn=Manager,dc=our,dc=domain" mode 0660 shm_key 142 index default eq index objectClass,entryUUID,entryCSN eq index reqStart,reqEnd,reqResult,reqType eq access to dn.subtree="cn=log" by group.exact="cn=DirectoryAdmins,cn=administrators,dc=our,dc=domain" write by dn.onelevel="cn=SyncUsers,cn=administrators,dc=our,dc=domain" read by * none overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE # This is all one line limits dn.onelevel="cn=SyncUsers,cn=administrators,dc=our,dc=domain" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited database hdb suffix "dc=our,dc=domain" rootdn "cn=manager,dc=our,dc=domain" rootpw {SHA}[XXX REMOVED XXX] directory /var/openldap/data/prod/db checkpoint 100000 30 mode 0660 shm_key 42 cachesize 500000 idlcacheSize 1500000 index default pres,eq index givenName,description,uid,cn,sn pres,eq,sub index objectClass,uniqueMember,member eq index employeeNumber eq,sub index entryCSN,entryUUID eq overlay ppolicy ppolicy_default cn=standard,cn=policies,dc=our,dc=domain overlay dynlist dynlist-attrset groupOfURLs memberURL member overlay syncprov syncprov-checkpoint 100000 30 syncprov-sessionlog 300000 overlay accesslog logdb cn=log logops writes logsuccess TRUE logold (objectClass=inetOrgPerson) logpurge 28+00:00 01+00:00 # This is all one line limits dn.onelevel="cn=SyncUsers,cn=administrators,dc=our,dc=domain" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited

16 years

3
3
0 / 0

TLS configuration needs client certification (why?)

by Frank Cornelissen

Hello all, why does slapd require a peer/client certificate? I'm slapd 2.3.30 on debian (package 2.3.30-5 to be precise). when connexting with ssl to slapd using ldapsearch -H ldaps://artemis.t310.org -b dc=t310,dc=org -x I get the following error from slapd (started with -d 8): TLS: can't accept. TLS: error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate s3_srvr.c:2455 When connecting to the same host but with the ldap protocol (vs ldaps) the search results correctly. This error seems like somehow slapd wants to get a client certficate, but I did not set slapd up that way. The ldap.conf on the client machines only contains the CA certificate field: TLS_CACERT /usr/share/ca-certificates/t310/t310_pem.crt relevant parts from slapd.conf (included in total at the end of message): TLSCertificateFile /etc/ldap/artemis-ldap-cert.pem TLSCertificateKeyFile /etc/ldap/artemis-ldap-key.pem TLSCACerticateFile /usr/share/ca-certificates/t310/t310_pem.crt #TLSVerifyClient never #TLSCRLCheck none verification with openssl s_server and s_client: openssl s_server -accept 12345 -cert /etc/ldap/artemis-ldap- cert.pem -key /etc/ldap/artemis-ldap-key.pem -CAfile /usr/share/ca- certificates/t310/t310_pem.crt Using default temp DH parameters Using default temp ECDH parameters ACCEPT and the client: openssl s_client -CAfile /etc/ssl/certs/t310_pem.pem - connect artemis.t310.org:12345 allows me to exchange data between them. However connecting the s_client to the real ldap server results in an error: artemis:~# openssl s_client -CAfile /etc/ssl/certs/ t310_pem.pem -connect artemis.t310.org:636 CONNECTED(00000003) depth=1 /O=T310 technologies/OU=CA Division/ emailAddress=ca(a)t310.org/L=Amsterdam/ST=NH/C=NL/CN=T310 root CA verify return:1 depth=0 /C=NL/ST=NH/O=T310 technologies/OU=ldap/ CN=artemis.t310.org verify return:1 15612:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1057:SSL alert number 40 15612:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188: Any help is appreciated Frank Cornelissen

16 years

5
7
0 / 0

dynamic configuration - for syncrepl , chaining

by Arunachalam Parthasarathy

Hello all, I am using openldap 2.3.36 1) Can I know Why dynamically modifying the syncreplication configuration through cn=config is not supported? 2) When I modify chaining URI also, I am unable to do. Can I know why is it so? Thanks a lot in advance, Arunachalam. **************************************************************************** **************************** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

16 years

1
0
0 / 0

How to use postread?

by manu＠netbsd.org

As I understood, postread control should offer a way of doing an atomic increment-and-read operation, but how is it supposed to output the result? This does not produce any particular output: ldapsearch -x -e!postread=uidNumber uid=foo uid -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

16 years

3
7
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software August 2007