openldap-technical

openldap-technical@openldap.org

9 participants
9867 discussions

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 17 Nov '18

17 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

Resizing of LMDB map
by Daniel Kraft 13 Nov '18

13 Nov '18

Hi! I'm trying to use LMDB in a way that automatically resizes the map whenever it becomes too small, i.e. a function fails with MDB_MAP_FULL. I've created and attached a program that resembles my real usecase in a very simplified fashion: It just writes data to the database, and tries to double the map size whenever MDB_MAP_FULL is received. However, for me this program (as well as my real code) produces a segfault in the mdb_put call that follows after the first resize. What am I doing wrong here, and how can I correctly implement a resize when full? According to the docs [1], it is ok to call mdb_env_set_mapsize for an open environment as long as no transactions are active. My code ensures this by aborting the current transaction before resizing the map. Also, there seems to be other code out there [2] that does the resize in a way that looks like what I'm trying to do, and presumably works fine. [1] http://www.lmdb.tech/doc/group__mdb.html#gaa2506ec8dab3d969b0e609cd82e619e5 [2] https://github.com/BVLC/caffe/pull/3731 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 -- 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 2

Re: Why built-in schemas are a bad idea
by Michael Ströder 12 Nov '18

12 Nov '18

On 11/12/18 11:27 AM, Ulrich Windl wrote: > So far nobody did comment of what I think is the real issue: I did. But obviously you did not like my answer. Ciao, Michael.

1 0

syncrepl with exattrs
by Frank Swasey 08 Nov '18

08 Nov '18

I am attempting to set up a replication using delta-syncrepl that will ignore four objectClasses. I am able to prevent the attributes of those objectClasses from being sent, by using @objectClassName in the exattrs value of the statement. However, I also have to set schemachecking off because the objectClass: objectClassName value is still coming over. I was not able to find any examples of using the exattrs option in the tests/data directory. And, I have failed to find anything relevant from google. Is there a way to prevent the four possible objectClass values that I don't want to see from being sent so I can leave schemachecking turned on? Thanks, - Frank

3 9

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical