openldap-technical

openldap-technical@openldap.org

3 participants
9898 discussions

Master Master or Master Slave Openldap replication.
by Kaushal Shriyan 01 Jul '14

01 Jul '14

Hi, Are there any document or writeup regarding setup of Master Master Openldap application? Do i need to go with setup of Master Master or Master Slave openldap replication, Please advice which approach should i follow and help me understand with some use cases. Regards, Kaushal

2 1

how to use ppolicy schema
by Udai Singh Mehra (Vizury) 30 Jun '14

30 Jun '14

Hi, I want to set password policies for my users in LDAP. Therefore i used the ppolicy.schema and added it to cn=config. I also used the ppolicy to be used as a olcOverLay Module. But I am unable to see a way to use it. I fail to create a default password policy for all the users. Can anyone send me some guidling steps as to how can I use the ppolicy.schema and set password policies for my users. i am using openldap in Ubuntu 14.04 which has everything set in slapd database. thanks, -- Udai Singh Mehra Infrastructure Engineering and Operations

1 0

LDAP limit of groups per user
by Julien Courtès 30 Jun '14

30 Jun '14

Hi, I am experiencing an issue with posix groups. I have a user which belongs to 28 posix groups but when I use the command "id" on the user, I can't see all the groups whereas as root, I can clearly see that this member belongs to much groups. Is there a limit of posix groups per user? If yes, how to increase it? Thanks Julien Courtès

2 2

zero copy jni lib for lmdb
by Kristoffer Sjögren 29 Jun '14

29 Jun '14

Hi I'm experimenting a bit with developing a JNI library for LMDB that utilize zero copy buffers. As you may know there is a project called lmdbjni [1] already but it does buffer copy only. I must admit that my C and JNI skills is not really that great, so please forgive any stupidity on my part. Anyway, i'm taking the sun.misc.Unsafe (no bounds checking) approach for memory allocation and pass memory addresses through JNI to LMDB for both writes and reads and at the moment I have implemented put, get, begin, commit [2]. I suspect that something is wrong because the performance between the buffer copy and zero copy isn't really that big. lmdbjni is even faster sometimes, write commits specifically is almost twice as fast. The test write 1M entries with a 4 bytes key (1-1M) and 128 bytes value (random) committed in one go. LMDB is configured identically both implementations with 4GB MDB_WRITEMAP. I run Linux 3.2.0 with Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz. JProfiler show no signs of bottlenecks in Java in my implementation, most time is spent on the native methods put and commit. The opposite is true for lmdbjni where most time is spent creating and writing Java byte buffers, while native put and commit is just a fraction of that time. Not sure exactly the significance of the gcc compiler but here is how I do it. gcc -g -Wall -O2 -Wbad-function-cast -Wno-write-strings -fPIC -shared -I$JAVA_HOME/include -I$JAVA_HOME/include/linux -Isrc/main/native src/main/native/jlmdb.c src/main/native/liblmdb.a -o target/linux64/libjlmdb.so - What could be the reason for "slow(er)" commits? - How much faster can I expect properly implemented zero copying to be? - Maybe lmdbjni have defacto standard optimizations that me as a C noobie might have overlooked? - Are there any performance counters, tracepoints or similar that might be of interest to find where latency is spent? Greatful for any tips or pointers on how to track the problem down. Cheers, -Kristoffer [1] https://github.com/chirino/lmdbjni [2] JNI MDB_env *mdb_env; MDB_dbi dbi; JNIEXPORT jlong JNICALL Java_NativeLmdb_put (JNIEnv * env, jobject obj, jlong tx, jlong keyAddress, jlong keySize, jlong valAddress, jlong valSize) { MDB_val mdb_key, mdb_val; mdb_key.mv_data = (void *)(intptr_t) keyAddress; mdb_key.mv_size = (size_t) keySize; mdb_val.mv_data = (void *)(intptr_t) valAddress; mdb_val.mv_size = (size_t) valSize; int rc = mdb_put((MDB_txn *) (intptr_t) tx, dbi, &mdb_key, &mdb_val, 0); return rc; } JNIEXPORT jlong JNICALL Java_NativeLmdb_get (JNIEnv *env, jobject o, jlong tx, jlong a, jlong s) { MDB_val mdb_key, mdb_val; mdb_key.mv_data = (void *)(intptr_t) a; mdb_key.mv_size = (size_t) s; int rc = mdb_get((MDB_txn *) (intptr_t) tx, dbi, &mdb_key, &mdb_val); if (rc == 0) { return (intptr_t) mdb_val.mv_data; } return -1; } JNIEXPORT void JNICALL Java_org_deephacks_lmdb_NativeLmdb_mdb_1txn_1begin(JNIEnv *env, jobject obj, jlongArray array) { jlong *nArray = (*env)->GetLongArrayElements(env, array, NULL); MDB_txn *txn; mdb_txn_begin(mdb_env, NULL, 0, &txn); nArray[0] = (jlong) txn; (*env)->ReleaseLongArrayElements(env, array, nArray, 0); } JNIEXPORT void JNICALL Java_NativeLmdb_mdb_1txn_1begin(JNIEnv *env, jobject obj, jlongArray tx) { jlong *nArray = (*env)->GetLongArrayElements(env, array, NULL); MDB_txn *txn; mdb_txn_begin(mdb_env, NULL, 0, &txn); tx[0] = (jlong) txn; (*env)->ReleaseLongArrayElements(env, tx, nArray, 0); } JNIEXPORT jint JNICALL Java_NativeLmdb_mdb_1txn_1commit(JNIEnv *env, jobject obj, jlong tx) { return (jint)mdb_txn_commit((MDB_txn *)(intptr_t)tx); } JNIEXPORT void JNICALL Java_NativeLmdb_open (JNIEnv * env, jobject obj) { mdb_env_create(&mdb_env); mdb_env_set_mapsize(mdb_env, 4294967296); mdb_env_open(mdb_env, "/tmp/testdb", MDB_WRITEMAP, 0664); MDB_txn *txn; mdb_txn_begin(mdb_env, NULL, 0, &txn); mdb_open(txn, NULL, 0, &dbi); mdb_txn_commit(txn); }

2 3

Syncrepl and problem with ldap_sasl_bind_s failed?
by Eivind Olsen 27 Jun '14

27 Jun '14

Hello. I'm struggling a bit with setting up syncrepl replication between two OpenLDAP servers (using version 2.4.39 compiled by the LTB project, on top of RHEL6, if that matters in this case). Does anyone here have some suggestions on what I should look deeper into here? Is it a known newbie-error I'm making? I can post configuration files, describe how I attempt to set up the replication etc. The two servers have a replicated cn=config, in addition to two suffixes with their own HDB backend. The first of those suffixes are meant for administrative data, replication user account, etc., and the second suffix is for some end-user accounts/settings. I seem to have managed to get the first HDB backend to replicate, but I can't get the 2nd to work for some reason (most likely because I'm doing something wrong). When I start OpenLDAP with some debug logging, I see several log line, but the first ones that catches my interest looks like: 53ac30ff slapd starting 53ac30ff slap_client_connect: URI=ldap://ldap01-testing.aminor.no DN="cn=replicator,ou=admins,ou=internal,o=aminor" ldap_sasl_bind_s failed (49) 53ac30ff do_syncrepl: rid=005 rc 49 retrying (4 retries left) (this was seen on the node ldap02-testing.aminor.no. The hostnames exist in DNS internally, the two nodes can see each other on the IP level etc.) Both the working and non-working suffix are configured to use the same replication user (which lives in the 1st suffix). In my case, I have 2 hdb backends, one seems to replicate just fine, the other doesn't. I can use ldapsearch on the suffix for that non-replicating hdb from both nodes to both nodes, and get replies back (running ldapsearch -x, with -D and -w giving the cn=replicator,ou=admins...etc. and password). I went to the #openldap IRC channel and asked about this issue earlier today, and I saw another person ask about the same "ldap_sasl_bind_s failed (49)" error message as well. He was using a somewhat older OpenLDAP though (2.4.23) on Debian though. Regards Eivind Olsen

3 6

mdb maxsize too big - no specific error message?
by Marc Patermann 25 Jun '14

25 Jun '14

Hi, is there no specific error message if the mdb maxsize is too big (for the containing filesystem)? I used my ansible (great tool!) playbook to create an ldap server in a test VM. This was only 8 GB small. My initial slapadd failed and I did not why. (On my "real hardware" test machine this was all fine.) "mdb_db_open: cannot be opened, err 112, Restore from Backup!" If this is what "err 112" means, it should better say "maxsize too big" or something. It took me some time to figure out, my disk was to small for my config. Marc

2 1

slapd dead. pls advise how I can restart it
by Eileen(=^ω^=) 25 Jun '14

25 Jun '14

Hi team, My LDAP service had an unexpected blackout, it can’t be started. could you pls advise how I can restart it? When I check the slapd status: [root@nplserver1 ~]# service slapd status slapd dead but pid file exists àbut I can’t find any pid file When I start slapd, below will be come. [root@nplserver1 openldap]# slapd start -d 256 @(#) $OpenLDAP: slapd 2.4.23 (Feb 22 2013 01:50:21) $ mockbuild@c6b7.bsys.dev.centos.org:/builddir/build/BUILD/openldap-2.4.23/openldap-2.4.23/build-servers/servers/slapd bdb(dc=npl,dc=tmsr): unable to join the environment bdb_db_open: database "dc=npl,dc=tmsr" cannot be opened, err 11. Restore from backup! bdb(dc=npl,dc=tmsr): txn_checkpoint interface requires an environment configured for the transaction subsystem bdb_db_close: database "dc=npl,dc=tmsr": txn_checkpoint failed: Invalid argument (22). backend_startup_one (type=bdb, suffix="dc=npl,dc=tmsr"): bi_db_open failed! (11) bdb_db_close: database "dc=npl,dc=tmsr": alock_close failed slapd stopped. And I can’t find any process in 389 port.‍ best wishes Eileen

7 8

Re: slapd dead. pls advise how I can restart it
by Mauricio Tavares 24 Jun '14

24 Jun '14

On Tue, Jun 24, 2014 at 11:31 AM, Alessandro Avagliano <alessandro(a)avagliano.berlin> wrote: > > On 24/06/14 16:10, Mauricio Tavares wrote: >> >> I does sound like the database is corrupted somehow. slapcat >> needs slapd to be running, right? >> > > Hello Mauricio, > Hello and thanks for the reply. I will save it in my notes. That said, the original poster was Eileen, not me. I do hope she'll try your suggestions and get the data back. > (If you don't have a backup... ) > ...depending on your operating system and OpenLDAP version installed, > you should have on your system a tool called db<version>_recover > > e.g.: db5.1_recover, db4.8_recover and so on. > > (from the man page:) > "db5.1_recover - Restore the database to a consistent state > > The db5.1_recover utility must be run after an unexpected application, > Berkeley DB, or system failure to > restore the database to a consistent state. All committed transactions > are guaranteed to appear after > db5.1_recover has run, and all uncommitted transactions will be > completely undone." > > > Be sure to make a backup copy of your db before running it, and that the > version of the db utilities that you are running matches your BDB > version (I haven't tried to recover it using different utilities/db > version). > > If you manage to restore your db, make sure you perform regular backups > and that you have at least 1 slapd replica running.... they can both > help you to restore the system in such situations > > I hope this helps, > > > Kind Regards, > Alessandro > >

1 0

ldap_set_option() performs blocking name resolution during initalization
by Jan Synacek 24 Jun '14

24 Jun '14

Is it intentional? If yes, could you please explain why, or point me to a documentation where I can find the answer? A backtrace and a snippet of code follow: #0 0x00007fda39c80a70 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007fda38d17e0d in send_dg (resplen2=0x0, anssizp2=0x0, ansp2=0x0, anscp=0x7fff2548cb30, gotsomewhere=<synthetic pointer>, v_circuit=<synthetic pointer>, ns=0, terrno=0x7fff2548bab0, anssizp=0x7fff2548bbf0, ansp=0x7fff2548baa8, buflen2=0, buf2=0x0, buflen=36, buf=0x7fff2548bc20 "\tg\001", statp=0x7fda39f533e0 <_res(a)GLIBC_2.2.5>) at res_send.c:1059 #2 __libc_res_nsend (statp=statp@entry=0x7fda39f533e0 <_res(a)GLIBC_2.2.5>, buf=buf@entry=0x7fff2548bc20 "\tg\001", buflen=<optimized out>, buf2=buf2@entry=0x0, buflen2=buflen2@entry=0, ans=ans@entry=0x7fff2548c700 "", anssiz=anssiz@entry=1024, ansp=ansp@entry=0x7fff2548cb30, ansp2=ansp2@entry=0x0, nansp2=nansp2@entry=0x0, resplen2=resplen2@entry=0x0) at res_send.c:556 #3 0x00007fda38d15d47 in __GI___libc_res_nquery ( statp=statp@entry=0x7fda39f533e0 <_res(a)GLIBC_2.2.5>, name=0x7fff2548d140 "client.example.com", class=class@entry=1, type=type@entry=1, answer=answer@entry=0x7fff2548c700 "", anslen=anslen@entry=1024, answerp=answerp@entry=0x7fff2548cb30, answerp2=answerp2@entry=0x0, nanswerp2=nanswerp2@entry=0x0, resplen2=resplen2@entry=0x0) at res_query.c:226 #4 0x00007fda38d16963 in __libc_res_nquerydomain (domain=0x0, resplen2=0x0, nanswerp2=0x0, answerp2=0x0, answerp=0x7fff2548cb30, anslen=1024, answer=0x7fff2548c700 "", type=1, class=1, name=0x7fff2548d140 "client.example.com", statp=0x7fda39f533e0 <_res(a)GLIBC_2.2.5>) at res_query.c:582 #5 __GI___libc_res_nsearch (statp=0x7fda39f533e0 <_res(a)GLIBC_2.2.5>, name=name@entry=0x7fff2548d140 "client.example.com", class=class@entry=1, type=type@entry=1, answer=answer@entry=0x7fff2548c700 "", anslen=anslen@entry=1024, answerp=0x7fff2548cb30, answerp2=answerp2@entry=0x0, nanswerp2=nanswerp2@entry=0x0, resplen2=resplen2@entry=0x0) at res_query.c:378 #6 0x00007fda2f2777e4 in __GI__nss_dns_gethostbyname3_r ( name=name@entry=0x7fff2548d140 "client.example.com", af=af@entry=2, result=result@entry=0x7fff2548d120, buffer=buffer@entry=0x1f33590 "\177", buflen=buflen@entry=992, errnop=errnop@entry=0x7fda3d8966a0, h_errnop=h_errnop@entry=0x7fff2548d10c, ttlp=ttlp@entry=0x0, canonp=canonp@entry=0x0) at nss_dns/dns-host.c:192 #7 0x00007fda2f277af0 in _nss_dns_gethostbyname_r ( name=0x7fff2548d140 "client.example.com", result=0x7fff2548d120, buffer=0x1f33590 "\177", buflen=992, errnop=0x7fda3d8966a0, h_errnop=0x7fff2548d10c) at nss_dns/dns-host.c:273 #8 0x00007fda39c9e163 in __gethostbyname_r ( name=name@entry=0x7fff2548d140 "client.example.com", resbuf=resbuf@entry=0x7fff2548d120, buffer=0x1f33590 "\177", buflen=buflen@entry=992, result=result@entry=0x7fff2548d118, h_errnop=h_errnop@entry=0x7fff2548d10c) at ../nss/getXXbyYY_r.c:266 #9 0x00007fda3bb1b3de in ldap_pvt_gethostbyname_a ( name=name@entry=0x7fff2548d140 "client.example.com", resbuf=resbuf@entry=0x7fff2548d120, buf=buf@entry=0x7fff2548d110, result=result@entry=0x7fff2548d118, herrno_ptr=herrno_ptr@entry=0x7fff2548d10c) at util-int.c:350 #10 0x00007fda3bb1b5d0 in ldap_pvt_get_fqdn (name=0x7fff2548d140 "client.example.com", name@entry=0x0) at util-int.c:748 #11 0x00007fda3bb19b47 in ldap_int_initialize ( gopts=gopts@entry=0x7fda3bd40000 <ldap_int_global_options>, dbglvl=dbglvl@entry=0x0) at init.c:645 #12 0x00007fda3bb1a627 in ldap_set_option (ld=0x0, option=24582, invalue=0x7fff2548d2b0) at options.c:446 #13 0x00007fda30951cf6 in setup_tls_config (basic_opts=0x1f30450) at src/providers/ldap/sdap.c:533 #14 0x00007fda308214b3 in ldap_id_init_internal (bectx=0x1f12b40, ops=0x1f12cb0, pvt_data=0x7fff2548d5e8) at src/providers/ldap/ldap_init.c:146 #15 0x00007fda30821ba0 in sssm_ldap_id_init (bectx=0x1f12b40, ops=0x1f12cb0, pvt_data=0x1f12cb8) at src/providers/ldap/ldap_init.c:199 #16 0x000000000041b227 in load_backend_module (ctx=0x1f12b40, bet_type=BET_ID, bet_info=0x1f12ca8, default_mod_name=0x0) at src/providers/data_provider_be.c:2346 #17 0x000000000041ce4c in be_process_init (mem_ctx=0x1f0ba80, be_domain=0x1f093f0 "localipaldap", ev=0x1f0a630, cdb=0x1f0bb90) at src/providers/data_provider_be.c:2520 #18 0x000000000041fde6 in main (argc=3, argv=0x7fff2548e008) at src/providers/data_provider_be.c:2743 735 /* LDAP_OPT_X_TLS_REQUIRE_CERT has to be set as a global option, 736 * because the SSL/TLS context is initialized from this value. */ 737 ret = ldap_set_option(NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, 738 &ldap_opt_x_tls_require_cert); 739 if (ret != LDAP_OPT_SUCCESS) { 740 DEBUG(SSSDBG_CRIT_FAILURE, 741 "ldap_set_option failed: %s\n",sss_ldap_err2string(ret)); 742 return EIO; 743 } Thanks, -- Jan Synacek Software Engineer, Red Hat

5 7

[LMDB] Single writer question
by Alain 18 Jun '14

18 Jun '14

If my memory serves me well, at some point Howard mentioned that LMDB was looking at moving from a single environment writer to a single writer per database. Am I just dreaming or did I see that? And if I'm not dreaming then what is the status of this, as my experiment seem to show that there is no performance gain to be have by splitting your data in more than one db. Thanks Alain

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical