openldap-technical April 2013

openldap-technical@openldap.org

69 participants
74 discussions

RE: slapd-meta as a proxy for a monolithic namespace
by Hummel, Wolfgang 24 Apr '13

24 Apr '13

Hello, thanks a lot for your support on this topic. Both inputs from Howard and Pierangelo were really helpful. With the additional config tweak it works properly. So far I tested search and delete operations successfully. Other tests to follow ... Regards Wolfgang Hummel -----Original Message----- From: Hummel, Wolfgang Sent: Dienstag, 23. April 2013 18:10 To: 'openldap-technical(a)openldap.org' Subject: slapd-meta as a proxy for a monolithic namespace Hello OpenLDAP community, we are currently planning for a largescale directory with > 1 Bio. entries in a single namespace. The idea is to divide the DB in 10 equal sized DBs and let them access by slapd-meta proxies. Example: dn: ou=rsp1,c=de,o=mno entries with uid=79101234567890, 79101234567891 etc. 791 is always fix In our scenario each server would have 100 Mio. entries using the last digit of uid as a naturally even balanced distribution mechanism. Here are the questions: - is slapd-meta a feasible approach for this scenario ? - how could the slapd.conf for the proxy look like ? Here is a (non working) example with 2 backend servers. What is wrong about it ? ... moduleload back_meta moduleload back_ldap ... ####################################################################### # Meta database ####################################################################### database meta suffix " ou=rsp1,c=de,o=mno" dncache-ttl forever lastmod off rootdn "cn=admin,ou=rsp1,c=de,o=mno" rootpw secret network-timeout 1 uri "ldap://10.11.12.170/ ou=rsp1,c=de,o=mno" rewriteEngine on #rewriteContext searchFilterAttrDN rewriteContext searchFilter rewriteRule '^uid=[0-9]{11}1,.*' 'ldap://10.11.12.170/%0' ':@' uri "ldap://10.11.12.180/ ou=rsp1,c=de,o=mno" rewriteEngine on #rewriteContext searchFilterAttrDN rewriteContext searchFilter rewriteRule '^uid=[0-9]{11}2,.*' 'ldap://10.11.12.180/%0' ':@' ...

1 0

slapd-meta as a proxy for a monolithic namespace
by Hummel, Wolfgang 24 Apr '13

24 Apr '13

Hello OpenLDAP community, we are currently planning for a largescale directory with > 1 Bio. entries in a single namespace. The idea is to divide the DB in 10 equal sized DBs and let them access by slapd-meta proxies. Example: dn: ou=rsp1,c=de,o=mno entries with uid=79101234567890, 79101234567891 etc. 791 is always fix In our scenario each server would have 100 Mio. entries using the last digit of uid as a naturally even balanced distribution mechanism. Here are the questions: - is slapd-meta a feasible approach for this scenario ? - how could the slapd.conf for the proxy look like ? Here is a (non working) example with 2 backend servers. What is wrong about it ? ... moduleload back_meta moduleload back_ldap ... ####################################################################### # Meta database ####################################################################### database meta suffix " ou=rsp1,c=de,o=mno" dncache-ttl forever lastmod off rootdn "cn=admin,ou=rsp1,c=de,o=mno" rootpw secret network-timeout 1 uri "ldap://10.11.12.170/ ou=rsp1,c=de,o=mno" rewriteEngine on #rewriteContext searchFilterAttrDN rewriteContext searchFilter rewriteRule '^uid=[0-9]{11}1,.*' 'ldap://10.11.12.170/%0' ':@' uri "ldap://10.11.12.180/ ou=rsp1,c=de,o=mno" rewriteEngine on #rewriteContext searchFilterAttrDN rewriteContext searchFilter rewriteRule '^uid=[0-9]{11}2,.*' 'ldap://10.11.12.180/%0' ':@' ... logfile snippet for # ldapsearch -LLL -xD uid=admin,ou=rsp1,c=de,o=mno -w secret -b ou=rsp1,c=de,o=mno uid=791720001981 ldap_bind: Invalid credentials (49) Apr 23 08:44:13 slapd[26200]: >>> dnPrettyNormal: <uid=admin,ou=rsp1,c=de,o=mno> Apr 23 08:44:13 slapd[26200]: <<< dnPrettyNormal: <uid=admin,ou=rsp1,c=de,o=mno>, <uid=admin,ou=rsp1,c=de,o=mno> Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 BIND dn="uid=admin,ou=rsp1,c=de,o=mno" method=128 Apr 23 08:44:13 slapd[26200]: do_bind: version=3 dn="uid=admin,ou=rsp1,c=de,o=mno" method=128 Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 meta_back_bind: dn="uid=admin,ou=rsp1,c=de,o=mno". Apr 23 08:44:13 slapd[26200]: conn=1015 op=0: meta_back_getconn[0] Apr 23 08:44:13 slapd[26200]: conn=1015 op=0: meta_back_getconn[1] Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 meta_back_getconn: candidates=2 conn=ANON fetched Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 >>> meta_back_search_start[0] Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 >>> meta_search_dobind_init[0] Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 <<< meta_search_dobind_init[0]=1 Apr 23 08:44:13 slapd[26200]: ==> rewrite_context_apply [depth=1] string='uid=admin,ou=rsp1,c=de,o=mno' Apr 23 08:44:13 slapd[26200]: ==> rewrite_context_apply [depth=1] res={0,'NULL'} Apr 23 08:44:13 slapd[26200]: [rw] searchBase: "uid=admin,ou=rsp1,c=de,o=mno" -> "uid=admin,ou=rsp1,c=de,o=mno" Apr 23 08:44:13 slapd[26200]: ==> rewrite_context_apply [depth=1] string='(objectClass=*)' Apr 23 08:44:13 slapd[26200]: ==> rewrite_rule_apply rule=''^uid=[0-9]{11}1,.*'' string='(objectClass=*)' [1 pass(es)] Apr 23 08:44:13 slapd[26200]: ==> rewrite_context_apply [depth=1] res={0,'(objectClass=*)'} Apr 23 08:44:13 slapd[26200]: [rw] searchFilter: "(objectClass=*)" -> "(objectClass=*)" Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 <<< meta_back_search_start[0]=1 Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 >>> meta_back_search_start[1] Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 >>> meta_search_dobind_init[1] Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 <<< meta_search_dobind_init[1]=1 Apr 23 08:44:13 slapd[26200]: ==> rewrite_context_apply [depth=1] string='uid=admin,ou=rsp1,c=de,o=mno' Apr 23 08:44:13 slapd[26200]: ==> rewrite_context_apply [depth=1] res={0,'NULL'} Apr 23 08:44:13 slapd[26200]: [rw] searchBase: "uid=admin,ou=rsp1,c=de,o=mno" -> "uid=admin,ou=rsp1,c=de,o=mno" Apr 23 08:44:13 slapd[26200]: ==> rewrite_context_apply [depth=1] string='(objectClass=*)' Apr 23 08:44:13 slapd[26200]: ==> rewrite_rule_apply rule=''^uid=[0-9]{11}2,.*'' string='(objectClass=*)' [1 pass(es)] Apr 23 08:44:13 slapd[26200]: ==> rewrite_context_apply [depth=1] res={0,'(objectClass=*)'} Apr 23 08:44:13 slapd[26200]: [rw] searchFilter: "(objectClass=*)" -> "(objectClass=*)" Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 <<< meta_back_search_start[1]=1 Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 meta_back_search: ncandidates=2 cnd="**" Apr 23 08:44:13 slapd[26200]: daemon: activity on 1 descriptor Apr 23 08:44:13 slapd[26200]: daemon: activity on: Apr 23 08:44:13 slapd[26200]: Apr 23 08:44:13 slapd[26200]: daemon: epoll: listen=8 active_threads=0 tvp=zero Apr 23 08:44:13 slapd[26200]: daemon: epoll: listen=9 active_threads=0 tvp=zero Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 meta_back_search[0] match="" err=32 (No such object). Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 meta_back_search[1] match="" err=32 (No such object). Apr 23 08:44:13 slapd[26200]: send_ldap_result: conn=1015 op=0 p=3 Apr 23 08:44:13 slapd[26200]: send_ldap_result: err=32 matched="ou=rsp1,c=de,o=mno" text="" Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 meta_back_bind: no target for dn "uid=admin,ou=rsp1,c=de,o=mno" (32).

3 2

ldap with TLS
by Rodney Simioni 23 Apr '13

23 Apr '13

Hi, I'm getting a weird behavior in LDAP with TLS. Using: openldap Linux Red Hat Sssd Nslcd When I issue a ' ldapsearch -x ZZ', it works flawlessly but when issue a `getent passwd`, I get back the system users in /etc/passwd file but I don't see the ldap users. The openldap.log indicates the following when I issue the 'getent passwd' command connection_read(14): TLS accept failure error=-1 id=1037 But it does not give any errors when doing the ldapsearch -x ZZ. So, if I have TLS not correctly configured, shouldn't it not work completely? Here's my sssd.conf: [domain/local] debug_level = 9 ldap_id_use_start_tls = True cache_credentials = True ldap_search_base = dc=wh,dc=local id_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_uri = ldap://127.0.0.1/ ldap_tls_cacert = /certs/cacert.pem [sssd] services = nss, pam config_file_version = 2 domains = local [nss] [pam] [sudo] [autofs] [ssh] Here's my nslcd.conf: uri ldap://127.0.0.1/ base dc=wh,dc=local ssl start_tls tls_cacertfile /certs/cacert.pem tls_reqcert hard Here's my /etc/openldap/ldap.conf: TLS_CACERT /certs/cacert.pem TLS_REQCERT hard URI ldap://127.0.0.1/ BASE dc=wh,dc=local This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio Inc. makes no warranty that this email is error or virus free. Thank you.

3 2

hdb and mdb have different search results/behaviour
by Juergen.Sprenger＠swisscom.com 23 Apr '13

23 Apr '13

Hi, I have running OpenDLAP 2.4.35 on Gentoo Linux and wanted to make some tests with mdb. Slapd was running fine with hdb, no problems so far. Then I exported contents via slapcat and switched config to mdb. When slapd started using mdb no users from directory were shown by 'getent passwd': ### hdb part #### # using hdb parameters database hdb dirtyread cachesize 150000 cachefree 100 idlcachesize 450000 dncachesize 100000 # slapadd from backup and run slapd with hdb backend /etc/init.d/unscd stop /etc/init.d/slapd stop rm /var/lib/openldap-data/* rm -rf /etc/openldap/slapd.d/* cp -p /etc/openldap/DB_CONFIG /var/lib/openldap-data/ cp -p /etc/openldap/slapd.conf.hdb /etc/openldap/slapd.conf su ldap -c '/usr/sbin/slapadd -f /etc/openldap/slapd.conf -l odsldap-dev.ldif' /etc/init.d/slapd start /etc/init.d/unscd start slapcat -f /etc/openldap/slapd.conf -b dc=scom | md5sum # 73850f9a3f7ff9d3d1ddb7663cd046a6 - getent passwd # all users shown, everything ok ### mdb part #### # using mdb paramters database mdb dbnosync maxsize 2094967296 searchstack 64 # slapadd from backup and run slapd with mdb backend /etc/init.d/unscd stop /etc/init.d/slapd stop rm /var/lib/openldap-data/* rm -rf /etc/openldap/slapd.d/* cp -p /etc/openldap/slapd.conf.mdb /etc/openldap/slapd.conf su ldap -c '/usr/sbin/slapadd -f /etc/openldap/slapd.conf -l odsldap-dev.ldif' /etc/init.d/slapd start /etc/init.d/unscd start slapcat -f /etc/openldap/slapd.conf -b dc=scom | md5sum # 73850f9a3f7ff9d3d1ddb7663cd046a6 - getent passwd # no users from ldap shown Am I missing something when setting up and using mdb? Both backends have exactly the same content, and so the results for searches should also be identical. Regards Jürgen Sprenger

2 1

Re: OpenLDAP 2.4.35 available
by Clément OUDOT 23 Apr '13

23 Apr '13

2013/4/1 OpenLDAP Project <project(a)openldap.org> > OpenLDAP 2.4.35 is now available for download as detailed on our download > page: > > http://www.openldap.org/software/download/ > > and should soon be available on all official mirrors: > > ftp://ftp.openldap.org/pub/OpenLDAP/MIRRORS > > This is a maintenance release and is made available for general use. > Users of OpenLDAP Software are encouraged to upgrade. > > Hi, as usual, you can find some RPMs here: http://ltb-project.org/wiki/download#openldap Clément.

3 2

clarification on ldap with ssl/tls
by Rodney Simioni 22 Apr '13

22 Apr '13

Hi, I've been tasked to enable ssl/tls on ldap. The server already has a certificate and key file. After looking at documentation, these are the three files that are needed In the ldap.conf file: TLSCertificateFile /etc/openldap/servercrt.pem TLSCertificateKeyFile /etc/openldap/serverkey.pem TLSCACertificateFile /etc/openldap/cacert.pem I already have the TLSCertificateFile and TLSCertificateKeyFile but I don't have the TLSCACertificateFile. Is that something I have to generate? Rod This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio Inc. makes no warranty that this email is error or virus free. Thank you.

4 3

hashed credentials for idassert-bind?
by Steve Eckmann 22 Apr '13

22 Apr '13

I thought I could use something like "credentials={SSHA}/iiPJIZ2Srf+O0HqLIypyKYKccx9V6ag" with idassert-bind or acl-bind in configuring an ldap backend in slapd.conf, instead of including the cleartext password. But when I try that I get an "invalid credentials" error from the proxied Active Directory. I've carefully regenerated the hashed value with slappasswd and repasted the new value into my slapd.conf file, so I'm pretty sure that the hash is correct. Is there a right way to obfuscate passwords that will be sent to a proxied AD server? Thanks. Steve

3 4

Re: How to improve performance with MDB backend?
by Saša-Stjepan Bakša 21 Apr '13

21 Apr '13

How do you measure or compare speed? I have a Python program which add a predefined number of users (1mil and each user consists of 8 DNs and 3 alias DNs) and for Modify test I have also Python program which modify 1 attribute with random value under one DN changed sequentially from 1 to 1mil) Now I can add those 1 million of users in 5508 sec what amounts to 181,55 users per second. Modify program can do 2141,33 modifications per sec. Do you find those numbers reasonable or are they nonsense? Is there a way to get 10000 modifications per second or I am asking a stupid question? Sasa On Mon, Apr 8, 2013 at 4:40 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > --On Monday, April 08, 2013 4:49 AM -0700 Howard Chu <hyc(a)symas.com> > wrote: > > Saša-Stjepan Bakša wrote: >> >>> Hi, >>> >>> Maybe this is not the best way to ask but I would like to get some >>> performance expectations or maybe suggestions how to improve >>> performance. I do have relatively long experience with OpenLDAP as a >>> precompiled package and with much less users so performance was not an >>> issue for those installations. >>> >>> Now I need to put few million users (now one million for test), custom >>> tailored schema and search performance is crucial but also modify >>> performance is big issue. Before MDB I have used HDB as backend. >>> >>> What to do to improve write part of performance or performance in general >>> (when adding data – from time to time – OpenLDAP stalls in a way)? >>> Just around 5 add/mod operations during that time then it continue with >>> much higher speed. >>> >>> I have used many different sources to find out other peoples experience >>> and I didn't choose to write to list lightly but I really need some >>> help/hints. >>> >> >> There's nothing particular to LMDB to tune. But if you're seeing pauses >> due to disk I/O, as your iotop output seems to indicate, you might want >> to look into using a different I/O scheduler. >> > > Not quite true. On Linux, I suggest setting the olcDbFlags as follows: > > olcDbEnvFlags: writemap > olcDbEnvFlags: nometasync > > With those flags set, writes are 65x faster for me with back-mdb than they > are with back-hdb/back-bdb. > > --Quanah > > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

7 27

backsql -> slapd restart necessary?
by hornuda 21 Apr '13

21 Apr '13

Hello, I use backsql as ldap backend. Is it necessary to restart the slapd server when a new entry was written into a table (postgresql) to make this entry available in ldap? Cheers, hornuda

2 1

disabling user account
by Jignesh Patel 20 Apr '13

20 Apr '13

Does openldap has a provision like active directory to disable a user? useraccountcontrol 544 -Jignesh

6 8

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical April 2013