openldap-technical

openldap-technical@openldap.org

14 participants
9795 discussions

Unique overlay confusing
by Ervin Hegedüs 30 Aug '18

30 Aug '18

Hi there, I've followed the docs (and some forums), and made these modifications: (OpenLDAP doc: http://www.openldap.org/doc/admin24/overlays.html#Attribute%20Uniqueness) dn: cn=module,cn=config cn: module objectClass: olcModuleList olcModulePath: /usr/lib/ldap/ olcModuleLoad: unique.la dn: olcOverlay=unique,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcUniqueConfig olcOverlay: unique olcUniqueAttribute: uid olcUniqueAttribute: mail olcUniqueAttribute: uidNumber olcUniqueAttribute: sn olcUniqueAttribute: cn but I still can set the mail attribute as same e-mail address for two different users. I've tried this config too: dn: olcOverlay=unique,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcUniqueConfig olcOverlay: unique olcUniqueUri: ldap:///?uid?sub? olcUniqueUri: ldap:///?mail?sub? olcUniqueUri: ldap:///?uidNumber?sub? olcUniqueUri: ldap:///?sn?sub? olcUniqueUri: ldap:///?cn?sub? What em'I missing? Thanks, a.

5 17

Call fo Papers - Paris Open Source Summit
by Clément OUDOT 30 Aug '18

30 Aug '18

Hello, There is an important event about free software and open source in Paris in december, with topics about identity management. The CFP is here: http://cfp.opensourcesummit.paris/ It should close friday but I think the deadline will be reported. Feel free to propose technical talks or customer success stories (for example migration from proprietary softwares to free softwares). Hope to see you soon, Clément.

1 0

Recommended way to transfer data from one cluster to the other?
by Karsten Heymann 29 Aug '18

29 Aug '18

Hi, We're replacing our aging LDAP Cluster (Debian 7, slapd 2.4.40, 2 masters with syncrepl and mirror mode, 2 slaves) with a new cluster of the same layout (2.4.44, probably 2.4.46, on Debian 9). I now wonder what the best way is to transfer the data from the old to the new cluster. As far as I can see, we have three options to transfer the data: 1) ldapsearch + ldapadd 2) slapcat + slapadd 3) Configure a temporary syncrepl rule on the new masters to fetch the data from the old ones. Which one is the preferred one? I would assume slapcat and slapadd, but I must admit I have not fully understood the purpose of the -S and -w switch. Should we somehow filter the *CSN-fields from the exported ldif as I assume they make no sense for the new cluster or are they automatically fixed when using slapadd with said options? I'm sorry if this topic has been discussed here before but my (probably lacking) google skills did not return anything obvious. Best regards Karsten

3 2

Re: Recommended way to transfer data from one cluster to the other?
by Quanah Gibson-Mount 29 Aug '18

29 Aug '18

--On Wednesday, August 29, 2018 12:50 PM +0200 Karsten Heymann <karsten.heymann(a)gmail.com> wrote: > Hi Quanah, > > Am Di., 28. Aug. 2018 um 21:05 Uhr schrieb Quanah Gibson-Mount > <quanah(a)symas.com>: >> --On Tuesday, August 28, 2018 9:48 PM +0200 Karsten Heymann >> <karsten.heymann(a)gmail.com> wrote: >> >> > Which one is the preferred one? >> >> Indeed, slapcat + slapadd is the preferred route. > > Great, so I was not too far off. > >> d) slapadd this second export to the rest of the new cluster > > I gess with no extra options regarding replication this time? Correct. Can just use "-q" at this point. >> * <http://www.openldap.org/its/index.cgi/?findid=8902> > > Ok, didn't know that. > > Thanks a lot. I performed a test import following your instructions > and so far everything looks good. > Karsten Glad it's looking good. :) In the future, please keep replies on the list unless they contain some type of sensitive info (passwords, etc). ;) This helps ensure others have the possibility of making use of the information. :) Warm regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Q: Co-existence of OpenLDAP and 389 Directory Server?
by Ulrich Windl 25 Aug '18

25 Aug '18

Hi! As stated some time ago the SUSE Linux Enterprise Server 15 (SLES15) switched from OpenLDAP to 389 Directory Server. Trying the latter, I see that it still works with BDB (4.8), and setup is easy. It also seems to have modern features like these: \n+Entry cn=SSHA256,cn=Password Storage Schemes,cn=plugins,cn=config is added \n+Entry cn=SSHA384,cn=Password Storage Schemes,cn=plugins,cn=config is added \n+Entry cn=SSHA512,cn=Password Storage Schemes,cn=plugins,cn=config is added \n+Entry cn=SHA256,cn=Password Storage Schemes,cn=plugins,cn=config is added \n+Entry cn=SHA384,cn=Password Storage Schemes,cn=plugins,cn=config is added \n+Entry cn=SHA512,cn=Password Storage Schemes,cn=plugins,cn=config is added \n+Entry cn=PBKDF2_SHA256,cn=Password Storage Schemes,cn=plugins,cn=config is added However I wonder if it's possible to integrate a 389DS (ns-slapd, http://www.port389.org/) into an OpenLDAP multi-master configuration. Definitely one cannot sync the configuration section, because it's too different. For example the ACL Syntax looks like this: (targetattr="carLicense || description || displayName || facsimileTelephoneNumber || homePhone || homePostalAddress || initials || jpegPhoto || labeledURI || mail || mobile || pager || photo || postOfficeBox || postalAddress || postalCode || preferredDeliveryMethod || preferredLanguage || registeredAddress || roomNumber || secretary || seeAlso || st || street || telephoneNumber || telexNumber || title || userCertificate || userPassword || userSMIMECertificate || x500UniqueIdentifier")(version 3.0; acl "Enable self write for common attributes"; allow (write) userdn="ldap:///self";) Regards, Ulrich

3 4

OpenLDAP instances crashes
by Saurabh Lahoti 23 Aug '18

23 Aug '18

Dear, Today, received below error in /var/log/messages with OpenLDAP instance crashing. Aug 16 13:21:07 muledeer kernel: slapd[29253]: segfault at 0 ip 00007fbeddf3af09 sp 00007fb72effc480 error 4 in uniquemember.so.0.0.0[7fbeddf3a000+2000] Aug 16 13:21:08 muledeer abrt[24629]: Saved core dump of pid 16470 (/usr/app/ldap/openldap2.4.46/libexec/slapd) to /var/spool/abrt/ccpp-2018-08-16-13:21:07-16470 (472973312 bytes) Aug 16 13:21:08 muledeer abrtd: Directory 'ccpp-2018-08-16-13:21:07-16470' creation detected Aug 16 13:21:08 muledeer abrtd: Executable '/usr/app/ldap/openldap2.4.46/libexec/slapd' doesn't belong to any package and ProcessUnpackaged is set to 'no' Aug 16 13:21:08 muledeer abrtd: 'post-create' on '/var/spool/abrt/ccpp-2018-08-16-13:21:07-16470' exited with 1 Aug 16 13:21:08 muledeer abrtd: Deleting problem directory '/var/spool/abrt/ccpp-2018-08-16-13:21:07-16470' Could you please guide us in finding probable root of this error..? ---- *Thanks & Kind Regards,* Saurabh LAHOTI. *Ideas enlighten Innovation**!!!* Please consider the environment before printing this mail..!!

6 13

help to get our openldap updated and replicated
by admin＠genome.arizona.edu 23 Aug '18

23 Aug '18

Hi all, I am about the 4th sysadmin for our organization, and our openldap is old, 2.4.40 system version for CentOS 6.9. Also there might have been incorrect modifications to the slapd.d files since it was really difficult to update things. The olcRootDN was set to "cn=config" somehow so I had to manually update that to the Manager account and figure out the CRC32 and everything, but at least I could make some updates now. Anyway, I would like to get our installation updated to a current version, as well as set up some sort of replication with our other server, in case one goes down then our users could still login and use our applications, or I could still add/delete users. Perhaps a multi-master config would be best? (Also maybe update the databases too since they are using bdb format? but maybe that is just unnecessary extra work) I tried to setup replication by following a guide, but was not successful and actually made things worse for our demon, so had to undo the changes for now. I guess 2.4.40 has some problems with replication anyway from what I've heard. First, to get openldap updated, would it be as simple as compiling the new version and then updating the init script /etc/init.d/slapd to point to the new binaries? I would stop slapd and get a backup of /etc/openldap and /var/lib/ldap. Then I could just leave our current config in /etc/openldap and databases in /var/lib/ldap? I've already built the new version and "make test" was successful so am ready to proceed from there with your assistance and suggestions. Thanks, -- Chandler Arizona Genomics Institute www.genome.arizona.edu

2 1

OpenLDAP Developer Day 2018
by Howard Chu 23 Aug '18

23 Aug '18

In case you missed it, we're holding an event to celebrate the 20th anniversary of the OpenLDAP Project this October in Germany. Talks are being solicited now. https://daasi.de/de/call-for-content_odd2018/ -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

OpenLDAP Developpers Day Silver Jubilee
by Peter 22 Aug '18

22 Aug '18

Dear all, something completely different: Join Us Celebrating 20 Years of OpenLDAP The community is coming together! ON:*October 8th, 2018* IN:*Tübingen, Germany* LOCATION: *Computing Center of the University of Tübingen* You are invited to join this forum, which is a great way to share and discuss your ideas, achievements and visions with the community. With this Call for Content we want to enable the community to continue the professional discourse. For this we are looking for contributions: either deployment success stories or reports on new development activities. This event brings together developers of OpenLDAP software, directory researchers and other OpenLDAP community members interested in discussing ongoing and future development efforts. If you want to participate and to present a topic, please contact odd-silverjubilee(a)daasi.de <mailto:odd-silverjubilee@daasi.de>before September 10th, 2018. Meet the team, learn and network. More info at: https://daasi.de/en/2018/08/14/5th-openldap-developer-day-2018-20-years-are… And please forward this to people connected with OpenLDAP. Cheers, Peter -- _______________________________________________________________________ Peter Gietz (CEO) DAASI International GmbH phone: +49 7071 407109-0 Europaplatz 3 Fax: +49 7071 407109-9 D-72072 Tübingen mail: peter.gietz(a)daasi.de Germany Web: www.daasi.de DAASI International GmbH, Tübingen Geschäftsführer Peter Gietz, Amtsgericht Stuttgart HRB 382175 Directory Applications for Advanced Security and Information Management _______________________________________________________________________

1 0

Re: Multiprocess LMDB transaction: resource not available
by Stefano Cossu 19 Aug '18

19 Aug '18

So, while perusing lmdb.h I saw this: > Use an MDB_env* in the process which opened it, not after fork(). That was my problem. It had nothing to do with transactions. I need to open the environment and hold a separate handle in each process. Right? Moving the mdb_env_create and mdb_env_open functions and related variables inside the get_() function got rid of the errors. In my dummy code below that is obviously terribly expensive, but my real application is running a pool of long-lived workers (HTTP server) and the cost of opening the environments only happens at server start. Thanks, Stefano On 08/19/2018 10:36 AM, Stefano Cossu wrote: > Hello, > I am writing a framework in Cython using multi-process access to an LMDB > database. I ran into a "Resource not available" error. > > I isolated the problem in the following script (this is Cython calling > the LMDB C API, so bear with the hybrid syntax): > > > import time > cimport cylmdb as lmdb # This is a Cython header mirroring lmdb.h > > import multiprocessing > import threading > > cdef: > lmdb.MDB_env *env > lmdb.MDB_dbi dbi > > > cdef void _check(int rc) except *: > if rc != lmdb.MDB_SUCCESS: > out_msg = 'LMDB Error ({}): {}'.format( > rc, lmdb.mdb_strerror(rc).decode()) > raise RuntimeError(out_msg) > > > cpdef void get_() except *: > cdef: > lmdb.MDB_txn *txn > lmdb.MDB_val key_v, data_v > > _check(lmdb.mdb_txn_begin(env, NULL, lmdb.MDB_RDONLY, &txn)) > > key_v.mv_data = b'a' > key_v.mv_size = 1 > > _check(lmdb.mdb_get(txn, dbi, &key_v, &data_v)) > print((<unsigned char *>data_v.mv_data)[:data_v.mv_size]) > time.sleep(1) > _check(lmdb.mdb_txn_commit(txn)) > print('Thread {} in process {} done.'.format( > threading.currentThread().getName(), > multiprocessing.current_process().name)) > > > def run(): > cdef: > unsigned int flags = 0 > #unsigned int flags = lmdb.MDB_NOTLS # I tried this too. > lmdb.MDB_txn *wtxn > lmdb.MDB_val key_v, data_v > > # Set up environment. > _check(lmdb.mdb_env_create(&env)) > _check(lmdb.mdb_env_set_maxreaders(env, 128)) > _check(lmdb.mdb_env_open(env, '/tmp/test_mp', flags, 0o644)) > > # Create DB. > _check(lmdb.mdb_txn_begin(env, NULL, 0, &wtxn)) > _check(lmdb.mdb_dbi_open(wtxn, NULL, lmdb.MDB_CREATE, &dbi)) > > # Write something. > key_v.mv_data = b'a' > key_v.mv_size = 1 > ts = str(time.time()).encode() > data_v.mv_data = <unsigned char *>ts > data_v.mv_size = len(ts) > _check(lmdb.mdb_put(wtxn, dbi, &key_v, &data_v, 0)) > _check(lmdb.mdb_txn_commit(wtxn)) > > > print('Multiprocess jobs:') > for i in range(5): > multiprocessing.Process(target=get_).start() > # Env should be closed only after all processes return. > #lmdb.mdb_env_close(env) > > > If I execute run(), the first process runs successfully, but apparently > it's holding on to some resources that the other processes need. > > Multiprocess jobs: > b'1534691578.4300401' > Process Process-2: > Traceback (most recent call last): > File "/usr/lib/python3.6/multiprocessing/process.py", line 258, in > _bootstrap > self.run() > File "/usr/lib/python3.6/multiprocessing/process.py", line 93, in run > self._target(*self._args, **self._kwargs) > File "lakesuperior/sandbox/threading_poc.pyx", line 23, in > lakesuperior.sandbox.threading_poc.get_ > cpdef void get_() except *: > File "lakesuperior/sandbox/threading_poc.pyx", line 28, in > lakesuperior.sandbox.threading_poc.get_ > _check(lmdb.mdb_txn_begin(env, NULL, lmdb.MDB_RDONLY, &txn)) > File "lakesuperior/sandbox/threading_poc.pyx", line 20, in > lakesuperior.sandbox.threading_poc._check > raise RuntimeError(out_msg) > RuntimeError: LMDB Error (11): Resource temporarily unavailable > Process Process-3: > Traceback (most recent call last): > File "/usr/lib/python3.6/multiprocessing/process.py", line 258, in > _bootstrap > self.run() > File "/usr/lib/python3.6/multiprocessing/process.py", line 93, in run > self._target(*self._args, **self._kwargs) > File "lakesuperior/sandbox/threading_poc.pyx", line 23, in > lakesuperior.sandbox.threading_poc.get_ > cpdef void get_() except *: > File "lakesuperior/sandbox/threading_poc.pyx", line 28, in > lakesuperior.sandbox.threading_poc.get_ > _check(lmdb.mdb_txn_begin(env, NULL, lmdb.MDB_RDONLY, &txn)) > File "lakesuperior/sandbox/threading_poc.pyx", line 20, in > lakesuperior.sandbox.threading_poc._check > raise RuntimeError(out_msg) > RuntimeError: LMDB Error (11): Resource temporarily unavailable > Process Process-4: > > Process Process-5: > Traceback (most recent call last): > File "/usr/lib/python3.6/multiprocessing/process.py", line 258, in > _bootstrap > self.run() > File "/usr/lib/python3.6/multiprocessing/process.py", line 93, in run > self._target(*self._args, **self._kwargs) > File "lakesuperior/sandbox/threading_poc.pyx", line 23, in > lakesuperior.sandbox.threading_poc.get_ > cpdef void get_() except *: > Traceback (most recent call last): > File "lakesuperior/sandbox/threading_poc.pyx", line 28, in > lakesuperior.sandbox.threading_poc.get_ > _check(lmdb.mdb_txn_begin(env, NULL, lmdb.MDB_RDONLY, &txn)) > File "lakesuperior/sandbox/threading_poc.pyx", line 20, in > lakesuperior.sandbox.threading_poc._check > raise RuntimeError(out_msg) > File "/usr/lib/python3.6/multiprocessing/process.py", line 258, in > _bootstrap > self.run() > File "/usr/lib/python3.6/multiprocessing/process.py", line 93, in run > self._target(*self._args, **self._kwargs) > File "lakesuperior/sandbox/threading_poc.pyx", line 23, in > lakesuperior.sandbox.threading_poc.get_ > cpdef void get_() except *: > RuntimeError: LMDB Error (11): Resource temporarily unavailable > File "lakesuperior/sandbox/threading_poc.pyx", line 28, in > lakesuperior.sandbox.threading_poc.get_ > _check(lmdb.mdb_txn_begin(env, NULL, lmdb.MDB_RDONLY, &txn)) > File "lakesuperior/sandbox/threading_poc.pyx", line 20, in > lakesuperior.sandbox.threading_poc._check > raise RuntimeError(out_msg) > RuntimeError: LMDB Error (11): Resource temporarily unavailable > > > If I run the same function multiple times on the same process, > everything is fine. > > Can someone point out what is wrong with this script? > > Thank you, > Stefano > > > -- exitsts .not exeunt hoall. http://stefano.cossu.cc

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical