openldap-technical

openldap-technical@openldap.org

9804 discussions

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

LDAP password management
by Adrian Paleacu 22 Aug '12

22 Aug '12

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. regards, Adrian

2 1

Re: syncrepl not propagating changes
by Mark Coetser 22 Aug '12

22 Aug '12

On 22/08/2012 12:00, Rein Tollevik wrote: > On 22.08.12 10:46, Mark Coetser wrote: >> On 22/08/2012 10:39, Howard Chu wrote: >>> Mark Coetser wrote: >>>> >>>> on some of the consumers, I have multiple syncrepl configs so that I >>>> replicate specific subdivision data to those servers. >>> >>> That is not supported. You can only use multiple consumers in the same >>> database if they are all pointing at different providers (and each of >>> those >>> providers uses a unique serverID). >> >> Can I split them into separate databases on the consumer? Or whats the >> correct way of doing what I am trying to achieve? > > Use a single syncrepl stanza on these consumers too, replicating your > toplevel cn=company dn. Add acl's on the provider which limits the user > these consumers binds as to only see those sub-trees you wish them to see. > > Rein > Hi Please could someone confirm that these acls would be secure, I am trying to allow services like pam/nss on the provider to still function and have access to the entire tree, then allow the replica user from the consumer to see the base of the tree and the whole of the subdivision tree including userPassword,shadowLastChange, also could someone assist with an example of a regex acl that I could use to say that "cn=replica,*" has read access to everything in that users subtree? access to attrs=userPassword,shadowLastChange by dn.base="cn=admin,dc=company" write by dn.base="cn=replica,dc=subdivision,dc=company" read by anonymous auth by self write by * none access to dn.base="" by peername.regex=127\.0\.0\.1 read by * none access to dn.base="dc=company" by dn.base="cn=replica,dc=subdivision,dc=company" read access to dn.subtree="dc=subdivision,dc=company" by dn.base="cn=replica,dc=subdivision,dc=company" read access to * by dn.base="cn=admin,dc=company" write by peername.regex=127\.0\.0\.1 read by * none -- Thank you, Mark Adrian Coetser mark(a)pkfnet.co.za

1 0

Re: syncrepl not propagating changes
by Mark Coetser 22 Aug '12

22 Aug '12

1 1

Re: Query regarding the Database files..
by Howard Chu 22 Aug '12

22 Aug '12

Pierangelo Masarati wrote: >> If you build the mdb_stat program in the libmdb source (it is not built by >> default) you can use it to examine the individual MDB databases. E.g.: > > Time for a slapstat tool? Eh... We lived thru 12 years of BerkeleyDB without needing such a thing. I don't see why we should need it now. It would be useful to flesh out mdb_stat to report more interesting information, but that's a pretty low priority on my list at the moment. For completeness' sake MDB should have mdb_stat, mdb_dump, and mdb_load. Patches welcome... -- -- 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical