openldap-technical

openldap-technical@openldap.org

7 participants
9864 discussions

Weird DNS round-robin issue
by Dennis Leeuw 18 May '14

18 May '14

-----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.

4 9

Re: Need Schema for aci attribute
by neel 17 May '14

17 May '14

> neel wrote: > > I am using HPCC and I am integrating it with openldap. In that when I > start > > one component I.e. mydali server. It throws this error. > > I don't know HPCC. Is it this one? > > https://track.hpccsystems.com/browse/HPCC-7999 > > Ciao, Michael. > > Yep, you are correct. Regards Neelesh

1 0

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?
by Turbo Fredriksson 16 May '14

16 May '14

[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%2… > > 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

17 92

regarding logging when running in the foreground
by Mike Jackson 16 May '14

16 May '14

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

4 6

Search issue (objectclass=person) (Possible dupe email)
by Tuc 16 May '14

16 May '14

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

5 17

ldapadd errors
by Brendan Kearney 16 May '14

16 May '14

[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

4 3

replica of schema info
by Francesco Malvezzi 16 May '14

16 May '14

good morning, I would like to be able to replicate the schema info only from cn=config. I tried to add the olcSyncrepl to cn=schema dn: cn=schema,cn=config changetype: modify add: olcSyncrepl olcSyncrepl: .... but doesn't work: <olcSyncrepl> only allowed within database declaration I tried to push a whole new olcDatabase={0}config (next step would be to add glue overlay to olcDatabase={1}config,cn=config) dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by * break olcAccess: {1}to dn.base="cn=config" by * none olcSuffix: cn=schema,cn=config olcRootDN: cn=admin,cn=schema,cn=config olcRootPW:: e1NTSEF9bnNNYkxIMFhFTm0zaXA5N0JXaHRVb3RwTlRsRXRxNTA= olcMonitoring: FALSE olcSyncrepl: .... but it doesn't work: olcSuffix: value #0: suffix <cn=schema,cn=config> not allowed in config database. It does work to add olcSyncrepl to olcDatabase={0}config,cn=config with a filter like: olcSyncrepl: {0}rid=001 provider=... binddn=... bindmethod=simple search base="cn=schema,cn=config" filter="(!(cn=core))" but then the whole olcDatabase={0}config,cn=config becomes a shadow context and I'm unable to ldapmodify anything (olcLoglevel for example). What am I missing? thank you for reading me, Francesco

2 5

Need Schema for aci attribute
by neel 16 May '14

16 May '14

Hi, I have compiled and configured OpenLDAP 2.4.39 with ACI. I am trying to integrate one application with LDAP. I have entered all settings. Authentication is working fine. Only thing when it tries to add some entries to ldap, it says that "err=17 text=aci: attribute type undefined" Can you please provide schema for aci attribute? Regards Neelesh

7 20

[LMDB] Choosing right environment flags
by Alain 14 May '14

14 May '14

I need to better understand the best way to configure the various environment flags related to sync and map. When we converted from BDB to LMDB, we instinctively kept #MDB_NOSYNC true. This proved to make the database subject to corruption if it was killed or stopped too harshly. It also had the effect on Windows at least to make Windows gradually use up all available RAM for the memory mapped file and to bring the server to its knees. After carefully reading the documentation about leaving "the system with no hint for when to write transactions to disk" when MDB_NOSYNC was turned on, we completely went without setting any options. The results were that we can't corrupt the database, but the speed degradation makes this approach unusable, as we are very heavily write focused (at least in this part of our process, where we perform analysis and load the database with 100's millions of records). In looking at the documentation I'm tempted to try MDB_WRITEMAP with MDB_MAPASYNC but do I then need to also issue some manual mdb_env_sync and if so at what frequency and what should trigger this? What are best practices combinations of those flags here. We absolutely can't afford database corruption, but we can deal with one (or maybe more with some re-design) transactions that are lost. Please guide us. Thanks Alain

2 1

password policy module memory leaks / excessive replication?
by Paul B. Henson 14 May '14

14 May '14

I've been testing the password policy module lately. I updated our development LDAP infrastructure Monday, basically loading and enabling the module, adding a default policy: dn: cn=default,ou=ppolicy,dc=csupomona,dc=edu cn: default objectClass: organizationalRole objectClass: pwdPolicy pwdAttribute: userPassword pwdLockout: TRUE pwdLockoutDuration: 1800 pwdMaxFailure: 100 pwdFailureCountInterval: 300 And a policy specific for service accounts: dn: cn=serviceaccount,ou=ppolicy,dc=csupomona,dc=edu cn: serviceaccount objectClass: organizationalRole objectClass: pwdPolicy pwdAttribute: userPassword After some initial testing and determining that the current implementation is not suitable for account lockouts, I haven't touched it since Monday. Yesterday, I started getting alerts that the systems were low on memory, and upon looking, found extremely bloated slapd processes. Next, I started getting alerts that the accesslog mdb was running out of space. Upon investigation, I found that the service account that is used to gather statistics was generating a considerable amount of churn every time it authenticated (every 30 seconds). This account was explicitly configured to use the service account password policy: dn: cn=slapd-monitor,ou=user,ou=service,dc=csupomona,dc=edu objectClass: person cn: slapd-monitor sn: LDAP monitoring account pwdPolicySubentry: cn=serviceaccount,ou=ppolicy,dc=csupomona,dc=edu Which should be pretty much "do nothing". (I realize now that this policy will actually result in pwdFailureTime entries being created for failed authentications, and accumulating forever until a successful authentication, but there are no failed authentications for this service account, only successful ones, in this case). There were 1662836 entries in the access log for this dn since Monday that as far as I can tell solely change the CSN: dn: reqStart=20140502031556.000000Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20140502031556.000000Z reqEnd: 20140502031558.000000Z reqType: modify reqSession: 2 reqAuthzID: cn=ldaproot,dc=csupomona,dc=edu reqDN: cn=slapd-monitor,ou=user,ou=service,dc=csupomona,dc=edu reqResult: 0 reqMod: entryCSN:= 20140501211559.348458Z#000000#003#000000 reqMod: modifiersName:= cn=ldaproot,dc=csupomona,dc=edu reqMod: modifyTimestamp:= 20140501211559Z reqEntryUUID: c16729b0-ce1e-4f9d-9123-e0b8f115133c entryUUID: 240ec245-0bac-4e20-b387-19243f720674 creatorsName: cn=accesslog createTimestamp: 20140501211559Z entryCSN: 20140501211559.348458Z#000000#003#000000 modifiersName: cn=accesslog modifyTimestamp: 20140501211559Z This explains why the accesslog was running out of space, it was full of these. It doesn't explain why the slapd process exploded in memory use, unless I suppose the steady-state memory usage of a slapd this busy processing replication is higher than one that's not quite so busy. But I'm confused as to why loading the password policy module, for an account with a policy configured to pretty much not do anything, results in a modification of the CSN for every authentication? I'm going to go peruse the source code to see if I can determine what's going on, but any expert opinions would be most welcome. Thanks much.

3 21

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical