slapcat -c problem
by David Spurek
Hi,
slapcat -c doesn't work as I expect in one case. It should ignore errors.
I have following slapd.conf with 2 suffixies, only the second one (dc=my-domain,dc=com) is filled with data:
cat slapd.conf
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
allow bind_v2
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
database bdb
suffix dc=example,dc=com
rootdn "cn=Manager,dc=example,dc=com"
rootpw x
directory /var/lib/ldap/
database bdb
suffix dc=my-domain,dc=com
rootdn "cn=Manager,dc=my-domain,dc=com"
rootpw x
directory /tmp/tmp.lfFaOlWyes/ldap-test-ldap2
[test]slapcat
537223f1 bdb_db_open: warning - no DB_CONFIG file found in directory /var/lib/ldap/: (2).
Expect poor performance for suffix "dc=example,dc=com".
537223f1 bdb_db_open: database "dc=example,dc=com": db_open(/var/lib/ldap//id2entry.bdb) failed: No such file or directory (2).
537223f1 backend_startup_one (type=bdb, suffix="dc=example,dc=com"): bi_db_open failed! (2)
slap_startup failed
'slapcat -c' gives me the same output. I expect that it will ignore errors with the first database and dumps the database for second suffix.
Should slapcat -c skip error in this case?
Tested with openldap-2.4.39
--
David Spurek
9 years, 6 months
Multiple ou entries are added
by David Spurek
Hi,
If I add following ldif with slapadd(attribute 'ou' and 'ou' in dn: are different):
dn: ou=testou.auto,dc=my-domain,dc=com
ou: testou.misc
objectClass: top
objectClass: organizationalUnit
Slapadd doesn't evalute it as an error in ldif but it adds 'ou' from dn as another attribute.
Added entry then looks like:
# testou.auto, my-domain.com
dn: ou=testou.auto,dc=my-domain,dc=com
ou: testou.misc
ou: testou.auto
objectClass: top
objectClass: organizationalUnit
Is this expected behavior or a bug?
Tested with openldap-2.4.39
--
David Spurek
9 years, 6 months
Encryption storage mechanism SHA256 in OpenLDAP
by bris chik
Hi All
We are using OpenLDAP 2.4.38 windows version as user store for our
application. I need to configure encryption storage mechanish as SHA256 in
openLDAP.
I tried with changing
#password-hash {CLEARTEXT}
password-hash {SHA256}
But it is not working. I mean after making this change password got saved
in OpenLDAP as SHA256 but after that when I am authenticating using pwd
through JNDI it cannot match with the stored one and it says incorrect
credentials.
FYI - I am just taking the plain text pwd as user is providing in login
page and passing to openLDAP. My understanding is OpenLDAP will take the
plaintext pwd and encrypt it to SHA256 and compare with its store. Please
let me know if my understanding is wrong or anything extra I have to do
here.
I got one link for doing this in linux version but didn't get anything for
windows version.
http://www.openldap.org/devel//cvsweb.cgi/~checkout~/contrib/slapd-module...<http://www.openldap.org/devel/cvsweb.cgi/~checkout~/contrib/slapd-modules...>
Can anyone please help me on this?
9 years, 6 months
Weird DNS round-robin issue
by Dennis Leeuw
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
I hope I am on the right list for the problem I am experiencing.
We have two subnets
192.168.196.
192.168.222.
Our main LDAP servers run in 192.168.196. and are load-balanced by
round-robin DNS.
The 192.168.196. network is exhausted, so we added a new LDAP slave to
192.168.222. and added the IP address to the round-robin pool.
But it seems that it is only used by other servers in the 192.168.222
network and not by servers in the 192.168.196. network
This setup has now been running for 6 days, with nscd.conf:
enable-cache hosts yes
positive-time-to-live hosts 3600
negative-time-to-live hosts 20
suggested-size hosts 211
check-files hosts yes
persistent hosts yes
shared hosts yes
max-db-size hosts 33554432
and nslcd.conf:
uid nslcd
gid ldap
uri ldap://ldap.div.ourdomain.nl/
base dc=div,dc=ourdomain,dc=nl
ssl no
tls_cacertdir /etc/openldap/cacerts
The LDAP server in the 192.168.222 range serves only 33 connections
all from the 192.168.222 range, and the 2 hosts in the 192.168.196
range serve 599 and 706 connections. The last 2 servers do serve the
143.121.222. network also. So might there be some caching issue?
$ getent ahost ldap.div.ourdomain.nl
192.168.196.190 STREAM ldap.div.ourdomain.nl
192.168.196.190 DGRAM
192.168.196.190 RAW
192.168.196.151 STREAM
192.168.196.151 DGRAM
192.168.196.151 RAW
192.168.222.179 STREAM
192.168.222.179 DGRAM
192.168.222.179 RAW
Is this the right list for this question? And if so can someone help
me understand what is going on?
With kind regards,
Dennis Leeuw
- --
ICT Medewerker
Divisie Biomedische Genetica
UMC Utrecht
Heidelberglaan 100 STR2.126
3584 CX Utrecht
The Netherlands
06 27744048
intern: 64048
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTAyjwAAoJEMVYYpdbQscouGsH/3yXjh6zmLMDRaks18qe+yH7
oUrdatkENF7+WyxLz7ZzNL69gXyEwTANGGf9y7CYuqNu47PDs3SvNOM1/kgjy7pr
CSN1t9acVb9i67JgOV2ed5fMHlOzOR+sevNKjsdEdKVXrYvcXnevLOD0KHhGlXeq
Ips0Uqk8cusDXQZSUPab0aQNhWawyT1Tf4SQVAJbJ3OYEiFpHyPJXos2F4DIpYPJ
9FLn/dqV8sUNc9kaOHRjwcVYYAVyey9vX33xbYKr4pXKLd/ujaArBtwE1tyKvR2G
JPz6Gw5sYK5JLjkmr1uzPAze46heiVFY6U1Vv7aMJ4ujuabBiU11Us2k4XuotPI=
=UxBr
-----END PGP SIGNATURE-----
------------------------------------------------------------------------------
De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is
uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht
ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender direct
te informeren door het bericht te retourneren. Het Universitair Medisch
Centrum Utrecht is een publiekrechtelijke rechtspersoon in de zin van de W.H.W.
(Wet Hoger Onderwijs en Wetenschappelijk Onderzoek) en staat geregistreerd bij
de Kamer van Koophandel voor Midden-Nederland onder nr. 30244197.
Denk s.v.p aan het milieu voor u deze e-mail afdrukt.
------------------------------------------------------------------------------
This message may contain confidential information and is intended exclusively
for the addressee. If you receive this message unintentionally, please do not
use the contents but notify the sender immediately by return e-mail. University
Medical Center Utrecht is a legal person by public law and is registered at
the Chamber of Commerce for Midden-Nederland under no. 30244197.
Please consider the environment before printing this e-mail.
9 years, 6 months
Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?
by Turbo Fredriksson
[Sorry Howard for sending it to you personally. It was meant for the list.
I sent a copy to the list as well. I hope you don't mind if I send this reply
to the list. I've included every word, so not to take something out of
context.]
On Jan 30, 2014, at 6:17 PM, Howard Chu wrote:
>> Personally, I think it's spot on. It IS hard to configure an LDAP server, and
>> even harder to understand how it works (the object based part). Took me three
>> months first time, and I'm not an idiot.
>
> The object based part is *LDAP*, so that complaint is not specific to OpenLDAP.
Indeed.
But setting up something like Active Directory is something my aunt can/could
do. It probably won't scale to thousands (or maybe not even hundreds :) of
users, but it can be done with reasonable ease.
> The part about RedHat seems fairly accurate to me, it *is* true that they have their own commercial LDAP server to sell, and they have no great interest in OpenLDAP working well on their platforms.
>
>> Even today, I need to consult either my own book or the howto (or seriously
>> skim through the man pages) to setup a new server.
>
> And I still need to read the docs when configuring an Apache HTTP server. That's why we have manpages, there's nothing wrong about that.
Same here. Not my point (see the part at the bottom)...
>> And even worse if when you want to optimize the backend... There's a lot of
>> magic there....
>
> The LMDB backend has no tuning/optimization. That's one of the reasons it exists today.
Yeah, but isn't it quite slow with lmdb? I haven't tested that in years, so
I don't know. One wouldn't run it in production though?
>> And with the new config backend!? I haven't even had the time or energy to go
>> that far yet!
>>
> I think you (and everyone else) are blowing this way out of proportion. Compare the example from here
I know how it works and I don't really have that much problem with it, it's just
so much more difficult to setup (initially) and then maintain than a simple
text file.
It's way better, but it IS also more complicated (than just fire up an editor,
modify the part you want and then issue a service restart - can't be much
simpler than that)...
> http://www.openldap.org/doc/admin24/slapdconf2.html#Configuration%20Example
>
> to the slapd.conf example
>
> http://www.openldap.org/doc/admin24/slapdconfig.html#Configuration%20File...
>
> They aren't that different, and anyone familiar with slapd.conf and LDIF files should have no trouble mapping concepts from one to the other.
>
> And if you aren't familiar with slapd.conf *and* LDIF then you don't know enough to be an LDAP administrator in the first place, you need to do more homework. That's just life.
I couldn't agree more! I've taken over more than my fair share of badly setup
and maintained OpenLDAP servers to get really pissed at all the ones not having
a clue what they're doing.
It's not just making a config file/backend to allow the server to start, it's
more planning on how the database should look like (where to put what and
what object classes to use and allow), setting up access control etc, etc. The
actually planing of the database (the content) is the most important part, and
it require quite a lot of reading and testing before it's understood properly to
be able to be used to any extent.
But then there's the integration to the rest of the system (pam login and what
not), Kerberos, SASL, etc, etc...
My point wasn't to argue about the validity of how the OpenLDAP server and it's
config file/backend work etc. I fully agree and have no problems with it.
My point was that the website isn't WRONG - it IS hard! Maybe it SHOULD be hard?
The whole concept of an LDAP server is a difficult subject, and shouldn't be
taken lightly.
Unfortunately, it seems that way to many beginners that have been installing
a distribution at home is starting to work as a Linux tech/admin thinking that
just because the've run it at their workstation at home for a couple of months
makes them good enough to work in a professional environment.
I see that in a lot of OpenSource project I'm part of. Complete noobs want to
use something complicated that require quite a lot of homework. And then comes
complaining when things go south! Or even worse, they bad mouth the project or
the technology!
(Open)LDAP is one of those many things that require a lot more from the admin
than say ... installing a mail server locally...
On Debian GNU/Linux that's practically automatic. Just answer a couple of
questions, and it works...
It's sad that the website in question (and from what one could take from this -
that people 'out there') actually thinks that this should be easy. But it's not
(technically) wrong...
--
There are no dumb questions,
unless a customer is asking them.
- Unknown
9 years, 6 months
regarding logging when running in the foreground
by Mike Jackson
Hi,
Is there a way to prevent slapd from using syslog when running in the
foreground? I run slapd permanently under the runit process
supervision package with -d 256, and it already captures stderr to
it's own logging system. However, I also get the same log messages
cluttering up my syslog with local4.debug lines. Running in the
foreground is pretty much a requirement for using process supervision
and almost every service related software supports it for this reason.
The background logging, despite running in the foreground, is
undesired behavior.
-mike
9 years, 6 months
Search issue (objectclass=person) (Possible dupe email)
by Tuc
Hi,
We're having an issue with a slightly older version of openldap.
(2.4.23-26 on CentOS). Using Apache Directory Studio I do a search:
"(objectclass=person)" on a search base of
"ou=People,dc=example,dc=com"
This should be the easiest and simplest search in the world. However, I
get entries like :
dn: uid=PLACEHOLDER_example_agent,ou=People,dc=example,dc=com
objectClass: top
objectClass: posixAccount
objectClass: inetOrgPerson
cn: PLACEHOLDER_example agent
gidNumber: 100
homeDirectory: /home/example_agent
sn: agent
uid: PLACEHOLDER_example_agent
uidNumber: 621
givenName: example
loginShell: /bin/bash
userPassword:: DELETED
and
dn: uid=BDTestUser,ou=People,dc=example,dc=com
objectClass: top
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: BD
sn: User
displayName: BD User
givenName: BD
mail: seo(a)example.com
mobile: +1 1111111111
ou: Sales
telephoneNumber: +1 222222222
title: BD Sample User
uid: BDTestUser
userPassword:: DELETED
Where am I going wrong?
Tuc
9 years, 6 months
ldapadd errors
by Brendan Kearney
[root@test mdb]# slapd -V
@(#) $OpenLDAP: slapd 2.4.39 (Feb 4 2014 09:07:17) $
mockbuild@buildvm-25.phx2.fedoraproject.org:/builddir/build/BUILD/openldap-2.4.39/openldap-2.4.39/servers/slapd
i am trying to add ipNetwork entries to my tree, and at first i was
getting "index generation failed" errors after several thousand entries
were added. i removed the indexing of the cn attribute and restarted
slapd and reran the loading of the entries. the existing objects were
moved past, and some new objects were added. then some new errors came
out.
adding new entry "cn=64.89.32.0,c=US,ou=GeoLocation,dc=bpk2,dc=com"
ldap_add: Other (e.g., implementation specific) error (80)
additional info: entry store failed
i am using lmdb. i have checked filesystem space, and that is not an
issue. the data.mdb is about 10 MB in size.
the job i am running is an ldapadd, using the rootdn ID. this is only
because it is going against a test instance. the job is started with:
ldapadd -h test.bpk2.com -D cn=Manager,dc=my-domain,dc=com -W -f
geolocation.ldif -S geo_errors.out -c
the data is a parsed version of the IpToCountry.csv geolocation info.
there are 137951 unique dn's to be added (with cn, ipnetworknumber,
ipnetmasknumber, l, and 2 objectclasses per dn), and i am part way
through the list. the ldif file is about 25 MB in size. all of the
parent objects exist, as that was a previous job to add them. this is
just to create the networks below each of the parent objects.
where can i look for places to identify the issue? has anyone run into
something like this before? a quick google only shows threads for
BDB/HDB backends, but i am using LMDB.
thanks in advance,
brendan kearney
9 years, 6 months
