openldap-software

openldap-software@openldap.org

2719 discussions

Re: Automatic referral chasing
by Gavin Henry 06 Sep '07

06 Sep '07

<quote who="Tony Earnshaw"> > Pierangelo Masarati skrev, on 06-09-2007 15:35: > >>>> I'll try that. "wip" is presumably ""Work In Progress", rather than >>>> the >>>> Dutch slang "wip" (which is something you probably didn't intend)? >>> >>> The former ;-) >> >> Would anybody mind providing a periphrasis for it for non-native >> English, non-native Dutch? :) > > Well, it's slang for "speedy copulation, a quick fuck". As it's slang, I > couldn't find anything suitable in Merriam Webster - there are British > English euphemisms like "a roll in the hay" and "a quicky" (army slang), > but I've been away from England so long that ... Just to confirm, I meant Work In Progress. > > --Tonni > > > -- > Tony Earnshaw > Email: tonni at hetnet dot nl >

1 0

Monitor the SyncRepl replication status
by Bruno Lezoray EMSM 06 Sep '07

06 Sep '07

Hi all, few months ago, i developed script to monitor slurpd replication, by checking replication logs. Now, we want to implement SyncRepl replication, and it looks more complex to know a status of the replication. Is someone already developed a tool to do that ? My first idea is to compare the contextCSN of the suffix entry between the master and the slave. I don't know if there is some specific logs that indicate the replication is broken. Any help is welcome. Rgds, Bruno.

3 4

chaining question
by Tony Earnshaw 05 Sep '07

05 Sep '07

I finally got chaining working on our OL 2.3.37 (I'll be updating) delta syncrepl Samba consumer. It used to work before and stopped around OL 2.3.24 - unfortunately I don't know exactly which version. The 2 2.3.37 and .38 chaining tests, 018 and 032 pass on my build machine. But when I put these ad lib into slapd.conf on the consumer, they don't. What doesn't work after 'moduleload back_ldap.la': overlay chain chain-uri ldap://mercurius.intern/ chain-idassert-bind bindmethod=simple binddn="cn=proxy,dc=barlaeus,dc=nl" credentials=secret mode=self chain-tls start Apart from chain-tls, this is almost verbatim what the two tests use. I finally noticed from the SLAPO-CHAIN man page, not having seen the wood for the trees, the following: "Directives for configuring the underlying ldap database may also be required, as shown in this example:". So I tried the example, and this chaining config does work on the consumer: overlay chain chain-rebind-as-user FALSE chain-uri ldap://mercurius.intern/ chain-rebind-as-user TRUE chain-idassert-bind bindmethod=simple binddn="cn=proxy,dc=barlaeus,dc=nl" credentials=secret mode=self chain-tls start Could someone please explain why the configuration for the two tests should pass, while it doesn't on my consumer, and why the config with the two chain-rebind-as-user stanzas does? Best, --Tonni -- Tony Earnshaw Email: tonni at hetnet dot nl

4 8

Re: Performance issue with In-Memory BDB
by Suhel Momin 04 Sep '07

04 Sep '07

Sorry, but I could not understand the meaning of back-bdb residing in HEAD. I have attached a diff over openldap-2.3.35 for changes regarding BDB in-memory. This mainly has changes for keeping logs,environment and databases in memory. The bdb in-memory code is under #ifdef BDB_INMEMORY I am trying out different environment cache sizes to check any performance difference. Thanks and Regards, Suhel On 8/31/07, Howard Chu <hyc(a)symas.com> wrote: > Suhel Momin wrote: > > Hi, > > > > I have made changes such that backend BDB ( ver 4.5 ) resides in > > memory instead of on disk . This is with default slapd configuration. > > I was hoping to have a better performance with this. > > back-bdb as currently residing in HEAD already yields efficiencies of 95% > of > available system bandwidth. It is extremely unlikely that you are going to > be > able to improve the performance significantly, most changes you could make > to > the code at this point will only yield performance losses. > > > But what I now see > > is that do_add takes much more time then what it use to take when BDB > > was on-Disk. Indexing is done on objectclass in both the cases. > > > > Any pointers on why this could be an issue? > > -- > -- 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/ >

2 1

Multiple Schema
by Suhel Momin 04 Sep '07

04 Sep '07

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

3 3

High availability
by Taymour A. El Erian 04 Sep '07

04 Sep '07

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

6 28

Question on "11.3.3.1. Notes on Proxy Authorization Rules"
by Patrick Ben Koetter 02 Sep '07

02 Sep '07

"11.3.3.1. Notes on Proxy Authorization Rules" <http://www.openldap.org/doc/admin23/sasl.html#SASL%20Proxy%20Authorization> notes the following example: authzTo: uid=[^,]*,dc=example,dc=com Shouldn't that be: authzTo: dn.regex:uid=[^,]*,dc=example,dc=com p@rick -- state of mind Agentur für Kommunikation, Design und Softwareentwicklung Patrick Koetter Tel: 089 45227227 Echinger Strasse 3 Fax: 089 45227226 85386 Eching Web: http://www.state-of-mind.de Amtsgericht München Partnerschaftsregister PR 563

2 1

openldap - logger
by Arunachalam Parthasarathy 02 Sep '07

02 Sep '07

Hello all, Can we able to write the debug log messages, directly to a file without using Syslog Thanks 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!

1 0

Requesting advice for repairing a syncRepl issue
by Benjamin Lewis 01 Sep '07

01 Sep '07

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

3 3

TLS configuration needs client certification (why?)
by Frank Cornelissen 31 Aug '07

31 Aug '07

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

5 7

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software