openldap-software March 2007

openldap-software@openldap.org

68 participants
83 discussions

RE: Ghosting Data
by Mark Mcdonald 12 Mar '07

12 Mar '07

Howard Chu <mailto:hyc@symas.com> laid ink upon scroll at Tuesday, March 13, 2007 12:55 PM: > It should, but if you don't have reasonable checkpoints set > it may take > a long time to flush the cache. If the system is actually > shutting down, > it may not wait long enough for slapd to finish. Looks like it's my checkpoint directive. I have: checkpoint 512 60 Something like 'checkpoint 256 5' seems safer, or should I aim lower still? > Note that DB_TXN_NOT_DURABLE should not be used on production servers. > This flag was deleted in BDB 4.3 and later because it is inherently > unsafe. (One of those "only use this if you know what you're doing" > options that too frequently got used by people who shouldn't have...) Sounds right :) Was DB_TXN_NOT_DURABLE just renamed to DB_LOG_INMEMORY in 4.3 or is there more to it? I understand the ideal solution is to log full transaction logs to disk and use db_archive to backup the old logs & related data but we didn't look into this in much detail as it was considered unnecessary. Obviously we're wrong about that but we can recover a failed system using one of 30 odd other identical replicas across the network or failing that rebuild from our authorative data sources relatively quickly so is it worthwhile using only auto-removed txn logs? Thanks Mark

1 0

RE: Ghosting Data
by Mark Mcdonald 12 Mar '07

12 Mar '07

Mark Mcdonald <> laid ink upon scroll at Tuesday, March 13, 2007 9:48 AM: > I'm about to take the offending server down and run slapindex > but I fear the problem is in dn2id.bdb and id2entry.bdb, > which I don't believe slapindex fixes. I believe the problem may be caused by an unclean backend database shutdown... My rationale is that DB_CONFIG uses DB_TXN_NOT_DURABLE (LDAP is not an authorative source for us and we can restore from other sources easily enough) and yet the timestamp of the database files is about 10 minutes lagging behind the time I actually shut the system down, where I would have assumed that a clean shutdown would flush memory to disk. I also got this error running slapindex after a clean shutdown (Ubuntu Edgy, /etc/init.d/slapd stop): root # su -c 'slapindex -c' openldap bdb_db_open: unclean shutdown detected; attempting recovery. => bdb_idl_insert_key: c_get failed: DB_PAGE_NOTFOUND: Requested page not found (-30988) => hdb_tool_entry_reindex: txn_aborted! Accessing a corrupted shared library (80) => bdb_idl_insert_key: c_get failed: DB_PAGE_NOTFOUND: Requested page not found (-30988) => hdb_tool_entry_reindex: txn_aborted! Accessing a corrupted shared library (80) .... etc The stop command from the above initscript is: start-stop-daemon --stop --quiet --oknodo --retry 10 \ --pidfile "$SLAPD_PIDFILE" \ --exec /usr/sbin/slapd 2>&1` Thanks Mark

2 1

Client auth to slapd TLS issues
by Philip Bellino 12 Mar '07

12 Mar '07

Hello, Running openldap -2-3-32 with SLAPD on a linux server. Also running openldap-2-3.32 on a linux client. slapd.conf includes: TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCACertificateFile /usr/local/etc/openldap/cacert.pem TLSCertificateFile /usr/local/etc/openldap/servercert.pem TLSCertificateKeyFile /usr/local/etc/openldap/newkey.pem TLSVerifyClient never (or allow) Issue1: Here is the debug output from the openldap code if the ldap.conf file has the following in it when I try authentication: TLS_CACERT cacert.pem TLS_CACERTDIR /usr/local/etc/openldap/ Login: ldapuser2 Password: *********ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP 140.179.180.135:389 ldap_new_socket: 6 ldap_prepare_socket: 6 ldap_connect_to_host: Trying 140.179.180.135:389 ldap_connect_timeout: fd: 6 tm: 5 async: 0 ldap_ndelay_on: 6 ldap_is_sock_ready: 6 ldap_ndelay_off: 6 ldap_open_defconn: successful ldap_send_server_request ldap_result ld 0x100141d0 msgid 1 ldap_chkResponseList ld 0x100141d0 msgid 1 all 1 ldap_chkResponseList returns ld 0x100141d0 NULL wait4msg ld 0x100141d0 msgid 1 (infinite timeout) wait4msg continue ld 0x100141d0 msgid 1 all 1 ** ld 0x100141d0 Connections: * host: 140.179.180.135 port: 389 (default) refcnt: 2 status: Connected last used: Thu Jul 20 09:26:37 2006 ** ld 0x100141d0 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ** ld 0x100141d0 Response Queue: Empty ldap_chkResponseList ld 0x100141d0 msgid 1 all 1 ldap_chkResponseList returns ld 0x100141d0 NULL ldap_int_select read1msg: ld 0x100141d0 msgid 1 all 1 read1msg: ld 0x100141d0 msgid 1 message type extended-result new result: res_errno: 0, res_error: <>, res_matched: <> read1msg: ld 0x100141d0 0 new referrals read1msg: mark request completed, ld 0x100141d0 msgid 1 request done: ld 0x100141d0 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_extended_result ldap_parse_result ldap_msgfree TLS: could not load verify locations (file:`cacert.pem',dir:`/usr/local/etc/openldap/'). TLS: error:02001002:system library:fopen:No such file or directory bss_file.c:104 TLS: error:2006D080:BIO routines:BIO_new_file:no such file bss_file.c:107 TLS: error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib by_file.c:274 ldap_err2string Now, that pem file "cacert.pem" is in /usr/local/etc/openldap. Can anyone tell me why I get this error? Also I thought that with "TLSVerifyClient never" that the server wouldn't even ask for the client's certificate or if "allow" it would ask but wouldn't care if it was not there or could not be verified. ************************************************************************ ************************************************************************ ***** Issue2: Here is the debug output from the openldap code if the ldap.conf file does not have the "TLS_CACERT cacert.pem" or "TLS_CACERTDIR /usr/local/etc/openldap/" in it when I try authentication: Login: ldapuser2 Password: *********ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP 140.179.169.185:389 ldap_new_socket: 6 ldap_prepare_socket: 6 ldap_connect_to_host: Trying 140.179.180.135:389 ldap_connect_timeout: fd: 6 tm: 5 async: 0 ldap_ndelay_on: 6 ldap_is_sock_ready: 6 ldap_ndelay_off: 6 ldap_open_defconn: successful ldap_send_server_request ldap_result ld 0x100141d0 msgid 1 ldap_chkResponseList ld 0x100141d0 msgid 1 all 1 ldap_chkResponseList returns ld 0x100141d0 NULL wait4msg ld 0x100141d0 msgid 1 (infinite timeout) wait4msg continue ld 0x100141d0 msgid 1 all 1 ** ld 0x100141d0 Connections: * host: 140.179.180.135 port: 389 (default) refcnt: 2 status: Connected last used: Thu Jul 20 10:05:12 2006 ** ld 0x100141d0 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ** ld 0x100141d0 Response Queue: Empty ldap_chkResponseList ld 0x100141d0 msgid 1 all 1 ldap_chkResponseList returns ld 0x100141d0 NULL ldap_int_select read1msg: ld 0x100141d0 msgid 1 all 1 read1msg: ld 0x100141d0 msgid 1 message type extended-result new result: res_errno: 0, res_error: <>, res_matched: <> read1msg: ld 0x100141d0 0 new referrals read1msg: mark request completed, ld 0x100141d0 msgid 1 request done: ld 0x100141d0 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_extended_result ldap_parse_result ldap_msgfree TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 0, err: 20, subject: /C=US/ST=Massachusetts/L=Littleton/O=MRV Inc/OU=Engineering/CN=DerJer/emailAddress=pino(a)mrv.com, issuer: /C=US/ST=Massachusetts/L=Littleton/O=MRV Inc/OU=Engineering/CN=DerJer/emailAddress=pino(a)mrv.com TLS certificate verification: Error, unable to get local issuer certificate TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS: can't connect. ldap_err2string I guess my question here is similar to the above. If TLSVerifyClient is set to never or allow, I get the above error. Can anyone tell me why I get this error? Any help would be most appreciated. Thanks, Phil Bellino ============================ Phil Bellino MRV Communications, Inc. Boston Product Division 295 Foster St. Littleton,MA 01460 Tel: (978)952-4807 Email: pbellino(a)mrv.com ============================

2 1

RE: Ghosting Data
by Mark Mcdonald 12 Mar '07

12 Mar '07

This seems related: root # ldapsearch [blah] -b ou=623392770,ou=section1,o=base dn # extended LDIF # # LDAPv3 # base <ou=623392770,ou=section1,o=base> with scope subtree # filter: (objectclass=*) # requesting: dn # # 621588406, section2, base dn: cn=621588406,ou=section2,o=base # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Note the completely different DNs. Searching with the base set to the DN returned above returns no results, but searching on one of the attributes (ie. cn=621588406, as below) returns 5 copies of the same entry. Any ideas? I'm about to take the offending server down and run slapindex but I fear the problem is in dn2id.bdb and id2entry.bdb, which I don't believe slapindex fixes. Mark Mcdonald <> laid ink upon scroll at Monday, March 12, 2007 2:57 PM: > I was wondering if anyone has seen anything like this before: > > root# ldapsearch [blah] 'cn=username' dn cn > > # extended LDIF > # > # LDAPv3 > # base <ou=people,o=base> with scope subtree > # filter: cn=username > # requesting: dn cn > # > > # username, people, base > dn: cn=username,ou=people,o=base > cn: username > > # username, people, base > dn: cn=username,ou=people,o=base > cn: username > > # username, people, base > dn: cn=username,ou=people,o=base > cn: username > > # username, people, base > dn: cn=username,ou=people,o=base > cn: username > > # search result > search: 2 > result: 0 Success > > # numResponses: 5 > # numEntries: 4 > > > Then when I try to delete the entry: > > root # ldapdelete > Enter LDAP Password: > cn=username,ou=people,o=base > ldap_delete: No such object (32) > matched DN: ou=people,o=base > > I haven't tried doing restarting slapd or the usual > db_recover stuff yet as it's not causing a problem (yet). Is > it symptomatic of a known issue? > > slapd 2.3.30 > back-hdb > Built against db 4.2.52 (standard Ubuntu Edgy package) > > Thanks > Mark

2 1

Re: slapd-sql with unixodbc - userCertificate retrieval problem
by Pierangelo Masarati 12 Mar '07

12 Mar '07

Kevin Vargo wrote: > I've uploaded: > openldap-2.3.32-kv1-patch_support-binary-attr-070312.tgz I insist: thanks for the contribution, but you need to go through the ITS (follow instructions at <http://www.openldap.org/its/> if you want your patch to be considered. Otherwise, there is no means to keep track of it. It looks interesting; without testing it I cannot say it is correct, and it appears that you do something nasty with data that is intended to be read-only (the cname of the attribute description you're mucking with). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: LDAP/BDB log purging
by Tony Earnshaw 12 Mar '07

12 Mar '07

Jeff Saxton wrote, on 10. mar 2007 08:18: [...] >> Do try *not* to use source-compiled db4 (in your case 4.5.20) on >> RHAS/RHEL, as it installs to non-standard (non-FHS) directories and will >> get you into all kinds of a mess later. As a pointer, try never to >> install non-rpm software on RHAS/RHEL, this after 4-5 years as Red Hat >> administrator and having done it all myself, earlier ;) >> > > Wow! I've only been a sysadmin for > 205yrs and using RedHat since 6.2 > and I never have trouble compiling from source. It's not compiling from source that's the problem, its stuffing libs and includes/headers into different directories from other similar on the *Red Hat RHEL/RHAS* system. Further, it's ok compiling and installing from source on one machine, but as soon as one has to install on multiple systems of the same type, you are costing whoever it is that's paying you far too much and involving yourself in a lot of unnecessary hassle. > If you need help meby I could give you a couple of pointers ;) From a sysadmin who's been dead for more than 100 years and couldn't spell when he was alive? Installing from packages where details of all packages are kept in a database gives gives many huge advantages, this is recognized by most, if not all, major OS vendors. I, too, was once too lazy (or ignorant) to learn to build my own program packages where I couldn't beg, borrow or steal others'. Well, now I can. --Tonni -- Tony Earnshaw Email: tonni at hetnet dot nl

3 2

How to restrict user authentication in ldapsearch ?
by JOYDEEP 12 Mar '07

12 Mar '07

Dear list, I can even query about an user as a different user. plese see below ldapsearch -H ldaps:// -u "uid=anupam" -x -W -D "uid=aftab,ou=Users,dc=kolkatainfoservices,dc=in" Here I can query about anupam as aftab. How can I restrict this ? thanks

1 0

[ldapsearch -H ldaps:// -d 255] is not working
by JOYDEEP 11 Mar '07

11 Mar '07

Dear list, I am using openldap2-2.3.19-18 under suse 10.1 and it is wotking fine at port 389 ( ldap://) Now to secure it with ssl, I have first generated a certificate with Ca.sh script comes with linux. then I have modified my /etc/openldap/slapd.conf as ========================================= TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCertificateFile /etc/openldap/myca/servercert.pem TLSCertificateKeyFile /etc/openldap/myca/serverkey.pem TLSCACertificateFile /etc/openldap/myca/cacert.pem TLSVerifyClient never ========================================= I also modified /etc/openldap/ldap.conf as ================================= HOST 127.0.0.1:636 BASE ou=Users,dc=kolkatainfoservices,dc=in TLS_CACERT /etc/openldap/myca/cacert.pem ================================= now when I execute *ldapsearch -H ldaps:// -d 255* it asks for ====================== ldap_msgfree sasl_client_step: 2 Please enter your password: ====================== after giving the manager password which is seceret it reports ========================== ldap_msgfree ldap_perror ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): user not found: no secret in database ============================================ could any one suggest what am I missing here ? thanks.

5 9

Ghosting Data
by Mark Mcdonald 11 Mar '07

11 Mar '07

I was wondering if anyone has seen anything like this before: root# ldapsearch [blah] 'cn=username' dn cn # extended LDIF # # LDAPv3 # base <ou=people,o=base> with scope subtree # filter: cn=username # requesting: dn cn # # username, people, base dn: cn=username,ou=people,o=base cn: username # username, people, base dn: cn=username,ou=people,o=base cn: username # username, people, base dn: cn=username,ou=people,o=base cn: username # username, people, base dn: cn=username,ou=people,o=base cn: username # search result search: 2 result: 0 Success # numResponses: 5 # numEntries: 4 Then when I try to delete the entry: root # ldapdelete Enter LDAP Password: cn=username,ou=people,o=base ldap_delete: No such object (32) matched DN: ou=people,o=base I haven't tried doing restarting slapd or the usual db_recover stuff yet as it's not causing a problem (yet). Is it symptomatic of a known issue? slapd 2.3.30 back-hdb Built against db 4.2.52 (standard Ubuntu Edgy package) Thanks Mark

1 0

LDAP/BDB log purging
by Lesley Walker 11 Mar '07

11 Mar '07

Running openldap 2.3.32 with bdb 4.2 (and using syncrepl if that's relevant). I need to deal with the issue of how to safely delete old bdb log files on our many replicas. In a previous thread, Aaron Richton wrote: > I'd recommend DB_LOG_AUTOREMOVE. Barring that, you can run db_archive > manually. Check Sleepycat docs for details on either. Well, I just ran db_archive and caused widespread chaos because most (all?) of the replicas stopped responding to queries. (I have yet to perform a post-mortem) I know that there's a bug in bdb 4.2 that causes logs to be held open even though they're no longer required. Upgrading bdb is not on the cards right now so I need to work around that problem by stopping and starting openldap. So the question I have just at the moment is, when I run db_archive, should openldap be running or not running? I've seen nothing in any docs that suggest it should be stopped, and the bdb docs simply imply that applications are expected to be running (but I'm not a programmer so my I interpreted it wrongly). So I ran db_archive just after starting openldap. Was that the wrong thing to do, and is it an obvious cause for the meltdown? Cheers, Lesley W -- Lesley Walker Linux Systems Administrator Opus International Consultants Ltd Email lesley.walker(a)opus.co.nz Tel +64 4 471 7002, Fax +64 4 473 3017 http://www.opus.co.nz Level 9 Majestic Centre, 100 Willis Street, PO Box 12 343 Wellington, New Zealand

8 23

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software March 2007