openldap-technical November 2018

openldap-technical@openldap.org

24 participants
24 discussions

ldapmodify add olcSyncrepl (okey but not okey)
by lejeczek 19 Nov '18

19 Nov '18

hi everyone I'm must be doing something trivially wrong and am hoping someone could help. I'm trying to add second replica: $ ldapmodify -vv -h rider.my.dom:1389 -D "cn=admin,cn=config" -w my.Biotec13 -x ldap_initialize( ldap://rider.my.dom:1389 ) dn: olcDatabase={1}bdb,cn=config changetype: modify add: olcSyncrepl: rid=002 provider=ldap://swir.my.dom:1389 bindmethod=simple timeout=0 network-timeout=0 binddn="uid=replicator,ou=people,dc=my,dc=dom" credentials="lejek9090" keepalive=0:0:0 starttls=no filter="(objectclass=*)" searchbase="dc=my,dc=dom" scope=sub attrs="*,+" schemachecking=off type=refreshOnly interval=00:00:10:00 retry="5 5 300 +" exit code of the above to shell is 0 yet next ldapsearch finds no such new entry exists. At the time of ldapmodify in logs I see: Nov 19 14:40:48 rider slapd[90048]: slap_queue_csn: queueing 0x7f22cc111e00 20181119144048.167126Z#000000#005#000000 Nov 19 14:40:48 rider slapd[90048]: slap_graduate_commit_csn: removing 0x7f22cc111e00 20181119144048.167126Z#000000#005#000000 How to get it work? Many thanks, L.

4 3

Re: syncrepl schema error
by aRaviNd 19 Nov '18

19 Nov '18

HI Quanah, Yes, there was duplicate values in DIT which was causing slaves to not sync the data. Thanks for your guidance Regards, Aravind M D On Sun, Nov 18, 2018 at 3:35 AM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Saturday, November 17, 2018 9:38 PM +0530 aRaviNd > <ambadiaravind(a)gmail.com> wrote: > > > If remove the schema changes replication works fine. Could you please let > > us know whats going wrong with the configuration? > > Most likely, you have two values in the attribute that are different when > case sensitive, but the same when case insensitive, i.e.: > > memberUID: AbcD > memberUID: aBCd > > Before your schema change, these are considered different. AAfter your > schema change, they are the same. So when a modification occurs to the > attribute they are now seen as duplicate values and it breaks replication. > > --Quanah > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

delete a user schema from cn=config
by Derek Zhou 19 Nov '18

19 Nov '18

Hi list, I was experimenting locally written schema with a recent build of slapd. I added the schema ldif with no problem using ldapadd -QY EXTERNAL -H ldapi:/// ... But then I realized I made a mistake, so I try to delete it with ldapdelete -QY EXTERNAL -H ldapi:/// it says: ldap_delete: Server is unwilling to perform (53) what does it mean? The schema is not used by any data on the server. I can use slapmodify to remove it after server shutdown, but that kind of suck and not much different, or even worse than editing conf file? Derek

4 8

syncrepl schema error
by aRaviNd 17 Nov '18

17 Nov '18

Hi Team, We have configured master slave openldap replication in our environment. Default NIS schema was modified for the attribute memberUid to be case insensitive. During replication after some of the records are transferred we are seeing below error. Nov 17 08:06:57 abc.com slapd[2356]: syncrepl_message_to_entry: rid=003 mods check (memberUid: value #30 provided more than once) Nov 17 08:06:57 abc.com slapd[2356]: do_syncrepl: rid=003 rc 20 retrying If remove the schema changes replication works fine. Could you please let us know whats going wrong with the configuration? Thanks in advace Regards, Aravind M D

2 1

cn=config default access control
by Derek Zhou 16 Nov '18

16 Nov '18

Hi list, I've been using openldap for a few years but yesterday I compiled slapd from git head for the first time. To my supprise that: root@my-machine:/root#: ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=config does not work. It took me a while to find out that by default the cn=config database has 'olcAccess: {0}to * by * none' and 'olcRootDN: cn=config' with no olcRootPW, so all access from ldap is denied. Once I know I used slapmodify to change olcRootDN to 'gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth' and everything works as expected afterward. My argument is why isn't it the default? I think debian packages already did that. cn=config is stored as plain text on the local file system so local root can read and change anyway. Changing cn=config is the first thing to do for any admin, and I am not exactly a newbie yet I still stumbled on it. By the way, if we really want people to use cn=config exclusively, I suggest to remove all mentioning of slapd.conf from the latest documentation. Old admins appreciate cn=config more and there will be less distraction for newbies. Derek

2 3

OpenLDAP thread-safety nowadays
by openldap-technical＠kolttonen.fi 15 Nov '18

15 Nov '18

Hello, I am new to OpenLDAP and I was wondering whether the OpenLDAP client C API is thread-safe. I found this old thread: https://www.openldap.org/lists/openldap-software/200606/msg00252.html Does anyone know whether there is still a need for separate libldap_r or is the default library okay as it is? Thanks for the information. Best regards, Unto Sten

2 1

Using unique overlay per OU
by Ervin Hegedüs 14 Nov '18

14 Nov '18

Hi, here is an OpenLDAP cluster, with few DC's, eg: dc=service1,dc=company1,dc=hu and dc=company2,dc=hu. All DC's containts few ten of OU, where few ten of user. Now the uniq overlay is set for some attributes, eg. "mail", which means an e-mail address can occures only once in all DB. (The help came on this list: http://www.openldap.org/lists/openldap-technical/201808/msg00016.html) Now, is there any way that I can use the unique rule for every OU, but not for all. I mean an e-mail address can be used under several OU, but only once per OU. Thanks, a.

2 1

Re: Resizing of LMDB map
by Daniel Kraft 13 Nov '18

13 Nov '18

On 2018-11-13 09:59, hyc(a)highlandsun.com wrote: > On Tue, Nov 13, 2018 at 07:09:08AM +0000, Daniel Kraft wrote: >> On 2018-11-12 21:21, Howard Chu wrote: >> Ah ok, so mdb_txn_commit also frees the transaction if it then actually >> fails with MDB_MAP_FULL -- I was missing that. By avoiding the >> mdb_txn_abort in that case, my example code indeed works now! >> >> So is it correct to assume that the transaction is "effectively aborted" >> after mdb_txn_commit fails with MDB_MAP_FULL (or, for that matter, any >> error)? > > http://www.lmdb.tech/doc/group__mdb.html#ga846fbd6f46105617ac9f4d76476f6597 > > The doc is quite clear. After you call commit the txn is freed. Yes, that part is clear (I just missed it before). But the doc doesn't say anything about what happens to the transaction data in case of an error. I think it is quite reasonable to assume that the transaction is fully aborted (as if mdb_txn_abort was called instead of mdb_txn_commit) in case of an error (since otherwise transaction atomicity would be violated), but I just wanted to check this is indeed what happens. Yours, Daniel -- https://www.domob.eu/ OpenPGP: 1142 850E 6DFF 65BA 63D6 88A8 B249 2AC4 A733 0737 Namecoin: id/domob -> https://nameid.org/?name=domob -- 3.6.0: Bar-Pri-Ran-Rog-Sam-Val-Wiz To go: Arc-Cav-Hea-Kni-Mon-Tou

2 1

Why built-in schemas are a bad idea
by Ulrich Windl 13 Nov '18

13 Nov '18

Hi! I had reported about trouble when upgrading the openldap from SLES11 SP4 to that from SLES12 SP3. Besides the version jump, SUSE also removed some modules that had been static in SLES11, so that they need to be loaded dynamically now. Besides that, the bdb version was updated as well, and some other minor things. The real problem is that I'll need to change cn=config to include the modules, one of them being accesslog. The main problem there seems to be that the accesslog module provides the accesslog schema also, meaning the schema is unknown until the module is loaded. Now no configuration change is accepted, because there are attributes in the config database without a schema: # slapadd -q -n0 -F /etc/openldap/slapd.d/ -l module.ldif 5be00c86 <= str2entry: str2ad(olcAccessLogDB): attribute type undefined slapadd: bad configuration directory I once did edit the config-db files directly and managed to get slapd running (and bdb auto-upgraded itself), but I'm looking for a clean solution. The other things I've noticed was that the old SLES11 openldap would not accept a module load directive when the module is not found (mdb in particular); loading modules that are statically included is no problem, however. This makes a replicated cn=config very difficult for a rolling upgrade of MMR servers. Any splendid idea how to add the accesslog module to a cn=config that already has accesslog configured for ist databases? Even temporarily removing the conflicting attributes does not work. Regards, Ulrich

3 13

openldap proxy giving TLS certificate error
by vadud3＠gmail.com 13 Nov '18

13 Nov '18

I am failing to authenticate through ldap proxy and I am seeing this error coming in continuously *TLS certificate verification: Error, self signed certificate in certificate chain* *TLS: can't connect: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (self signed certificate in certificate chain).* Any suggestions how to resolve this? Here is my slapd.conf. ### Schema includes > ########################################################## > include /etc/openldap/schema/core.schema > include /etc/openldap/schema/cosine.schema > include /etc/openldap/schema/inetorgperson.schema > include /etc/openldap/schema/misc.schema > include /etc/openldap/schema/nis.schema > ## Module paths > ############################################################## > modulepath /usr/lib64/openldap/ > moduleload back_ldap > # Main settings > ############################################################### > pidfile /var/run/openldap/slapd.pid > argsfile /var/run/openldap/slapd.args > sizelimit unlimited > TLSCACertificateFile /root/data/certs/ldap.crt > TLSCertificateFile /root/data/certs/ldap.crt > TLSCertificateKeyFile /root/data/certs/ldap.key > ### Database definition (Proxy to Corp LDAP) > ######################################### > database ldap > readonly yes > protocol-version 3 > rebind-as-user yes > uri "ldaps://192.168.1.100:636" > suffix "ou=People,dc=example,dc=net" > ### Logging > ################################################################### > loglevel 0 > It had been working until last week when IT changed there ldap certificate I generate the certificate using this command *openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout /root/data/certs/ldap.key -out /root/data/certs/ldap.crt -subj "/CN=host.example.net/OU=Example/O=Example/L=City/ST=ST/C=US <http://host.example.net/OU=Example/O=Example/L=City/ST=ST/C=US>"* So I recreated against the same IT ldap server, so I do have the new cert and keys produced same way as before. All new authentication are failing now. -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical November 2018