Custom ldapSyntax
by Peter Schütt
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
11 years, 1 month
update referral per rid
by Hendrik van der Ploeg
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
11 years, 1 month
Re: Antwort: Re: RHEL 6 OpenLDAP 2.4.19-15.el6 init problem
by Quanah Gibson-Mount
--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
11 years, 1 month
Re: 8 principal limitation in openldap
by Srivatsav M
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
>>>>
>>>
>>>
>>
>
11 years, 1 month
"ldap_sasl_bind_s failed (-1)" makes me in trouble... [episode 2]
by Olivier Pavilla
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
11 years, 1 month
could not work in C++?
by owen nirvana
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
11 years, 1 month
"ldap_sasl_bind_s failed (-1)" makes me in trouble...
by Olivier Pavilla
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 -
11 years, 1 month
Problems with 4-way multi-master
by Mark
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.
11 years, 1 month
[GnuTLS][TLS init def ctx failed: -1]
by Warren Howard
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.
11 years, 1 month
