openldap-technical April 2011

openldap-technical@openldap.org

97 participants
98 discussions

RE: Problem Compiling openldap-2.4.23
by Darouichi, Aziz 29 Apr '11

29 Apr '11

Sorry about that. The path to BDB is correct. I made typo when I created the prefix. When I grep for BDB _VERSION. grep DB_VERSION_STRING /usr/local/Berkley-5.1/include/db.h #define DB_VERSION_STRING "Berkeley DB 5.1.25: (January 28, 2011) -----Original Message----- From: Michael Ströder [mailto:michael@stroeder.com] Sent: Friday, April 29, 2011 11:30 AM To: Darouichi, Aziz Subject: Re: Problem Compiling openldap-2.4.23 Please keep responses on the mailing list. Darouichi, Aziz wrote: > But I am using BDB 5.1.23 It seems this is not used. Maybe a typo in this path: /usr/local/Berkely-5.1 ^^ missing "e"? Ciao, Michael. > -----Original Message----- > From: Michael Ströder [mailto:michael@stroeder.com] > Sent: Friday, April 29, 2011 11:20 AM > To: Darouichi, Aziz > Cc: openldap-technical(a)openldap.org > Subject: Re: Problem Compiling openldap-2.4.23 > > Darouichi, Aziz wrote: >> I installed Berkeley 5.1.25.NC in RHEL 32 when I try to compile >> openldap-2.4.23 using the followings. >> >> CPPFLAGS="-I/usr/local/Berkely-5.1/include" >> LDFLAGS="-L/usr/local/Berkley-5.1/lib" ./configure --prefix=/opt/local >> >> LD_LIBRARY_PATH=/usr/local/Berkley-5.1/lib , export LD_LIBRARY_PATH. >> >> I get the error message. >> >> checking for Berkeley DB major version in db.h... 4 >> checking for Berkeley DB minor version in db.h... 3 >> checking if Berkeley DB version supported by BDB/HDB backends... no >> configure: error: BerkeleyDB version incompatible with BDB/HDB backends > > BDB 4.3.x should not be used because of severe issues with this version: > > http://www.openldap.org/faq/data/cache/44.html > > Ciao, Michael.

1 0

Problem Compiling openldap-2.4.23
by Darouichi, Aziz 29 Apr '11

29 Apr '11

Hi, I installed Berkeley 5.1.25.NC in RHEL 32 when I try to compile openldap-2.4.23 using the followings. CPPFLAGS="-I/usr/local/Berkely-5.1/include" LDFLAGS="-L/usr/local/Berkley-5.1/lib" ./configure --prefix=/opt/local LD_LIBRARY_PATH=/usr/local/Berkley-5.1/lib , export LD_LIBRARY_PATH. I get the error message. checking for Berkeley DB major version in db.h... 4 checking for Berkeley DB minor version in db.h... 3 checking if Berkeley DB version supported by BDB/HDB backends... no configure: error: BerkeleyDB version incompatible with BDB/HDB backends Thanks, Aziz

2 1

Re: Installation openLDAP in Debian
by Hallvard B Furuseth 29 Apr '11

29 Apr '11

Olivier Guillard writes: > How to survive in operational environnement without comments > in files ( nor a way to track change logs btw ) ? I suppose you could put slapd.d/ under version control. After making a change or a set of changes, commit your modified slapd.d/ with your comments in the commit message. Or put comments in other files under slapd.d/. If these filenames do not resemble DNs, e.g. have filetype .txt and no '=' in them, they won't clash with cn=config's filenames. I haven't tried how cumbersome this is/isn't in practice though. -- Hallvard

4 5

"DIT content rule" usage patterns?
by Marco Pizzoli 29 Apr '11

29 Apr '11

Hi list, could someone point me to some resources, in particular usage examples, about DIT content rules? Thanks in advance Marco -- _________________________________________ Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison

4 6

slapi_get_client_ip in openldap?
by Jani Salonen 28 Apr '11

28 Apr '11

Hi, I've written a prebind plugin for slapd, and I was wondering if there is a way to resolve connected client's IP address somehow, like IBM Tivoli has slapi_get_client_ip()/slapi_get_source_ip() functions? If there is no suitable functions already in openldap, does anyone know a feasible way to do it? -- /} @###{]::::::Jani Salonen::::::> \}

2 1

RE: Finding issue with LDAP_OPT_NETWORK_TIMEOUT
by Singh, Pravat (NSN - IN/Bangalore) 28 Apr '11

28 Apr '11

Hi, I am facing problem while in ldap_simple_bind () while setting LDAP_OPT_NETWORK_TIMEOUT. Can anybody let me know if I am missing something. Just to add some information that I have compiled the openldap-2.4.23 version on solaris 10 with sun studio compiler. The bind api "ldap_simple_bind()" is successful if don't use LDAP_OPT_NETWORK_TIMEOUT but fails if I use. >From my application bind() method I am using the following apis struct timeval tempTime; tempTime.tv_usec = 0; tempTime.tv_sec = 10; ldap_init((char*)theHost.c_str(), thePort); ldap_set_option(theLDAP, LDAP_OPT_PROTOCOL_VERSION, &desired_version); ldap_set_option(theLDAP, LDAP_OPT_DEREF, &desired_deref); ldap_set_option( theLDAP, LDAP_OPT_NETWORK_TIMEOUT, (void *)&tempTime ); ldap_simple_bind(theLDAP, (char*)theUserDN, (char*)theUserPW); here I am getting a bind failure and from openldap library in ldap_sasl_bind(...) of libldap_r/sasl.c where the following code fails and ld->ld_errno returns -1 /* send the message */ *msgidp = ldap_send_initial_request( ld, LDAP_REQ_BIND, dn, ber, id ); printf("returning ld->ld_errno %d\n",ld->ld_errno); Could anybody help me to know if I am missing anything here (Don't know may be to set some ldap options or missed some compilation flag, not sure). Hope someone will help me to solve this issue. If anybody has a sample client code with ldap option set to LDAP_OPT_NETWORK_TIMEOUT. Please send me. Regards, Pravat

2 1

Re: Problem regarding OpenLdap installation and Berkeley DB
by Marco Pizzoli 28 Apr '11

28 Apr '11

On Thu, Apr 28, 2011 at 7:33 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Thursday, April 28, 2011 11:21 AM +0200 Marco Pizzoli > <marco.pizzoli(a)gmail.com> wrote: > >> Hi, >> OpenLDAP is officially supported only with BerkeleyDB versions at >> maximum equal to 5.0.x, and this particular version only since 2.4.24. > > No. Read the change log again: > > Added slapd support for BDB 5.0+ (ITS#6698) > > It says 5.0+. That means 5.0 and higher. Not maximal at 5.0. I saw right but interpreted wrong, it seems... 5.0+ to me appeared as whatever version 5.0.0/5.0.1/5.0.2/etc... My fault

1 0

Problem regarding OpenLdap installation and Berkeley DB
by Frederick William Borges Pohl 28 Apr '11

28 Apr '11

Hello, I am a new user to Openldap and I´ve been struggling to install on my RedHat box for quite some time. I´ve googled and read past messages from this forum but i´m still unable to solve my problem which. I have installed Berkeley Db db-5.1.25 with success but when I try to install openldap, I get the following error: [root@redqas01 openldap-2.4.23]# ./configure ... checking db.h usability... yes checking db.h presence... yes checking for db.h... yes checking for Berkeley DB major version in db.h... 5 checking for Berkeley DB minor version in db.h... 1 checking if Berkeley DB version supported by BDB/HDB backends... yes checking for Berkeley DB link (default)... no configure: error: BDB/HDB: BerkeleyDB not available Searching this mailing list, I found some information regarding setting the LDFLAGS and CPPFLAGS for the BDB installation. So I did the following commands: (considering that the installation for the BDB was in the /usr/local directory) LD_LIBRARY_PATH="/usr/lib:/usr/local/lib:/usr/local/BerkeleyDB.5.1/lib:/usr/local/berkeley/lib" LDFLAGS="-L/usr/local/lib -L/usr/local/BerkeleyDB.5.1/lib -L/usr/local/berkeley/lib" CPPFLAGS="-I/usr/local/include -I/usr/local/BerkeleyDB.5.1/include -I/usr/local/berkeley/include" I checked the /usr/local/lib/ directory and the libdb-5* files are there. I also checked the /usr/local/include/ and the db.h file is also there. But I still get the same error message. Any tips? Att Frederick Pohl

4 3

Multi-Master Question when network partition
by Tony Dong 28 Apr '11

28 Apr '11

> Hi, > > In OpenLDAP 2.4 admin guide "chapter 18: Replication" 18.2.2.3. Arguments against Multi-Master replication: > > If a network is partitioned and multiple clients start writing to each of the "masters" then reconciliation will be a pain; it may be best to simply deny writes to the clients that are partitioned from the single provider. > > How to configure to deny writes in a LDAP master? > > My environment is 3-way MMR, of A, B, C three servers. If connection between server A and server B is lost, how can server A and B automatically deny writes and become read-only? As server C can still accept write operations, and sync with both server A and B, so data in server A and B is up-to-date and thus can act as slaves temporarily. > > > Best Regards, > Tony Dong > > >

1 0

Deleted DNs, and the great quest.
by Jorgen Lundman 27 Apr '11

27 Apr '11

SunOS ldapslave01.unix 5.10 Generic_141445-09 i86pc i386 i86pc db-4.8.30.NC.tar.gz openldap-2.4.23.tgz Hello list, We have had a rare bug hit us now and then, that appears to be quite persistent. I know it isn't fun to read through someone else's setup and troubles, but I am hoping to at least get some hints at what to look at next. Let us imagine our setup as: uid=user1,o=a.gmail.com,ou=mail,dc=company,dc=com uid=user2,o=a.gmail.com,ou=mail,dc=company,dc=com uid=user1,o=b.gmail.com,ou=mail,dc=company,dc=com uid=user1,o=c.gmail.com,ou=mail,dc=company,dc=com (Not literally gmail.com, replacing customer domains manually, but same "style" of service). ldapmaster -> slave1 -> localhost slapd (pop/imap) -> slave2 -> localhost slapd (postfix) -> slave3 -> localhost slapd (ftp) -> slave4 -> localhost slapd (smtp/forward) All using syncrepl. One master, only ever updated by the provisioning engine. 4 immediate slaves (full ldap tree), then about 150 work servers, running localhost slapd with only applicable tree. Ie, only "ou=mail" for the mail-related servers. What happens now and then, is that: o=b.gmail.com,ou=mail,dc=company,dc=com gets deleted. Gone. But you can access record "uid=user1,o=b.gmail.com,ou=mail,dc=company,dc=com" just fine. But not "o=b.gmail.com,ou=mail,dc=company,dc=com". How is that possible? Mismatching indexes? Amusingly, POP and IMAP work fine since they authenticate against the final user record "uid=user1,o=b.gmail.com,ou=mail,dc=company,dc=com". but Postfix will fail, as it verifies that the domain exists "o=b.gmail.com,ou=mail,dc=company,dc=com". syncrepl for accounts under tree "o=b.gmail.com,ou=mail,dc=company,dc=com" appear to stop until the record is fixed. There is an easy fix, if we modify the record "o=b.gmail.com,ou=mail,dc=company,dc=com" on the master, it gets pushed out. It is not always the same record, but it does seem to be a class of certain records. And the missing records seem to happen most on certain servers. 80% of the time, on the vmx servers. It far worse when they disappear on the slaves, since many localhost slapds will then not get synced. Now, this happens more frequently when we do deletions. Usually around the first of the month, since that is when we delete customers who left. Alas, we moved the entire LDAP DNS tree to its own LDAP master, so have been deleting this tree for 20 days, and will keep deleting for 12 more days. So, at the moment, we have this error once, or twice, a day. At the moment, I do not really know what goes wrong. I am hoping that perhaps I can get some good ideas on where to look, and what to look for. This morning, we lost "i.gmail.com" on vmx02. If I grep for it in the logs, we only find: Apr 27 09:17:51 vmx02.unix slapd[13990]: [ID 338579 local4.debug] nonpresent_cal lback: rid=275 nonpresent UUID 82d9570a-cdd6-102f-9364-65cc77dfbe36, dn o=i.gmail.com,ou=mail,dc=company,dc=com Apr 27 09:18:11 vmx02.unix slapd[13990]: [ID 905397 local4.debug] syncrepl_del_nonpresent: rid=275 be_delete o=i.gmail.com,ou=mail,dc=company,dc=com (66) # grep nonpresent_callback /var/log/slaplog| wc -l 517707 # grep syncrepl_del_nonpresent /var/log/slaplog|wc -l 9 What is also curious, is the UUID, for example: slaplog.20110424.gz:Apr 24 15:31:26 vmx02.unix slapd[13990]: [ID 338579 local4.debug] nonpresent_callback: rid=275 nonpresent UUID 82d9570a-cdd6-102f-9364-65cc77dfbe36, dn o=i.gmail.com,ou=mail,dc=company,dc=com slaplog.20110424.gz:Apr 24 23:41:00 vmx02.unix slapd[13990]: [ID 338579 local4.debug] nonpresent_callback: rid=275 nonpresent UUID 82d9570a-cdd6-102f-9364-65cc77dfbe36, dn o=i.gmail.com,ou=mail,dc=company,dc=com Persistent uuid? Is it ok that UUID is repeated? Are unique over time, or sometimes recycled? If I move from vmx02, to its LDAP provider, in this case, ldapslave03 (rid = 329) Apr 27 09:12:27 ldapslave03.unix slapd[20759]: [ID 338579 local4.debug] nonprese nt_callback: rid=329 present UUID d6215e0e-1c55-102f-8da7-0b6e3175d2bb, dn o=i.gmail.com,ou=mail,dc=company,dc=com /export/backup/ldapslave03.unix# gzgrep d6215e0e-1c55-102f-8da7-0b6e35d2bb slaplog.20110* Jan 6 07:15:39 Feb 8 18:47:48 Apr 24 15:22:21 Apr 24 23:36:22 Is it worth pursuing the repeated UUID? Is that some stuck record that keeps retrying over and over? Is it that is constantly trying to delete these records, and correctly failing, except now and then, it succeeds like that of vmx02 this morning? Then there is the slightly different message, with error "66". Apr 27 09:20:06 ldapslave03.unix slapd[20759]: [ID 976560 local4.debug] syncprov_sendresp: cookie= Apr 27 09:20:06 ldapslave03.unix last message repeated 1 time Apr 27 09:20:06 ldapslave03.unix slapd[20759]: [ID 905397 local4.debug] syncrepl _del_nonpresent: rid=329 be_delete o=i.gmail.com,ou=ftp,dc=company,dc=com (66) Apr 27 09:20:06 ldapslave03.unix slapd[20759]: [ID 976560 local4.debug] syncprov_sendresp: cookie= Apr 27 09:20:06 ldapslave03.unix last message repeated 4 times I believe 66 is LDAP_NOT_ALLOWED_ON_NONLEAF, which is correct. It has thousands of accounts in there, so it definitely should not delete it. But why does it try to delete it in the first place? It is not us trying to delete half the tree (well, you know, pretty sure...ish.. it isn't us) so where is it coming from? Or should I look at that empty "cookie="? Why that empty, it starts back at: Apr 27 09:17:29 ldapslave03.unix slapd[20759]: [ID 859137 local4.debug] slap_queue_csn: queing 21798d80 20110427000316.304365Z#000000#000#000000 Apr 27 09:17:29 ldapslave03.unix slapd[20759]: [ID 976560 local4.debug] syncprov_sendresp: cookie=rid=268,csn=20110427000316.304365Z#000000#000#000000 Apr 27 09:17:29 ldapslave03.unix slapd[20759]: [ID 976560 local4.debug] syncprov_sendresp: cookie=rid=278,csn=20110427000316.304365Z#000000#000#000000 Apr 27 09:17:29 ldapslave03.unix slapd[20759]: [ID 775493 local4.debug] slap_graduate_commit_csn: removing a2bee60 0110427000316.304365Z#000000#000#000000 Apr 27 09:17:29 ldapslave03.unix slapd[20759]: [ID 905397 local4.debug] syncrepl_del_nonpresent: rid=329 be_delete uid=$account,ou=users,ou=radius,dc=company,dc=com (0) Apr 27 09:17:29 ldapslave03.unix slapd[20759]: [ID 502419 local4.debug] Entry uid=userX,o=$customerdomain.com,ou=mail,dc=company,dc=com CSN 20110426223343.974235Z#000000#000#000000 older or equal to ctx 20110426223343.974235Z#000000 #000#000000 Apr 27 09:17:29 ldapslave03.unix last message repeated 1 time Apr 27 09:17:29 ldapslave03.unix slapd[20759]: [ID 976560 local4.debug] syncprov_sendresp: cookie= Apr 27 09:17:29 ldapslave03.unix last message repeated 1 time then a few hundred lines of empty "cookie=" lines. It is also worth to note that very close to the time that it lost the record today, we have: Apr 27 09:11:25 vmx02.unix slapd[13990]: [ID 763815 local4.debug] connection_input: conn=6946 deferring operation: too many executing and it is almost as if, it kills the replication connection randomly when it gets busy. Whatever record it was working on at the time is half processed? Alas, there are no entries at all for any of these on the master. Possibly because master's loglevel is "sync", which don't seem to do much when it is the provider. Recommended log level would be? Now, there is version openldap-2.4.24 out, with a very large list of fixes, but I did not see anything immediately obvious. If there is a fix that "looks good" to fix this, I can go through the upgrade. But it is a 3 week process to make it happen on all servers. Worse is, I have tried to replicate the trouble in a test network, running the exact same data, and binaries, with a master, slave and localhost slapd all on one machine. But I can not make the trouble happen in a simulated environment. Possibly as I am not generating the same load. Quite annoying. slapd.conf is pushed out with git, and is the same everywhere, except that slaves have the syncrepl section, with separate rids, and memory cache size are set differently. include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/qmail.schema include /usr/local/etc/openldap/schema/local.schema include /usr/local/etc/openldap/schema/RADIUS-LDAPv3.schema include /usr/local/etc/openldap/schema/AmavisdLDAP.schema include /usr/local/etc/openldap/schema/analyse.schema include /usr/local/etc/openldap/schema/formail.schema include /usr/local/etc/openldap/schema/dlz.schema include /usr/local/etc/openldap/schema/filter.schema pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args loglevel sync database monitor access to dn.subtree="cn=Monitor" by dn="cn=admin,dc=company,dc=com" read by * none access to attrs=userPassword by self write by anonymous auth by * none access to * by self write by dn="cn=admin,dc=company,dc=com" write by * read password-hash {CRYPT} database hdb suffix "dc=company,dc=com" rootdn "cn=admin,dc=company,dc=com" directory /usr/local/var/openldap-data rootpw $secret index objectClass eq index uid eq index uidNumber eq index mail eq index mailAlternateAddress pres,eq index deliveryMode eq index accountStatus eq index gecos eq index radiusGroupName eq index o pres,eq index entryCSN,entryUUID eq index gidNumber eq index DNSType eq index DNSIPAddr eq index DNSData eq index DNSHostName eq checkpoint 128 15 cachesize 6000 idlcachesize 18000 overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 1000 dbconfig set_lk_detect DB_LOCK_DEFAULT dbconfig set_lg_max 52428800 dbconfig set_cachesize 4 0 1 dbconfig set_flags db_log_autoremove dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 syncrepl rid=( $IP-4TH-OCTET + 256 ) provider=ldap://172.20.12.163 type=refreshAndPersist interval=00:00:00:30 searchbase="dc=company,dc=com" filter="(objectClass=*)" attrs="*,+" scope=sub schemachecking=off bindmethod=simple binddn="cn=admin,dc=company,dc=com" credentials="$secret" retry="60 10 300 +" updateref ldap://172.20.12.113 (Actually, 172.20.12.163 and 172.20.12.113 are the same server, just aliases on same nic. But updateref is never actually used, we only one writer that talks directly to master).

3 14

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical April 2011