openldap-technical

openldap-technical@openldap.org

4 participants
9898 discussions

BDB: Converting mmapped files to shared memory: Need slap{cat,add}?
by Nick Urbanik 27 Aug '12

27 Aug '12

Dear Folks, I have a large production 2.4.32 LDAP server slaving many trees. I set it up with memory-mapped files, and want to change it to use shared memory instead, since shared memory BDB seems to work better after watching the other servers that have been upgraded 2.3 => 2.4.32 with shared memory. To convert this, do I need to slapcat the directories and restore them after the configuration change with slapadd, or is it sufficient to use db_recover in each LDAP database after changing the configuration while slapd is stopped? -- Nick Urbanik http://nicku.org 808-71011 nick.urbanik(a)optusnet.com.au GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24 I disclaim, therefore I am.

3 3

mdb database protected against any power cut?
by Francois Gnu 25 Aug '12

25 Aug '12

Hello @ll! Is the mdb database protected against any power cut? Is the mechanism of recovery mdb database working fine? Thank you very much Librement, ------ Francois Trachez (kiko) Team Fedora|Lyon (France) http://stg.fedoraproject.org/fr/ http://stg.fedoraproject.org/es/

3 5

Re: OpenLDAP 2.4.32 available
by Clément OUDOT 24 Aug '12

24 Aug '12

2012/7/31 OpenLDAP Project <project(a)openldap.org>: > OpenLDAP 2.4.32 is now available for download as detailed on our download page: > > http://www.openldap.org/software/download/ Hi, you can find some RPMs here: http://ltb-project.org/wiki/download#openldap Clément OUDOT

1 0

Performance of MDB and BDB Please suggest?
by aryan rawat 24 Aug '12

24 Aug '12

Hi, I am working on Open-Ldap for one of my application and I was testing to find out which DB is FAST MDB or BDB for ldapsearch. Tested both the DB’s on same platform for .6 Million records. Configuration Done for BDB (openldap2.4.24) MDB (openldap2.4.32) Slapd.conf database hdb threads 32 Slapd.conf database mdb threads 32 maxsize 2147483648 DB_CONFIG set_cachesize 2 0 1 To test the same developed a java tool to send a bulk search request on Open Ldap for both the DB’s. Pumping the load for 400,500,1000,2000,2500 etc.. search request to openldap. *The outcome was BDB was almost 8 time faster than MDB. * To my surprise it was written that for search MDB is faster than BDB. Please suggest if I have done some wrong configuration in MDB.. BR's, Haroon

3 3

compiled the Openldap 2.4.32 with these setting are they the Best..
by aryan rawat 24 Aug '12

24 Aug '12

Hi , I have compiled the Openldap 2.4.32 with these options for MDB ./configure --prefix=/root/haroon/openldap/new1 --enable-debug=yes --enable-bdb=no --enable-hdb=no --enable-mdb=yes --with-cyrus-sasl --with-threads --with-tls=openssl CC="gcc" LDFLAGS="-L/usr/lib64/sasl2" CPPFLAGS="-I/usr/include/sasl" Are they the best setting or I need to set some thing different. BR's, Haroon

1 0

representing file pathnames
by Chuck Lever 23 Aug '12

23 Aug '12

Hi- (Sorry for the length, it's a pretty wonky problem). I'm working with the IETF NFSv4 working group on a schema for storing file system referral information in LDAP, as part of the FedFS standard (RFC 5716). I'm looking for some opinions about certain details of the schema. A "referral" is a file server response that conveys a table of file server hostname and export pathname pairs that are replicas of the local file set on that file server. When a referral is encountered, a file system client chooses a row from this table and mounts that export automatically as it continues to traverse the file system name space. Referrals are a standard part of both the NFSv4 and SMB protocols. FedFS provides a standard way to store these rows in an LDAP database. Each row is contained in a single LDAP record, called a File Set Location record. A group of these records that live under the same parent record is retrieved by a file server to generate the table in a referral response. Today an FSL record for an NFS referral contains among other things a UTF-8 string server hostname, an integer port number, and a binary blob containing an XDR-marshalled representation of the export pathname. Note that both the pathname components and hostname are represented in UTF-8 in the NFS protocol, which is why they are stored as UTF-8 in LDAP. XDR was chosen because the file server doesn't have to alter the pathname data it reads from the LDAP server; it can just turn it around and send it immediately on to NFS clients. The pathname's components are UTF-8 strings. The pathname is expressed as an ordered variable-length list of these strings. The pathname separator is not stored in the XDR blob, since physical file systems can use different characters for this purpose (HFS+ on Mac OS uses ":", POSIX uses "/", and Windows uses "\"). NFS typically performs single component lookups on the wire, so NFS clients are never concerned with how a file server might separate its pathname components. The downside of using a binary XDR blob is that it's not observable or editable via typical LDAP tools. Plus, ewww. It's been suggested that we use a file URL to represent export pathnames. A file URL is expressed in US-ASCII with escaping, and the pathname separator is stored in the string. A file URL also has the ability to store a hostname. "file://hostname/path/to/some/file" I'm not sure this is the best fit for our purpose. We're especially concerned about some of the complexities of converting escaped US-ASCII to UTF-8, and the use of a fixed pathname separator character. Can we represent the full range of the UTF-8 code set with a US-ASCII file URL? We could also use an NFS URL, which would allow us to express the server hostname, a port number, and the pathname in a single string. But both the hostname and pathname are enocded in US-ASCII, not UTF-8, and the NFS URL format employs a fixed pathname separator character. An alternative we have considered would store the pathname in a single-valued UTF-8 string attribute, including pathname separators, but also store the pathname separator character in a separate attribute. A simple escaping mechanism would be used to represent a separator character embedded in a component. We'd like to have a schema that represents referral data in a way that is considered natural for LDAP, can store the full richness that an NFS referral is capable of, and is easy to access and update with typical LDAP client tools like ldapmodify. Are there other ideas we haven't considered? What is a practical way to store an ordered variable-length list of strings in an LDAP attribute? Is there a similar CIFS URL format that might be used to store SMB share information? Thanks very much for your consideration. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com

3 6

openldap 2.4.23 hangs
by rwsmith＠bislink.net 22 Aug '12

22 Aug '12

Hi, Not sure if I should post this here or with the CentOS mailing list (I am hoping they are monitoring this). I am using a stock CentOS 6.3 32-bit installation with # rpm -qa | grep openldap openldap-devel-2.4.23-26.el6_3.2.i686 openldap-2.4.23-26.el6_3.2.i686 openldap-clients-2.4.23-26.el6_3.2.i686 openldap-servers-2.4.23-26.el6_3.2.i686 I have a 4-way multi-master sync replication set up on four virtual servers using Citrix XenServer 6.2. I am also running Samba 3.5.10 as a PDC on one machine and BDC on the other three. All servers are also running sssd-1.8.0 for the Linux authentication. The problem is that one or more of the LDAP servers will hang, usually the one that acts as the PDC, since this is hit the hardest and is the more critical of the four. Usually but not always the "hang" will trickle to the other servers--usually when I am not watching during the middle of the night. Fortunately we are not yet in full production. Compiling from source is not yet an option. I must use the stock RPMs from CentOS per our design guidelines. LDAP will appear to hang but what appears to be happening is that only the listener becomes busy and will not get out this state. Here is a short pull of the logs that I am collecting: Aug 14 20:34:44 auth-us slapd[10357]: daemon: read active on 69 Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0 tvp=zero Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0 tvp=zero Aug 14 20:34:44 auth-us slapd[10357]: conn=1742 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Aug 14 20:34:44 auth-us slapd[10357]: conn=1742 op=0 STARTTLS Aug 14 20:34:44 auth-us slapd[10357]: conn=1742 op=0 RESULT oid= err=0 text= Aug 14 20:34:44 auth-us slapd[10357]: daemon: activity on 1 descriptor Aug 14 20:34:44 auth-us slapd[10357]: daemon: activity on: Aug 14 20:34:44 auth-us slapd[10357]: Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0 tvp=zero Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0 tvp=zero Aug 14 20:34:44 auth-us slapd[10357]: daemon: activity on 1 descriptor Aug 14 20:34:44 auth-us slapd[10357]: daemon: activity on: Aug 14 20:34:44 auth-us slapd[10357]: 69r Aug 14 20:34:44 auth-us slapd[10357]: Aug 14 20:34:44 auth-us slapd[10357]: daemon: read active on 69 Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0 tvp=zero Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0 tvp=zero Aug 14 20:34:46 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0 tvp=zero Aug 14 20:34:46 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0 tvp=zero Aug 14 20:34:51 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0 tvp=zero Aug 14 20:34:51 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0 tvp=zero Aug 14 20:34:54 auth-us slapd[10357]: daemon: activity on 1 descriptor Aug 14 20:34:54 auth-us slapd[10357]: daemon: activity on: Aug 14 20:34:54 auth-us slapd[10357]: 39r Aug 14 20:34:54 auth-us slapd[10357]: Aug 14 20:34:54 auth-us slapd[10357]: daemon: read active on 39 Aug 14 20:34:54 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0 tvp=zero Aug 14 20:34:54 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0 tvp=zero Aug 14 20:34:54 auth-us slapd[10357]: daemon: activity on 1 descriptor Aug 14 20:34:54 auth-us slapd[10357]: daemon: activity on: Aug 14 20:34:54 auth-us slapd[10357]: Aug 14 20:34:54 auth-us slapd[10357]: daemon: epoll: listen=7 busy Aug 14 20:34:54 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0 tvp=zero Aug 14 20:34:56 auth-us slapd[10357]: daemon: epoll: listen=7 busy Aug 14 20:34:56 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0 tvp=zero Aug 14 20:35:01 auth-us slapd[10357]: daemon: epoll: listen=7 busy Aug 14 20:35:01 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0 tvp=zero Aug 14 20:35:06 auth-us slapd[10357]: daemon: epoll: listen=7 busy Aug 14 20:35:06 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0 tvp=zero Aug 14 20:35:11 auth-us slapd[10357]: daemon: epoll: listen=7 busy Aug 14 20:35:11 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0 tvp=zero Aug 14 20:35:12 auth-us slapd[10357]: daemon: activity on 1 descriptor Aug 14 20:35:12 auth-us slapd[10357]: daemon: activity on: Aug 14 20:35:12 auth-us slapd[10357]: 42r Aug 14 20:35:12 auth-us slapd[10357]: Aug 14 20:35:12 auth-us slapd[10357]: daemon: read active on 42 Aug 14 20:35:12 auth-us slapd[10357]: daemon: epoll: listen=7 busy Aug 14 20:35:12 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0 tvp=zero Aug 14 20:35:14 auth-us slapd[10357]: daemon: activity on 1 descriptor Aug 14 20:35:14 auth-us slapd[10357]: daemon: activity on: Aug 14 20:35:14 auth-us slapd[10357]: 40r Aug 14 20:35:14 auth-us slapd[10357]: Aug 14 20:35:14 auth-us slapd[10357]: daemon: read active on 40 Aug 14 20:35:14 auth-us slapd[10357]: daemon: epoll: listen=7 busy Aug 14 20:35:14 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0 tvp=zero Aug 14 20:35:16 auth-us slapd[10357]: daemon: epoll: listen=7 busy Aug 14 20:35:16 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0 tvp=zero Aug 14 20:35:21 auth-us slapd[10357]: daemon: epoll: listen=7 busy Aug 14 20:35:21 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0 tvp=zero Aug 14 20:35:26 auth-us slapd[10357]: daemon: epoll: listen=7 busy Aug 14 20:35:26 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0 tvp=zero Aug 14 20:35:31 auth-us slapd[10357]: daemon: epoll: listen=7 busy Aug 14 20:35:31 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0 tvp=zero Every log entry prior to this looks normal in that epoll: listen=7 goes between active_threads=0 to busy when a connection comes in, sets up the connection, and then goes back to active_threads=0. I have yet to understand what is going on to cause it to go into the busy state and never to return until I manually stop and restart the slapd process. It does appear however that slapd can still process any queries on active connections as noted on descriptors 40r and 42r--it just can't process any new connection requests as epoll: listen=7 has hung. Looking through the archives this problem still appears to be present in a few additional later releases but I have not found any thread yet which points to a specific solution or patch that fixes this problem. Unless I can point to a specific solution and/or patch I won't get approval to do a pull from the latest source and compile--I'll have to stick with an hourly cron job that stops and restart slapd. Thanks, Bob Smith --bs

4 4

Re: slapd-meta doesn't continue with multiple uri's
by Liam Gretton 22 Aug '12

22 Aug '12

On 22/08/2012 09:44, Pierangelo Masarati wrote: >> My fault: "timeout" is operation-wide; when it's hit, the >> operation ends as you reported. "network-timeout" is related to >> connect(2) only. As far as I understand, by looking at the code, >> there is no practical means, so far, to perform what you're asking >> for. Either the connection cannot be established, and in this case >> the code works as intended, or if it hangs for ever the operation >> can only be aborted/timed out. In those cases, you definitely need >> to fix the configuration by removing the hung URI. But what's the point of specifying multiple targets in the uri option if it doesn't fall through to subsequent ones when the first is not contactable? Have I completely missed the point of the documentation? -- Liam Gretton liam.gretton(a)le.ac.uk HPC Architect http://www.le.ac.uk/its/ IT Services Tel: +44 (0)116 2522254 University Of Leicester, University Road Leicestershire LE1 7RH, United Kingdom

1 0

Re: LDAP password management
by Dan White 22 Aug '12

22 Aug '12

On 08/22/12 19:43 +0300, Adrian Paleacu wrote: >Hi Dan, > >Thank you for quick response. So is not possible to inform LDAP service >that an already hashed password is passed trough. You can accomplish hashing of your password, over the network, by binding with SASL. Depending on the mechanism you use, doing so will require you to store your passwords in cleartext on the server. See: http://www.cyrussasl.org/docs/cyrus-sasl/2.1.25/mechanisms.php OTP and SRP do not require storing your password in cleartext. In any case, if your desire is to secure the transmission of your password, the use of TLS is recommended. If you're asking how to handle the case where you're transitioning to an ldap based authentication scheme from a hashed password store (such as /etc/shadow), see the manpage for crypt(3), and prepend your hashes with {CRYPT} before storing them within slapd. >On Wed, Aug 22, 2012 at 6:06 PM, Dan White <dwhite(a)olp.net> wrote: > >> On 08/22/12 17:48 +0300, Adrian Paleacu wrote: >> >>> Hi everyone, >>> >>> I have a binding question regarding the password. Is possible to send a >>> hashed password to LDAP system. My passwords are hashed and I don't have a >>> way to send it as plain text. >>> >> >> See Section 14.4 of the OpenLDAP Administrator's guide. >> >> If your passwords are stored on your server in certain hashed forms, then >> slapd will expect you to transmit a cleartext password to be hashed and >> locally compared with the stored password value. -- Dan White

1 0

syncrepl not propagating changes
by Mark Coetser 22 Aug '12

22 Aug '12

Hi current version of openldap 2.4.23-7.2 I have however built and used 2.4.31 with the same results. I have a single provider that has multiple domians ie dc=company dc=subdivision1,dc=company dc=subdivision2,dc=company on some of the consumers, I have a single syncrepl config with the base, so these servers have all the users and replication tends to work fine. olcSyncrepl: {0} rid=00x provider=ldaps://x.x.x.x bindmethod=simple binddn="cn=replica,dc=repl_config,dc=company" credentials="xxxxx" filter="(objectclass=*)" searchbase="dc=company" scope=sub attrs="*,+" schemachecking=off type=refreshAndPersist retry="5 5 300 +" starttls=yes tls_reqcert=never tls_cert=/etc/ldap/ssl/ca-cert.pem tls_key=/etc/ldap/ssl/keys/ca-key.pem on some of the consumers, I have multiple syncrepl configs so that I replicate specific subdivision data to those servers. olcSyncrepl: {0} rid=001 provider=ldaps://x.x.x.x bindmethod=simple binddn="cn=replica,dc=repl_config,dc=company" credentials="xxxxx" filter="(objectclass=*)" searchbase="dc=company" scope=base attrs="*,+" schemachecking=off type=refreshAndPersist retry="5 5 300 +" starttls=yes tls_reqcert=never tls_cert=/etc/ldap/ssl/ca-cert.pem tls_key=/etc/ldap/ssl/keys/ca-key.pem olcSyncrepl: {1} rid=002 provider=ldaps://x.x.x.x bindmethod=simple binddn="cn=replica,dc=repl_config,dc=company" credentials="xxxxx" filter="(objectclass=*)" searchbase="dc=repl_config,dc=company" scope=base attrs="*,+" schemachecking=off type=refreshAndPersist retry="5 5 300 +" starttls=yes tls_reqcert=never tls_cert=/etc/ldap/ssl/ca-cert.pem tls_key=/etc/ldap/ssl/keys/ca-key.pem olcSyncrepl: {2} rid=002 provider=ldaps://x.x.x.x bindmethod=simple binddn="cn=replica,dc=repl_config,dc=company" credentials="xxxxx" filter="(objectclass=*)" searchbase="dc=subdivision,dc=company" scope=base attrs="*,+" schemachecking=off type=refreshAndPersist retry="5 5 300 +" starttls=yes tls_reqcert=never tls_cert=/etc/ldap/ssl/ca-cert.pem tls_key=/etc/ldap/ssl/keys/ca-key.pem whats happening with these consumers is that the initial sync seems to work and some changes to the provider do make it down to the consumer but lately most changes are NOT making it down to the consumer, when I log sync then I am seeing that the csn is committed for the change for the first rid but then for the next rid it logs that the csn is too old? Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=080 LDAP_RES_INTERMEDIATE - NEW_COOKIE Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=080 NEW_COOKIE: rid=080,csn=20120822075659.107448Z#000000#000#000000 Aug 22 09:56:59 fw1 slapd[30938]: slap_queue_csn: queing 0xb4230120 20120822075659.107448Z#000000#000#000000 Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=082 LDAP_RES_INTERMEDIATE - NEW_COOKIE Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=082 NEW_COOKIE: rid=082,csn=20120822075659.107448Z#000000#000#000000 Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=081 LDAP_RES_INTERMEDIATE - NEW_COOKIE Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=081 NEW_COOKIE: rid=081,csn=20120822075659.107448Z#000000#000#000000 Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=083 cookie=rid=083,csn=20120822075659.107448Z#000000#000#000000 Aug 22 09:56:59 fw1 slapd[30938]: slap_graduate_commit_csn: removing 0xb422e830 20120822075659.107448Z#000000#000#000000 Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=082 LDAP_RES_INTERMEDIATE - NEW_COOKIE Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=083 CSN too old, ignoring 20120822075659.107448Z#000000#000#000000 Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=082 NEW_COOKIE: rid=082,csn=20120822075659.112753Z#000000#000#000000 Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=081 LDAP_RES_INTERMEDIATE - NEW_COOKIE Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=081 NEW_COOKIE: rid=081,csn=20120822075659.112753Z#000000#000#000000 Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=080 LDAP_RES_INTERMEDIATE - NEW_COOKIE Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=080 NEW_COOKIE: rid=080,csn=20120822075659.112753Z#000000#000#000000 Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=083 cookie=rid=083,csn=20120822075659.112753Z#000000#000#000000 Aug 22 09:56:59 fw1 slapd[30938]: slap_queue_csn: queing 0xb4f11d20 20120822075659.112753Z#000000#000#000000 Aug 22 09:56:59 fw1 slapd[30938]: slap_graduate_commit_csn: removing 0xb4f18508 20120822075659.112753Z#000000#000#000000 Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=083 CSN too old, ignoring 20120822075659.112753Z#000000#000#000000 -- Thank you, Mark Adrian Coetser mark(a)pkfnet.co.za

3 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical