openldap-technical April 2011

openldap-technical@openldap.org

97 participants
98 discussions

Custom ldapSyntax
by Peter Schütt 05 Apr '11

05 Apr '11

Hallo, I use OpenLDAP 2.4.19 and I try to build an own gender attribute. I need a custom syntax for the value, "M" or "W". I cannot find a description for ldapsyntax, I only find an example and I try this: attributetype ( 1.3.6.1.4.1.xxxxxx.2.2.4.4 NAME ( 'gender' 'sex' ) DESC 'Gender: M for male, F for female' SYNTAX 1.3.6.1.4.1.xxxxxx.2.2.5.1 SINGLE-VALUE ) ldapsyntax ( 1.3.6.1.4.1.xxxxxx.2.2.5.1 NAME 'GenderType' DESC 'Case Insensitive Gender Type' X-VALIDATE-RE '^(?i)M|W|m|w$' ) but I think X-VALIDATE-RE is an extension for another LDAP-Server not for OpenLDAP because it does not work: [LDAP: error code 21 - gender: no validator for syntax 1.3.6.1.4.1.xxxxxx.2.2.5.1] How can I create my own custom syntax? Thanks for any hints. Ciao Peter Schütt

3 3

update referral per rid
by Hendrik van der Ploeg 05 Apr '11

05 Apr '11

Hello everyone, I have multiple syncrepl rid's defined. Every rid points to a different physical ldapprovider. But they all end with dc=domain,dc=nl. Like this: site 1: dc=n010101,dc=domain,dc=nl site 2: dc=n010102,dc=domain,dc=nl CONFIG EXAMPLE: suffix "dc=domain,dc=nl" directory /var/lib/ldap syncrepl rid=000 provider=ldaps://pdc.provider0.domain.nl syncrepl rid=001 provider=ldaps://pdc.provider1.domain.nl What I want is to assign per site/syncrepl-rid a referral so the correct update request will be sent to the right ldapprovider. Is it possible to do this? Help is very much appreciated. Best regards, Hendrik van der Ploeg Noordwijkerhout The Netherlands

1 0

Re: Antwort: Re: RHEL 6 OpenLDAP 2.4.19-15.el6 init problem
by Quanah Gibson-Mount 04 Apr '11

04 Apr '11

--On April 4, 2011 3:00:34 PM +0200 Simone Piccardi <piccardi(a)truelite.it> wrote: Hi Simone. First, keep your replies on the list. > On 01/04/2011 18:11, Quanah Gibson-Mount wrote: >> Hi Markus, >> >> While I understand this is often the case with companies, this policy is >> short sighted. If you want to have a stable, secure, and functional LDAP >> server, then you need to be able to build OpenLDAP from source. >> > That's true, but is true also for a lot of other programs. However, OpenLDAP is an amazingly complex piece of software, which a lot of other programs are not. > And if you need to build everything from source, it will become soon a > manutention nightmare (often you have to do so for a lot of different > machines). I didn't say for him to build everything from source. I said to build OpenLDAP from source. Personally, I do build everything that OpenLDAP uses from source myself, short of the kernel & gcc. > So that kind of policy is a must in a lot of cases, and your suggestion > cannot be accepted. I don't care whether or not you accept what I said. It wasn't a suggestion, it is the result of over a decade of experience working with LDAP software from a number of projects. > Not having good packages in a distribution harms everyone, but > unfortunately this is a general problem, not affecting just RedHat or > OpenLDAP. Correct. And this is something the OpenLDAP Foundation has zero control over. The distributions decide what OpenLDAP releases they include. The distributions decide what patches they apply to their OpenLDAP builds. The distributions occasionally apply their own patches to OpenLDAP that can break it in horrible ways. Distributions do not update their OpenLDAP builds after they release a particular OS, either. So again, if someone chooses against better advice to use the build a distribution provides, then they need to seek help from those who provide the build they are using. If that is not acceptable to them, then they either need to learn to build OpenLDAP themselves so they can use current releases rather than ones that have had hundreds of bugs fixed since their release, or they should use a version of OpenLDAP that comes with support from a company that provides such a thing. Symas is a good example of that. If they choose to use a distribution build, and then contact the OpenLDAP foundation about problems they face with it, the first thing they are going to be asked to do is to upgrade their software. If their policy doesn't allow that, then they need to contact the distributor. Not the foundation. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: 8 principal limitation in openldap
by Srivatsav M 04 Apr '11

04 Apr '11

appreciate any help/pointers on resolving this issue. thanks Ramakant > On 1 April 2011 03:25, Srivatsav M <srivatsav.mudumba(a)gmail.com> wrote: > >> Hi, >> >> I was triaging this issue and I ran into another mysterious area, it >> doesn't look like the number (8) of principals/RDN is the problem and infact >> the length/size of the RDN's could be the issue. Please find the >> /etc/ldap.conf files attached renamed according to the AD/openldap server >> being configured. >> >> a. In the ad_ldap_conf_size the number of characters is around 3137 for >> the nss_base_<map>. On line 122, if i just make the 80 as 8 in the end of >> the string, the command "getent passwd" is working and it lists all the >> users registered in the ldap.conf file but otherwise it doesn't show any >> user. >> >> b. In the open_ldap_conf_size_issue the number of characters is around >> 3103 for the nss_base_<map>. In the end of the file if i just comment the >> last two lines, the "getent passwd" is working and it lists all the users >> registered in the ldap.conf file but otherwise it doesn't show any user. >> >> from these findings this looks more like some buffer issue, can you >> please help me with the following. >> 1. Any particular method/file that I should be looking for to check this >> buffer size may be even in the nss_ldap library or so >> 2. If there is a buffer size issue of say around 3137 characters (bytes >> for that), what would be the best value to increase it. >> >> appreciate any help >> >> Thanks >> Ramakanth >> >> On 30 March 2011 01:17, Srivatsav M <srivatsav.mudumba(a)gmail.com> wrote: >> >>> Please find below the answers to your questions: >>> >>> 1. > >> We are using OpenLDAP for authenticating users registered in a >>> LDAP >>> >>> > >> server (Open LDAP, Active Directory). >>> >>> Which one? Or both? >>> >>> Our dev environment has openLDAP and AD servers and we have tested this issue against each of them individually and are able to reproduce it against both the types of LDAP servers >>> >>> 2. Users shouldn't be "registered in the /etc/ldap.conf file". >>> >> Can you please help me understand why I shouldn't be using this in the >>> ldap.conf file? >>> >>> 3. Please supply a full copy of your /etc/ldap.conf, or at least a >>> representative one, and provide the example output of 'getent passwd >>> username' and 'groups >>> >>> >> attached along with this mail >>> >>> username' for the user who doesn't authenticate. You may also want to supply >>> the relevant PAM configuration files. >>> >>> $ getent passwd >>> root <xxxxxxxxx> >>> test_user:somepwd:1002:1002:Test User:/home/testuser:/bin/bash >>> test_people1:*:10004:10004:Test People1:/home/test_people1:/bin/bash >>> >>> >> All external users are not able to login after adding the 8th principal/RDN >>> >>> /etc/pam.d/common-auth >>> >>> auth required pam_env.so >>> auth sufficient pam_ldap.so use_first_pass >>> auth required pam_unix2.so >>> >>> /etc/pam.d/common-account >>> >>> account required pam_unix2.so >>> account sufficient pam_localuser.so >>> account required pam_ldap.so use_first_pass >>> >>> /etc/pam.d/common-session >>> >>> >>> session required pam_limits.so >>> session required pam_unix2.so >>> session required pam_mkhomedir.so skel=/etc/skel/ >>> session optional pam_ldap.so >>> session optional pam_umask.so >>> >>> Also, please provide details of your LDAP client (distribution release, what versions of nss_ldap and pam_ldap you are running). >>> >>> >> openldap2-client-2.3.32-0.25 >>> >> nss_ldap-259-4.3 >>> >>> 4. Do we know what the actual problem is? Do we know it would be solved >>> by nss-ldapd? >>> >>> There might be a simple misunderstanding here, or a simple configuration problem, and switching software might not solve that. >>> >>> Additionally, the distribution in question may have a different preferred LDAP client. >>> >>> >> based on the above information, would it be possible for pointing any config. issues? , please do let me know if you need any further information. >>> >>> thanks >>> >>> Ramakanth >>> >>> >>> On 25 March 2011 20:23, Marco Pizzoli <marco.pizzoli(a)gmail.com> wrote: >>> >>>> Hi, >>>> I could be corrected if I'm wrong, but this problem is not related to >>>> OpenLDAP. It's a nss_ldap problem. >>>> nss_ldap is a client library that's used by linux vendors to achieves >>>> seamless integration of users against *a* LDAP server. >>>> >>>> I had a similar problem with a complex configuration and bypassed (not >>>> solved) the problem by modifying my client configuration. >>>> >>>> I reduced the number of ldap server configured to be accessed: from 4 to >>>> 3. >>>> I reduced the number of users defined in *nss_initgroups_ignoreusers*directive: i had about 40 listed in it... >>>> >>>> Etc... >>>> >>>> Make some tries and tell me if you can solve it. >>>> >>>> Marco >>>> >>>> >>>> >>>> On Thu, Mar 24, 2011 at 9:25 PM, Srivatsav M < >>>> srivatsav.mudumba(a)gmail.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> We are using OpenLDAP for authenticating users registered in a LDAP >>>>> server (Open LDAP, Active Directory). After adding 8 principals >>>>> (/etc/ldap.conf), none of the users registered in the /etc/ldap.conf file >>>>> are able to login. >>>>> >>>>> nss_base_passwd >>>>> OU=engg,DC=mycompany,DC=region,DC=someplace,DC=myarea,DC=compname,DC=parentcompname >>>>> nss_base_shadow >>>>> OU=engg,DC=mycompany,DC=region,DC=someplace,DC=myarea,DC=compname,DC=parentcompname >>>>> nss_base_group >>>>> OU=engg,DC=mycompany,DC=region,DC=someplace,DC=myarea,DC=compname,DC=parentcompname >>>>> >>>>> >>>>> Can you please share the reason for this 7 limitation in the open ldap >>>>> library. or how I can fix this issue. I am looking i for the header file in >>>>> the source files whhich has this constant or limitation defined. >>>>> >>>>> Tried googling, but it appears that no one has encountered this issue. >>>>> Some customers are running into this issue and it has become a severity 1 >>>>> issue to fix. >>>>> >>>>> Thanks >>>>> Ramakanth >>>>> >>>> >>>> >>>> >>>> -- >>>> _________________________________________ >>>> Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi. >>>> Jim Morrison >>>> >>> >>> >> >

2 1

"ldap_sasl_bind_s failed (-1)" makes me in trouble... [episode 2]
by Olivier Pavilla 04 Apr '11

04 Apr '11

As I said in my last mail. I got this: slap_client_connect: URI=ldaps://wtf.wtf.fr:636 DN="cn=replicaiufm,ou=useraccess,dc=wtf,dc=fr" ldap_sasl_bind_s failed (-1) There's this line in the /etc/ldap/ldap.conf: TLS_REQCERT never the certificate is localized in /etc/ldap/cacerts unverre:/home/olivier# cat /etc/ldap/ldap.conf | grep "TLS" TLS_CACERT /etc/ldap/cacerts/chain-4302-wtf.wtf.fr.pem TLS_CERT /etc/ldap/cacerts/chain-4302-wtf.wtf.fr.pem # TLS_CACERTDIR /etc/ldap/cacerts TLS_REQCERT never So then I added this to /etc/ldap/slapd.conf: loglevel stats args trace sync I restarted slapd: slapd -u openldap -g openldap -l LOCAL4 -s 0 -h ldap:/// ldaps:/// tail -f /var/log/syslog wrote this: Apr 4 09:12:39 unverre slapd[9061]: slapd stopped. Apr 4 09:13:21 unverre slapd[9069]: bdb_back_initialize: initialize BDB backend Apr 4 09:13:21 unverre slapd[9069]: bdb_back_initialize: Berkeley DB 4.6.21: (September 27, 2007) Apr 4 09:13:21 unverre slapd[9069]: bdb_db_init: Initializing BDB database Apr 4 09:13:21 unverre slapd[9069]: >>> dnPrettyNormal: <dc=wtf,dc=fr> Apr 4 09:13:21 unverre slapd[9069]: <<< dnPrettyNormal: <dc=wtf,dc=fr>, <dc=wtf,dc=fr> Apr 4 09:13:21 unverre slapd[9069]: >>> dnPrettyNormal: <cn=luz2,dc=wtf,dc=fr> Apr 4 09:13:21 unverre slapd[9069]: <<< dnPrettyNormal: <cn=luz2,dc=wtf,dc=fr>, <cn=luz2,dc=wtf,dc=fr> Apr 4 09:13:21 unverre slapd[9069]: >>> dnNormalize: <cn=replicaiufm,ou=useraccess,dc=wtf,dc=fr> Apr 4 09:13:21 unverre slapd[9069]: <<< dnNormalize: <cn=replicaiufm,ou=useraccess,dc=wtf,dc=fr> Apr 4 09:13:21 unverre slapd[9069]: >>> dnNormalize: <dc=wtf,dc=fr> Apr 4 09:13:21 unverre slapd[9069]: <<< dnNormalize: <dc=wtf,dc=fr> Apr 4 09:13:21 unverre slapd[9069]: >>> dnNormalize: <cn=Subschema> Apr 4 09:13:21 unverre slapd[9069]: <<< dnNormalize: <cn=subschema> [cut] Apr 4 09:13:21 unverre slapd[9070]: slapd startup: initiated. Apr 4 09:13:21 unverre slapd[9070]: backend_startup_one: starting "cn=config" Apr 4 09:13:21 unverre slapd[9070]: config_back_db_open Apr 4 09:13:21 unverre slapd[9070]: config_build_entry: "cn=config" Apr 4 09:13:21 unverre slapd[9070]: config_build_entry: "cn=module{0}" Apr 4 09:13:21 unverre slapd[9070]: config_build_entry: "cn=schema" Apr 4 09:13:21 unverre slapd[9070]: config_build_entry: "cn={0}core" Apr 4 09:13:21 unverre slapd[9070]: config_build_entry: "cn={1}cosine" Apr 4 09:13:21 unverre slapd[9070]: config_build_entry: "cn={2}nis" Apr 4 09:13:21 unverre slapd[9070]: config_build_entry: "cn={3}inetorgperson" Apr 4 09:13:21 unverre slapd[9070]: config_build_entry: "cn={4}internet2" Apr 4 09:13:21 unverre slapd[9070]: config_build_entry: "cn={5}supann" Apr 4 09:13:21 unverre slapd[9070]: config_build_entry: "cn={6}mailUniv" Apr 4 09:13:21 unverre slapd[9070]: config_build_entry: "cn={7}unrc" Apr 4 09:13:21 unverre slapd[9070]: config_build_entry: "olcDatabase={-1}frontend" Apr 4 09:13:21 unverre slapd[9070]: config_build_entry: "olcDatabase={0}config" Apr 4 09:13:21 unverre slapd[9070]: config_build_entry: "olcDatabase={1}bdb" Apr 4 09:13:21 unverre slapd[9070]: config_build_entry: "olcOverlay={0}syncprov" Apr 4 09:13:21 unverre slapd[9070]: backend_startup_one: starting "dc=wtf,dc=fr" Apr 4 09:13:21 unverre slapd[9070]: bdb_db_open: "dc=wtf,dc=fr" Apr 4 09:13:21 unverre slapd[9070]: bdb_db_open: database "dc=wtf,dc=fr": dbenv_open(/var/lib/ldap). Apr 4 09:13:21 unverre slapd[9070]: => bdb_entry_get: ndn: "dc=wtf,dc=fr" Apr 4 09:13:21 unverre slapd[9070]: => bdb_entry_get: oc: "(null)", at: "contextCSN" Apr 4 09:13:21 unverre slapd[9070]: bdb_dn2entry("dc=wtf,dc=fr") Apr 4 09:13:21 unverre slapd[9070]: => bdb_dn2id("dc=wtf,dc=fr") Apr 4 09:13:21 unverre slapd[9070]: <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) Apr 4 09:13:21 unverre slapd[9070]: slapd starting Apr 4 09:13:21 unverre slapd[9070]: =>do_syncrepl rid=008 Apr 4 09:13:21 unverre slapd[9070]: slap_client_connect: URI=ldaps://wtf.wtf.fr:636 DN="cn=replicaiufm,ou=useraccess,dc=wtf,dc=fr" ldap_sasl_bind_s failed (-1) Apr 4 09:13:21 unverre slapd[9070]: do_syncrepl: rid=008 rc -1 retrying Anyone can tall me what does mean this: slap_client_connect: URI=ldaps://wtf.wtf.fr:636 DN="cn=replicaiufm,ou=useraccess,dc=wtf,dc=fr" ldap_sasl_bind_s failed (-1) Do I got this message because of this: bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) WTH is DB_NOTFOUND? Does thi mean DB_CONFIG is missing? However unverre:/home/olivier# ls /var/lib/ldap/DB* /var/lib/ldap/DB_CONFIG -- S.C.I.R.C. Orléans (Bourgogne) - I.U.F.M. Centre-Val de Loire 72 Rue du Faubourg Bourgogne - 45044 ORLEANS Cedex 1 Tel : 02-38-49-**-** , mailto:ølivier.pavilla@univ-orleans.fr

2 1

could not work in C++?
by owen nirvana 04 Apr '11

04 Apr '11

I try to access ldap data in C++, and write a small example which open and close ldap, compiled by g++ error is the following: error: 'ldap_init' was not decalred in this scope error: 'ldap_simple_bind_s' was not decalred in this scope error: 'ldap_unbind' was not decalred in this scope I have added extern "C" {} block. With my means, it will be compiled using gcc actually. So it work fine in gcc, it should be fine in g++. gtalk:freeespeech@gmail.com

2 2

"ldap_sasl_bind_s failed (-1)" makes me in trouble...
by Olivier Pavilla 03 Apr '11

03 Apr '11

Hi everybody I'm running on a Lenny debian 64bit an openldap server (in fact, I'm trying :-). When I do: unverre:/home/olivier# slapd -VV @(#) $OpenLDAP: slapd 2.4.17 (Jan 12 2011 14:58:43) $ @barber:/build/buildd-openldap_2.4.17-2.1~bpo50+1-amd64-2bRKLL/openldap-2.4.17/debian/build/servers/slapd So... I do this: unverre:/home/olivier# slapd -d 16383 -u openldap -g openldap It shows: [blabla] ldap_create ldap_url_parse_ext(ldaps://wtf.wtf.fr:636) ldap_sasl_bind_s ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP wtf.wtf.fr:636 ldap_new_socket: 13 ldap_prepare_socket: 13 ldap_connect_to_host: Trying XXX.XXX.XXX.XXX:636 ldap_pvt_connect: fd: 13 tm: -1 async: 0 slap_client_connect: URI=ldaps://wtf.wtf.fr:636 DN="cn=replicaiufm,ou=useraccess,dc=wtf,dc=fr" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=008 rc -1 retrying daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero I'm lost in translation. I do not understand WTH is wrong. What does mean "ldap_sasl_bind_s failed (-1)"? Does My certificate is wrong? Did I do something wrong or what? In this case google is absolutely not my friend. Too much results for this kind of message. Thx in advance for your help. Kind regards -- S.C.I.R.C. Orléans (Bourgogne) - I.U.F.M. Centre-Val de Loire 72 Rue du Faubourg Bourgogne - 45044 ORLEANS Cedex 1 Tel : 02-38-49-**-** , mailto:ølivier.pavilla@univ-orleans.fr http://blog.linux-squad.com -

1 0

Compiling with SLAPI support and ACL caching
by Nick Milas 03 Apr '11

03 Apr '11

Hi, I have read here: http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg249720.html that "Compiling OpenLDAP with SLAPI support means that ACL caching is disabled". My question: Is this true for current Openldap versions as well? (I'm interested in versions 2.4.22 and later.) By the way, I have seen some earlier activity (e.g. thread: http://www.openldap.org/lists/openldap-devel/200507/msg00091.html) that SLAPI support was probably getting moved to an overlay, rather than being used as a compile option (if I understand well). Is there any update re. this "transition"? Thanks, Nick Milas

1 1

Problems with 4-way multi-master
by Mark 02 Apr '11

02 Apr '11

I've been testing a 4-way multi-master setup using OpenLDAP 2.4.25 and I'm having some sporadic problems with it that I'm having difficulty diagnosing.. I have four identical RHEL 4.9 machines on the same switch (NTP syncronized to same stratum 2 servers): dual-core Xeon 5110 1.60GHz 8GB RAM 100Mb full-duplex NIC OpenLDAP 2.4.25, BDB 4.8.30, OpenSSL 1.0.0d, Cyrus SASL 2.1.23 (using no tls/ssl at this time) I start the slapds with '-d conns,sync' then commence. I ldapadd 1000 DNs to one of the servers. After all the syncing has stopped I then compare the slapd contents against each other looking for differences. Occasionally there are as much as a couple hundred DNs missing from one or more of the instances. When that happens I've noticed that the mmaster with less DNs has lost its consumer connection to a mmaster provider (confirmed using lsof and netstat) and will never attempt a re-connect, but the provider still shows the connection (using lsof and netstat). When the consumer gets in this state I can connect to its cn=config and cn=monitor backends (and browse them) but when I try to connect to its multi-master'd backend the connection attempt just hangs. It's almost like the connect succeeds but the client is waiting for a response from the server (and never gets it). Also, the consumer slapd will not respond to a 'kill -TERM' at this time and must be 'kill -KILL'd. The same thing occurs sometimes when I delete the entire tree. I've been trying to catch logging information that might help but so far nothing's jumping out at me. While I continue to try to reproduce and parse through logfiles maybe someone can look at my slapd.confs below and see if I might have configured something wrong (I'm listing the original slapd.conf files below, but I've used slaptest to convert them to slapd.d/cn=config.ldif format): HOST1 slapd.conf: include /tmp/openldap/multi-master/etc/schema/core.schema include /tmp/openldap/multi-master/etc/schema/cosine.schema include /tmp/openldap/multi-master/etc/schema/nis.schema argsfile /tmp/openldap/multi-master/var/run/slapd.args pidfile /tmp/openldap/multi-master/var/run/slapd.pid threads 16 idletimeout 0 writetimeout 5 reverse-lookup off timelimit time.soft=30 time.hard=300 sizelimit size.soft=500 size.hard=1000 password-hash {SSHA} loglevel stats sync serverid 001 modulepath /tmp/openldap/multi-master/libexec moduleload back_monitor.la moduleload back_hdb.la moduleload syncprov.la database config rootdn cn=manager,cn=config rootpw {SSHA}yMFj3Y7KPh223NkkKLQsFeLUVm08Ckpm database monitor rootdn cn=manager,cn=monitor rootpw {SSHA}vPVSN8o8eRnLdC/bGS7yDwQGeH4BHc0R database hdb suffix dc=example,dc=com rootdn cn=manager,dc=example,dc=com rootpw {SSHA}0obbsJw5Yq2XAkdd/kS7vokaB9rrSOtI directory /tmp/openldap/multi-master/var/data/dc=example,dc=com cachesize 30000 cachefree 5 checkpoint 128 15 dncachesize 25000 idlcachesize 100000 index objectClass eq index entryCSN eq index entryUUID eq syncrepl rid=001 provider=ldap://host2:1389 type=refreshAndPersist interval=00:00:05:00 retry="15 +" searchbase="dc=example,dc=com" binddn="cn=manager,dc=example,dc=com" credentials="example_pass" starttls=no schemachecking=off syncrepl rid=002 provider=ldap://host3:1389 type=refreshAndPersist interval=00:00:05:00 retry="15 +" searchbase="dc=example,dc=com" binddn="cn=manager,dc=example,dc=com" credentials="example_pass" starttls=no schemachecking=off syncrepl rid=003 provider=ldap://host4:1389 type=refreshAndPersist interval=00:00:05:00 retry="15 +" searchbase="dc=example,dc=com" binddn="cn=manager,dc=example,dc=com" credentials="example_pass" starttls=no schemachecking=off HOST2 slapd.conf: include /tmp/openldap/multi-master/etc/schema/core.schema include /tmp/openldap/multi-master/etc/schema/cosine.schema include /tmp/openldap/multi-master/etc/schema/nis.schema argsfile /tmp/openldap/multi-master/var/run/slapd.args pidfile /tmp/openldap/multi-master/var/run/slapd.pid threads 16 idletimeout 0 writetimeout 5 reverse-lookup off timelimit time.soft=30 time.hard=300 sizelimit size.soft=500 size.hard=1000 password-hash {SSHA} loglevel stats sync serverid 002 modulepath /tmp/openldap/multi-master/libexec moduleload back_monitor.la moduleload back_hdb.la moduleload syncprov.la database config rootdn cn=manager,cn=config rootpw {SSHA}yMFj3Y7KPh223NkkKLQsFeLUVm08Ckpm database monitor rootdn cn=manager,cn=monitor rootpw {SSHA}vPVSN8o8eRnLdC/bGS7yDwQGeH4BHc0R database hdb suffix dc=example,dc=com rootdn cn=manager,dc=example,dc=com rootpw {SSHA}0obbsJw5Yq2XAkdd/kS7vokaB9rrSOtI directory /tmp/openldap/multi-master/var/data/dc=example,dc=com cachesize 30000 cachefree 5 checkpoint 128 15 dncachesize 25000 idlcachesize 100000 index objectClass eq index entryCSN eq index entryUUID eq syncrepl rid=001 provider=ldap://host1:1389 type=refreshAndPersist interval=00:00:05:00 retry="15 +" searchbase="dc=example,dc=com" binddn="cn=manager,dc=example,dc=com" credentials="example_pass" starttls=no schemachecking=off syncrepl rid=002 provider=ldap://host3:1389 type=refreshAndPersist interval=00:00:05:00 retry="15 +" searchbase="dc=example,dc=com" binddn="cn=manager,dc=example,dc=com" credentials="example_pass" starttls=no schemachecking=off syncrepl rid=003 provider=ldap://host4:1389 type=refreshAndPersist interval=00:00:05:00 retry="15 +" searchbase="dc=example,dc=com" binddn="cn=manager,dc=example,dc=com" credentials="example_pass" starttls=no schemachecking=off HOST3 slapd.conf: include /tmp/openldap/multi-master/etc/schema/core.schema include /tmp/openldap/multi-master/etc/schema/cosine.schema include /tmp/openldap/multi-master/etc/schema/nis.schema argsfile /tmp/openldap/multi-master/var/run/slapd.args pidfile /tmp/openldap/multi-master/var/run/slapd.pid threads 16 idletimeout 0 writetimeout 5 reverse-lookup off timelimit time.soft=30 time.hard=300 sizelimit size.soft=500 size.hard=1000 password-hash {SSHA} loglevel stats sync serverid 003 modulepath /tmp/openldap/multi-master/libexec moduleload back_monitor.la moduleload back_hdb.la moduleload syncprov.la database config rootdn cn=manager,cn=config rootpw {SSHA}yMFj3Y7KPh223NkkKLQsFeLUVm08Ckpm database monitor rootdn cn=manager,cn=monitor rootpw {SSHA}vPVSN8o8eRnLdC/bGS7yDwQGeH4BHc0R database hdb suffix dc=example,dc=com rootdn cn=manager,dc=example,dc=com rootpw {SSHA}0obbsJw5Yq2XAkdd/kS7vokaB9rrSOtI directory /tmp/openldap/multi-master/var/data/dc=example,dc=com cachesize 30000 cachefree 5 checkpoint 128 15 dncachesize 25000 idlcachesize 100000 index objectClass eq index entryCSN eq index entryUUID eq syncrepl rid=001 provider=ldap://host1:1389 type=refreshAndPersist interval=00:00:05:00 retry="15 +" searchbase="dc=example,dc=com" binddn="cn=manager,dc=example,dc=com" credentials="example_pass" starttls=no schemachecking=off syncrepl rid=002 provider=ldap://host2:1389 type=refreshAndPersist interval=00:00:05:00 retry="15 +" searchbase="dc=example,dc=com" binddn="cn=manager,dc=example,dc=com" credentials="example_pass" starttls=no schemachecking=off syncrepl rid=003 provider=ldap://host4:1389 type=refreshAndPersist interval=00:00:05:00 retry="15 +" searchbase="dc=example,dc=com" binddn="cn=manager,dc=example,dc=com" credentials="example_pass" starttls=no schemachecking=off HOST4 slapd.conf: include /tmp/openldap/multi-master/etc/schema/core.schema include /tmp/openldap/multi-master/etc/schema/cosine.schema include /tmp/openldap/multi-master/etc/schema/nis.schema argsfile /tmp/openldap/multi-master/var/run/slapd.args pidfile /tmp/openldap/multi-master/var/run/slapd.pid threads 16 idletimeout 0 writetimeout 5 reverse-lookup off timelimit time.soft=30 time.hard=300 sizelimit size.soft=500 size.hard=1000 password-hash {SSHA} loglevel stats sync serverid 004 modulepath /tmp/openldap/multi-master/libexec moduleload back_monitor.la moduleload back_hdb.la moduleload syncprov.la database config rootdn cn=manager,cn=config rootpw {SSHA}yMFj3Y7KPh223NkkKLQsFeLUVm08Ckpm database monitor rootdn cn=manager,cn=monitor rootpw {SSHA}vPVSN8o8eRnLdC/bGS7yDwQGeH4BHc0R database hdb suffix dc=example,dc=com rootdn cn=manager,dc=example,dc=com rootpw {SSHA}0obbsJw5Yq2XAkdd/kS7vokaB9rrSOtI directory /tmp/openldap/multi-master/var/data/dc=example,dc=com cachesize 30000 cachefree 5 checkpoint 128 15 dncachesize 25000 idlcachesize 100000 index objectClass eq index entryCSN eq index entryUUID eq syncrepl rid=001 provider=ldap://host1:1389 type=refreshAndPersist interval=00:00:05:00 retry="15 +" searchbase="dc=example,dc=com" binddn="cn=manager,dc=example,dc=com" credentials="example_pass" starttls=no schemachecking=off syncrepl rid=002 provider=ldap://host2:1389 type=refreshAndPersist interval=00:00:05:00 retry="15 +" searchbase="dc=example,dc=com" binddn="cn=manager,dc=example,dc=com" credentials="example_pass" starttls=no schemachecking=off syncrepl rid=003 provider=ldap://host3:1389 type=refreshAndPersist interval=00:00:05:00 retry="15 +" searchbase="dc=example,dc=com" binddn="cn=manager,dc=example,dc=com" credentials="example_pass" starttls=no schemachecking=off Thank you.

3 5

[GnuTLS][TLS init def ctx failed: -1]
by Warren Howard 02 Apr '11

02 Apr '11

Hi there, I'm using: slapd -V @(#) $OpenLDAP: slapd 2.4.21 (Mar 30 2011 18:32:32) $ buildd@rothera:/build/buildd/openldap-2.4.21/debian/build/servers/slapd cat /etc/issue Ubuntu 10.04.2 LTS \n \l This is Ubuntu so openldap has been compiled with GnuTLS ldd /usr/sbin/slapd . . . libgnutls.so.26 => /usr/lib/libgnutls.so.26 (0xb73a9000) . . . I've been following this guide https://help.ubuntu.com/10.04/serverguide/C/openldap-server.html and the section on TLS works perfectly if I follow the instructions to the letter. That is, so long as the locations of olcTLSCACertificateFile, olcTLSCertificate and olcTLSCertificateKeyFile are /etc/ssl/certs, /etc/ssl/certs and /etc/ssl/private respectively, then slapd will start. For example: olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem olcTLSCertificateFile: /etc/ssl/certs/ldap01_slapd_cert.pem olcTLSCertificateKeyFile: /etc/ssl/private/ldap01_slapd_key.pem However, if I change the location of any of these files slapd will fail to start with the error "TLS init def ctx failed: -1". Should anyone ask, yes I've doubled checked for correct file permissions and searched for typos. The names of the files does not matter, just their location. These appears to be bug to me. Regards, Warren.

2 2

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical April 2011