openldap-technical

openldap-technical@openldap.org

10001 discussions

OCSP in OpenLDAP
by Thomas Kwan 23 Aug '11

23 Aug '11

Hi, I would like to ask something about OCSP with OpenLDAP. Is there any setup for OCSP in OpenLDAP? How can I config it? Cheers! TKwan

2 1

Unable to build MinGW OpenLDAP in Cygwin: gcc no longer supports the "-mno-cygwin" flag?
by daisy.wu＠emc.com 23 Aug '11

23 Aug '11

Hi, OpenLDAP developers, I am trying to build OpenLDAP client libraries on Windows by following the instructions listed on the OpenLDAP.org Faq-O-Matic. Building MinGW OpenLDAP in a Cygwin Environment http://www.openldap.org/faq/data/cache/302.html In the MinGW Support in Cygwin section http://www.openldap.org/faq/data/cache/301.html To create the wrapper script, start the Cygwin bash shell, and execute the following: $ cd /usr/bin $ cat > mgcc #!/bin/sh gcc -mno-cygwin $* ^D The problem is that it seems gcc no longer supports the "-mno-cygwin" flag: $ gcc -mno-cygwin gcc: The -mno-cygwin flag has been removed; use a mingw-targeted cross-compiler. I am currently using Cygwin version ... $ uname -a CYGWIN_NT-6.1-WOW64 hostname 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin And my gcc version is ... $ gcc -v Using built-in specs. Target: i686-pc-cygwin Configured with: /gnu/gcc/releases/respins/4.3.4-4/gcc4-4.3.4-4/src/gcc-4.3.4/configure --srcdir=/gnu/gcc/releases/respins/4.3.4-4/gcc4-4.3.4-4/src/gcc-4.3.4 --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/lib --datadir=/usr/share --localstatedir=/var --sysconfdir=/etc --infodir=/usr/share/info --mandir=/usr/share/man -C --datadir=/usr/share --infodir=/usr/share/info --mandir=/usr/share/man -v --with-gmp=/usr --with-mpfr=/usr --enable-bootstrap --enable-version-specific-runtime-libs --with-slibdir=/usr/bin --libexecdir=/usr/lib --enable-static --enable-shared --enable-shared-libgcc --disable-__cxa_atexit --with-gnu-ld --with-gnu-as --with-dwarf2 --disable-sjlj-exceptions --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --disable-symvers --enable-libjava --program-suffix=-4 --enable-libgomp --enable-libssp --enable-libada --enable-threads=posix --with-arch=i686 --with-tune=generic --enable-libgcj-sublibs CC=gcc-4 CXX=g++-4 CC_FOR_TARGET=gcc-4 CXX_FOR_TARGET=g++-4 GNATMAKE_FOR_TARGET=gnatmake GNATBIND_FOR_TARGET=gnatbind --with-ecj-jar=/usr/share/java/ecj.jar Thread model: posix gcc version 4.3.4 20090804 (release) 1 (GCC) Any help would be much appreciated. Thanks. Daisy Wu Daisy.wu(a)emc.com<mailto:Daisy.wu@emc.com>

1 0

syncrepl broken, and I can't update anything on the server
by Alister Forbes 23 Aug '11

23 Aug '11

All, I have two servers, bru-1 and rtp-1 At one point I had cn=config working properly, and somehow managed to mess that up. The situation I'm in now is that syncing between the two machines doesn't work, and I can't make any changes to the configs. There are no special configurations, no SASL, or Kerberos, just plain passwords. I've been through the Server guide, and hopefully I'm just missing something, but I can't seem to find any indication of a way to solve my problem. bru-1 is running solaris10, and rtp-1 is running RHEL 5 , both with hand compiled openldap 2.4.23 bru-1: dn: cn=config olcServerID: 1 ldap://rtp-1.cisco.com olcServerID: 5 ldap://bru-1.cisco.com # {0}config, config dn: olcDatabase={0}config,cn=config olcSyncrepl: {0}rid=005 provider=ldap://bru-1.cisco.com binddn ="cn=admin,cn=config" bindmethod=simple credentials="testpass" searchbase="cn =config" type=refreshAndPersist retry="5 5 300 5" timeout=3 rtp-1 dn: cn=config olcServerID: 1 ldap://rtp-1.cisco.com olcServerID: 5 ldap://bru-1.cisco.com # {0}config, config dn: olcDatabase={0}config,cn=config olcSyncrepl: {0}rid=005 provider=ldap://bru-1.cisco.com binddn ="cn=admin,cn=config" bindmethod=simple credentials="testpass" searchbase="cn =config" type=refreshAndPersist retry="5 5 300 5" timeout=3 I'm having to run them with olcMirrorMode set to False at the moment, because if I try to startup bru-1 with mirror mode enabled, it crashes out. Aug 16 13:35:32 bru-1.cisco.com slapd[14591]: [ID 600618 local4.debug] olcServerID: value #2: SID=0x005 (listener=ldap:///) Aug 16 13:35:33 bru-1.cisco.com slapd[14591]: [ID 309573 local4.debug] olcSyncrepl: value #0: syncrepl will eventually stop retrying; the "retry" parameter should end with a '+'. Aug 16 13:35:33 bru-1.cisco.com slapd[14591]: [ID 942748 local4.debug] Config: ** successfully added syncrepl rid=005 "ldap://bru-1.cisco.com" Aug 16 13:35:33 bru-1.cisco.com slapd[14591]: [ID 801593 local4.debug] olcMirrorMode: value #0: <olcMirrorMode> database is not a shadow Aug 16 13:35:33 bru-1.cisco.com slapd[14591]: [ID 183426 local4.debug] config error processing olcDatabase={0}config,cn=config: <olcMirrorMode> database is not a shadow Aug 16 13:35:33 bru-1.cisco.com slapd[14591]: [ID 486161 local4.debug] slapd stopped. Aug 16 13:35:33 bru-1.cisco.com slapd[14591]: [ID 432338 local4.debug] connections_destroy: nothing to destroy. Can anyone give me a pointer in the right direction please? Even just how to get my database back to being a shadow so I can work on the replication problem later. I realise it could all be linked, so this is the sort of log error I'm seeing when I try running. It looks almost like a password problem, but that doesn't make any sense, as I can do searches on both machines with ldapsearch, or even phpldapadmin. Bru-1: Aug 16 13:39:51 bru-1.cisco.com slapd[14662]: [ID 445809 local4.debug] do_syncrepl: rid=008 rc -1 retrying (4 retries left) Aug 16 13:39:51 bru-1.cisco.com slapd[14662]: [ID 445809 local4.debug] do_syncrepl: rid=007 rc -1 retrying (4 retries left) Aug 16 13:39:51 bru-1.cisco.com slapd[14662]: [ID 319573 local4.debug] slap_client_connect: URI=ldap://rtp-1.cisco.com DN="cn=root,dc=ca" ldap_sasl_bind_s failed (49) Aug 16 13:39:51 bru-1.cisco.com slapd[14662]: [ID 445809 local4.debug] do_syncrepl: rid=006 rc 49 retrying (4 retries left) rtp-1: Aug 16 05:16:11 rtp-1 slapd[19928]: syncrepl_entry: rid=005 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Aug 16 05:16:11 rtp-1 slapd[19928]: syncrepl_entry: rid=005 be_search (0) Aug 16 05:16:11 rtp-1 slapd[19928]: syncrepl_entry: rid=005 cn={1}DUAConfigProfile,cn=schema,cn=config Aug 16 05:16:11 rtp-1 slapd[19928]: null_callback : error code 0x35 Aug 16 05:16:11 rtp-1 slapd[19928]: syncrepl_entry: rid=005 be_add cn={1}DUAConfigProfile,cn=schema,cn=config (53) Aug 16 05:16:11 rtp-1 slapd[19928]: syncrepl_entry: rid=005 be_add cn={1}DUAConfigProfile,cn=schema,cn=config failed (53) Aug 16 05:16:11 rtp-1 slapd[19928]: do_syncrepl: rid=005 rc 53 retrying (4 retries left) Any clues or hints, would be greatly appreciated -- Alister Forbes TACSUNS _.|._.|._ Cisco Systems Please avoid sending me Word or PowerPoint attachments. See - http://www.gnu.org/philosophy/no-word-attachments.html

2 3

Indexing, use of slapindex
by anax 22 Aug '11

22 Aug '11

Hi listers Installation here: openldap-servers-2.4.15-7.fc11.i586 One master server, two backup servers (syncrepl). All authentication and mailing is managed by ldap. 1. About indexing: When i check the slapd-log, i see many <= bdb_equality_candidates: (uidNumber) not indexed <= bdb_equality_candidates: (gidNumber) not indexed In the discussion about slapd tuning http://www.openldap.org/doc/admin24/tuning.html#Indexes, however, i read that if each entry in a certain set of ldap-entries has got the candidate-attribute, it is not worth while to index the attribute, because slapd needs to read each entry in any case in order to find the requested one. this is the case for uidNumber as well as gidNumber, because both are compulsory attributes for objectClass posixAccount. My first question: is it therefore correct to disregard the above indexing requests of slapd? 2. About slapindex: When it comes to use slapindex, the docu is not clear about how to do that. Some places say, that you need to stop slapd entirely, some places say that it is sufficient to put slapd in read-only mode for the corresponding background database, which in this case would be /etc/openldap/slapd.d/cn=config/olcDatabase\=\{2\}bdb.ldif this file contains both the olcReadOnly and the olcDbIndex attributes. So i could just add the following two lines in the above file: olcDbIndex: uidNumber eq olcDbIndex: gidNumber eq set the olcReadOnly attribute to TRUE, and restart slapd, and everything would be done automatically? Or would i need to invoke slapindex additionally with the following command slapindex -c And if i had to start slapindex additionally, would slapindex tell me, that the database is in read-only mode, so no changes are possible, not even index changes? And, if i had to start slapindex additionally, i would do it as root. the files generated by slapindex would they be owned by root (inaccessible by slapd) or by the slapd user? Would the new indexes be propagated to the backup servers by syncrepl automatically? If not, what would i have to change on the backup servers? Thank you for your attention suomi

2 2

openldap syncrepl Provider with Slave(older version)
by Rupesh Thakkar 21 Aug '11

21 Aug '11

Hi , My application was using replication using Slurpd . Now, we want to move to openldap version 2.4 (RHEL 6.x)from 2.2, so I should use syncrepl instead slurpd. Replication clients(slaves) can still be of older version(2.2) I am tried to replication setup using sincerely using doc http://www.openldap.org/doc/admin24/replication.html I am following first of two topologies suggested for replacing slurped in doc http://www.openldap.org/doc/admin24/replication.html It says (Master/Provider configuration) ----->Proxy consumer configuration --sincerely--->old Slaves(which were working with slurpd) Following are my Master and Proxy configuration file they are similar to what above documents says Master slapd.conf [ /usr/sbin/slapd -h ldap://localhost:389 -f /usr/share/openldap-servers/slapd.conf ] -------------------------------------------------------------------------------------------------------------------------------------------------------------- access to * by dn.base="cn=replicator,dc=Avaya" write by dn.base="cn=root,dc=Avaya" write by dn.base=umObjectGUID=31ff609ecb5e11e09542001a64e587d4,ou=People,dc=Avaya read by * break access to dn.base="" by * read access to dn.base="dc=Avaya" by * read access to dn.subtree="ou=People,dc=Avaya" by dn.exact="cn=root,dc=Avaya" write by users read by * read access to * by self write by * read database bdb suffix "dc=Avaya" rootdn "cn=root,dc=Avaya" rootpw secret rootpw Testpw # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. password-hash {CLEARTEXT},{SHA},{SSHA} directory /var/lib/ldap index objectClass eq index default sub index ou,cn,mail,surname,givenname eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub index entryCSN eq index entryUUID eq checkpoint 1024 15 cachesize 10000 idlcachesize 10000 #syncrepl Provider for primary db overlay syncprov syncprov-checkpoint 1000 60 # Let the replica DN have limitless searches limits dn.exact="umObjectGUID=218afb42cb5e11e09542001a64e587d4,ou=People,dc=Avaya" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited limits dn.exact="cn=replicator,dc=Avaya" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited Proxy slapd_p.conf [ /usr/sbin/slapd -h ldap://localhost:50389 -f /usr/share/openldap-servers/slapd_p.conf ] -------------------------------------------------------------------------------------------------------------------------------------------------------------- access to * by * read # Consumer Proxy that pulls in data via Syncrepl and pushes out via slapd-ldap database ldap # ignore conflicts with other databases, as we need to push out to same suffix hidden on suffix "dc=Avaya" rootdn "cn=slapd-ldap,dc=Avaya" uri ldap://localhost:50389 rootpw secret rootpw testing lastmod on acl-bind bindmethod=simple binddn="cn=replicator,dc=Avaya" credentials=Testpw #binddn="umObjectGUID=31ff609ecb5e11e09542001a64e587d4,ou=People,dc=Avaya" #credentials=1234 syncrepl rid=001 provider=ldap://localhost:389/ binddn="cn=replicator,dc=Avaya" #binddn="umObjectGUID=31ff609ecb5e11e09542001a64e587d4,ou=People,dc=Avaya bindmethod=simple credentials=Testpw #credentials=1234 searchbase="dc=Avaya" type=refreshAndPersist retry="5 5 300 5" overlay syncprov 1)I am able to query Master database but not to proxy database why so ? ps -ef | grep slapd /usr/sbin/slapd -h ldap://localhost:389 -f /usr/share/openldap-servers/slapd.conf /usr/sbin/slapd -h ldap://localhost:50389 -f /usr/share/openldap-servers/slapd_P.conf lsearch query to master database(port 389) is working /usr/bin/ldapsearch -x -h localhost -p 389 -D"cn=root,dc=Avaya" -w w00dstock -b"dc=Avaya" '(objectClass=*)' Why following query to proxy (50389) is failing even though database has read permissions to everyone . /usr/bin/ldapsearch -x -h localhost -p 50389 -D"cn=slapd-ldap" -w w00dstock -b"dc=Avaya" '(objectClass=*)' ldap_bind: Invalid credentials (49) 2)is "cn=replicator,dc=Avaya" here should be rootdn user or normal database(slapd) user ?. I tried this ldap slapd user "umObjectGUID=31ff609ecb5e11e09542001a64e587d4,ou=People,dc=Avaya" and with password "1234" and restarting both master and proxy still query fails Can you point me where am I wrong ? Thanks Rupesh "This email and any files transmitted with it contain confidential, proprietary, privileged information of Symphony Services Corp (India) Pvt. Ltd. and are intended solely for the use of the recipient/s to whom it is addressed. Any unauthorized notifying, copying or distributing of this e-mail, directly or indirectly, and the contents therein in full or part is prohibited by any entity who is not a recipient. Any email received inadvertently or by mistake should be deleted by the entity who is not a recipient thereof. You may be pleased to notify the sender immediately by email and the email should be deleted from your system".

2 2

setting max ssf with ldap_set_option
by Ken Dreyer 19 Aug '11

19 Aug '11

I have a small LDAP utility (msktutil) that talks to Active Directory using GSSAPI over TLS. I'm trying to set the SASL parameter "maxssf" to "0" in the code. I've found that in a recent version of OpenLDAP (2.4.24), modifying LDAP_OPT_X_SASL_SSF_MAX with ldap_set_option() has no effect. The basic code is sasl_ssf_t max_ssf = 0; printf( "setting max ssf to %d\n", max_ssf ); ldap_set_option(ld, LDAP_OPT_X_SASL_SSF_MAX, &max_ssf) Subsequent ldap_get_option() calls show that the value is not changing, as does the output when I bind with ldap_sasl_interactive_bind_s(). I would at the very least expect ldap_set_option() to return something other than LDAP_OPT_SUCCESS here. Am I hitting a bug in OpenLDAP, or am I really off track ? :) I've attached a small test case (gcc -o test test.c -lldap -llber). This works as I expect in both 2.3.43 and 2.4.23, and fails in 2.4.24. RHEL5: openldap-2.3.43-12.el5_6.7 ./test LDAP_OPT_X_SASL_SSF_MAX before setting = 2147483647 setting max ssf to 0 LDAP_OPT_X_SASL_SSF_MAX after setting = 0 RHEL6: openldap-2.4.23-15.el6_1.1.x86_64 ./test LDAP_OPT_X_SASL_SSF_MAX before setting = 2147483647 setting max ssf to 0 LDAP_OPT_X_SASL_SSF_MAX after setting = 0 Fedora 15: openldap-2.4.24-3.fc15.i686 ./test LDAP_OPT_X_SASL_SSF_MAX before setting = 2147483647 setting max ssf to 0 LDAP_OPT_X_SASL_SSF_MAX after setting = 2147483647

3 3

Re: Server Hangs
by Quanah Gibson-Mount 19 Aug '11

19 Aug '11

--On Tuesday, August 16, 2011 3:51 PM -0700 David Engeset <davidke(a)whidbey.net> wrote: > Below is how I generally configure BDB and OpenLDAP for normal > operational use. > I configured BDB with no parameters for all versions from 4.2 to > 5.1, so I ran: > > ../dist/configure > make&& make install For building BDB on *nix systems, you should specify: --enable-posixmutexes --with-mutex=POSIX/pthreads > For the debugging I did the following for BDB: > > env CFLAGS=-O2 ../dist/configure --enable-debug You need to use "-g" as I stated previously. CFLAGS="-g -O2 -fPIC" are the flags I pass to BDB. What we are looking for is the gcc debugging symbols. The --enable-debug flag looks like it does some internal debugging stuff in the BDB code which isn't really what we're asking for. > make&& make install > > For OpenLDAP: > > export LD_LIBRARY_PATH="/usr/local/BerkeleyDB.4.8/lib" > env CPPFLAGS="-I/usr/local/BerkeleyDB.4.8/include" CFLAGS="-g -O0" \ > LDFLAGS="-L/usr/local/BerkeleyDB.4.8/lib" ./configure --enable-wrappers \ > --enable-crypt --with-cyrus-sasl --with-tls --enable-debug > make depend&& make&& make install STRIP='' This looks good. Can you please re-generate your stack trace with a correctly build BDB behind openldap? Thanks! --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

3 5

Replication with cn=config
by Nocturn 18 Aug '11

18 Aug '11

I'm trying to set up repliction with OpenLDAP on SL:RHEL 6.1. OpenLDAP is by default configured with cn=config, but the replication documentation is still in the old slapd.conf format. Can anyone point me out how to get this up and running with cn=config? Thanks

3 3

migrating contents from openldap-2.1 to openldap-2.3.37
by Michael Kershaw 18 Aug '11

18 Aug '11

All, I've currently been tasked with migrating the contents of a contained ldap environment running openldap-2.1 to a new development server running sles11 with openldap-2.3.37. I've begun to populate the new environment, but have hit an "Invalid DN syntax" error that I'm not quite sure how to get around yet. I'm new to ldap from a server point of view, so I'm learning as I chug through this. This piece is what's in the existing 2.1: dn: group-name=EDI Technician,ou=group,ou=edi,dc=coat,dc=com objectClass: group-roles group-name: EDI Technician roles: EDI Technician And when I go to add: ldapadd -x -W -D "cn=edi_admin,ou=edi,dc=coat,dc=com" -f ./edi-tech_roles.ldif Enter LDAP Password: adding new entry "group-name=EDI Technician,ou=group,ou=edi,dc=coat,dc=com" ldap_add: Invalid DN syntax (34) additional info: invalid DN Is it the "group-name" that's no longer valid syntax? If so, is there an equivalent? Any help is appreciated! Mike

4 3

LDAP Stopping Frequently
by Nishant Goli -X (ngoli - Exobase Corporation at Cisco) 18 Aug '11

18 Aug '11

Hi Team, I have set up Open LDAP with Oracle as backend DB using back sql. Everything was running fine until recently. LDAP started going down frequently with the following line in the log. slapd: entry-id.c:867: backsql_get_attr_vals: Assertion `j < oldcount + count' failed and then the process goes down. Any help in troubleshooting this issue is greatly appreciated. Thanks Nishant

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical