openldap-software February 2009

openldap-software@openldap.org

48 participants
51 discussions

Re[2]: 2.4.13 slapacl strange behavior
by Irina Shetuhina 05 Feb '09

05 Feb '09

Hi. > --On Tuesday, February 03, 2009 4:32 PM +0300 Dmitriy Kirhlarov > <dimma(a)higis.ru> wrote: >> Hi, list. >> >> We are upgrade our openldap installation to 2.4.13 with Berkley DB 47. >> We use mirror mode on two openldap servers. >> >> Now we have strange behavior of slapacl (it's look like ITS#3622 issue). >> >> $ sudo slapacl -b o=vega -D cn=ldapadm,o=vega >> always return correct data. >> >> $ sudo slapacl -b o=vega -D uid=dkirhlarov,ou=users,o=vega >> >> after that, database o=vega corrupted: > Are you running slapacl while slapd is running? Yes, slapd was running. > --Quanah > -- > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration -- Irina Shetukhina

2 1

Initializing cn=config from existing multi-master setup via syncrepl - "new entry is older than ours"
by Jonathan Clarke 05 Feb '09

05 Feb '09

Hi all, We have setup a couple of servers in N-way multimaster config, using back-config, as explained in the admin guide. These all use RE24, checked out today. We are now trying to add another server to the existing cluster. To do this, we want to replicate the existing cn=config branch from the cluster, to initialize the config for the new server. To do this, we start the new server with a minimal cn=config branch, making it a syncrepl consumer to an existing server (consumer only, no multimaster on this new server): 8<------------ dn: cn=config objectClass: olcGlobal cn: config olcServerID: 2 olcLogLevel: sync stats dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootPW: secret olcSyncRepl: rid=001 provider=ldap://server1/ binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=3 8<------------ Then, we start the server with slapd -c "rid=001,csn=0" to force a full reload. This successfully loads the config branch from the master, *except* entries that already existed in the new server's config branch. These produce the following errors: 8<------------ Feb 3 18:22:43 server2 slapd[12893]: @(#) $OpenLDAP: slapd 2.4.X (Feb 3 2009 12:10:46) $ root@server2.test.lan:/root/sources/openldap-cvs-re24/servers/slapd Feb 3 18:22:43 server2 slapd[12894]: slap_queue_csn: queing 0x194e31f0 20090203172243.314729Z#000000#002#000000 Feb 3 18:22:43 server2 slapd[12894]: slap_graduate_commit_csn: removing 0x194e3930 20090203172243.314729Z#000000#002#000000 Feb 3 18:22:43 server2 slapd[12894]: slapd starting Feb 3 18:22:43 server2 slapd[12894]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Feb 3 18:22:43 server2 slapd[12894]: syncrepl_entry: rid=001 inserted UUID 31cda500-29ca-4bf8-bc53-253af0021b21 Feb 3 18:22:43 server2 slapd[12894]: syncrepl_entry: rid=001 be_search (0) Feb 3 18:22:43 server2 slapd[12894]: syncrepl_entry: rid=001 cn=config Feb 3 18:22:43 server2 slapd[12894]: syncrepl_entry: rid=001 be_add (68) Feb 3 18:22:43 server2 slapd[12894]: dn_callback : new entry is older than ours cn=config ours 20090203172228.809275Z#000000#000#000000, new 20090203165238.611891Z#000000#001#000000 Feb 3 18:22:43 server2 slapd[12894]: syncrepl_entry: rid=001 entry unchanged, ignored (cn=config) 8<------------ Only four entries are in this case: - cn=config - cn=schema,cn=config - olcDatabase={-1}frontend,cn=config - olcDatabase={0}config,cn=config How can we force syncrepl to overwrite these entries? Any hints, or advice would be most appreciated. Regards, Jonathan

3 4

GSSAPI and LVS Load balanced ldap servers
by Francis Swasey 03 Feb '09

03 Feb '09

We've finally reached the point in replacing our old authentication system that I'm attempting to get GSSAPI working with our ldap.uvm.edu system. We have five systems that are behind the LVS (Linux Virtual System) load balancer. I've got GSSAPI partially working. As long as I use the real name of the servers, ldapwhoami will return the correct information. However, when I try to use the load balanced name (ldap.uvm.edu), then the ldapwhoami fails with the following: $ ldapwhoami -H ldap://ldap.uvm.edu SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) and what I find in syslog on the server that got the traffic is: SASL [conn=864335] Failure: GSSAPI Error: Miscellaneous failure (Wrong principal in request) conn=864335 op=1 RESULT tag=97 err=49 text=SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context Our DNS is configured so that ldap.uvm.edu is 132.198.101.196, the PTR for that returns vip1.uvm.edu (which also forward resolves to 132.198.101.196). I have set the KRB5_KTNAME environment variable to /etc/openldap/ldap.keytab, which contains the following keys ldap/<realname>.uvm.edu -- this is the real name of each of the five servers ldap/ldap.uvm.edu -- which I assume is extraneous ldap/vip1.uvm.edu The /etc/krb5.keytab holds keys for host/<realname>.uvm.edu, host/ldap.uvm.edu, and host/vip1.uvm.edu. Again, I assume that the entry for host/ldap.uvm.edu is extraneous. As I'm running on Linux, the 132.198.101.196 address is attached to the loopback interface on each of the ldap servers. Slapd is listening on 0.0.0.0:389 and 0.0.0.0:636. I'm using OpenLDAP 2.3.43 and (Red Hat's) cyrus-sasl-2.1.19-14 package. Is this a stupid configuration problem that I've somehow missed in the documentation, a bug that Red Hat hasn't back-ported in cyrus-sasl, or something else? Thanks, -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900)

5 7

2.4.13 slapacl strange behavior
by Dmitriy Kirhlarov 03 Feb '09

03 Feb '09

Hi, list. We are upgrade our openldap installation to 2.4.13 with Berkley DB 47. We use mirror mode on two openldap servers. Now we have strange behavior of slapacl (it's look like ITS#3622 issue). $ sudo slapacl -b o=vega -D cn=ldapadm,o=vega always return correct data. $ sudo slapacl -b o=vega -D uid=dkirhlarov,ou=users,o=vega authcDN: "uid=dkirhlarov,ou=users,o=vega" entry: write(=wrscxd) children: write(=wrscxd) objectClass=organization: write(=wrscxd) o=vega: write(=wrscxd) structuralObjectClass=organization: write(=wrscxd) entryUUID=0e0b8986-9cc3-102b-96f3-3bcca1c2be14: write(=wrscxd) creatorsName=cn=ldapadm,o=vega: write(=wrscxd) createTimestamp=20070522151544Z: write(=wrscxd) description=Vega Enterprise: write(=wrscxd) entryCSN=20081118152239.589172Z#000000#001#000000: write(=wrscxd) modifiersName=uid=dkirhlarov,ou=users,o=vega: write(=wrscxd) modifyTimestamp=20081118152239Z: write(=wrscxd) contextCSN=20080919162319.000000Z#000000#000#000000: write(=wrscxd) contextCSN=20090203122647.662600Z#000000#002#000000: write(=wrscxd) contextCSN=20090203123435.986113Z#000000#001#000000: write(=wrscxd) bdb(o=vega): Error: closing the transaction region with active transactions bdb_db_close: database "o=vega": close failed: Invalid argument (22) after that, database o=vega corrupted: $ sudo slapacl -b o=vega -D cn=ldapadm,o=vega hdb_db_open: database "o=vega": unclean shutdown detected; attempting recovery. hdb_db_open: database "o=vega": recovery skipped in read-only mode. Run manual recovery if errors are encountered. hdb_db_open: database "o=vega": alock_recover failed bdb_db_close: database "o=vega": alock_close failed backend_startup_one: bi_db_open failed! (-1) slap_startup failed slapd restart fix a problem. Could somebody, please, reproduce this issue and comment it? Our system: $ uname -rs; pkg_info -Ix openldap-serv FreeBSD 7.1-amd64-20090114-RELENG_7_1 openldap-server-2.4.13 Open source LDAP server implementation WBR. Dmitriy

4 5

stable version 2.3
by Lise Didillon 03 Feb '09

03 Feb '09

hello, As I have sometimes slapd freezes in openldap version 2.3.19 with BDB 4.2.52 , I would like to upgrade the openldap package but in 2.3 version. So I would like to know what is the release number considered as stable in 2.3 version of openldap (is it the 2.3.43 version?) I see in the mailing list to try 2.3.20 but certainly it's better to take the last 2.3 stable version, is it? Thanks, Lise Didillon -- Lise DIDILLON Ingénieur d'études, Ligne Produit UseIT lise.didillon(a)prologue.fr <mailto:lise.didillon@prologue.fr> ------------------------------------------------------------------------ logo prologue <http://www.prologue.fr> ZA de Courtaboeuf 12 Avenue des Tropiques BP 73 - 91 943 Les Ulis Cedex Tél : +33 1 69 29 39 39 Fax : +33 1 69 29 90 43

2 2

contextCSN: multiple values provided
by Kim Jelmoni 03 Feb '09

03 Feb '09

Hello ! I'm trying to setup master - slave ldap on ubuntu 8.10 (master) and gentoo slave. Got on the server side ldap base config (slapd 2.4.11-0ubuntu6.1) and slave openldap 2.3.43 plain file config. Master config : syncrepl_backend.ldif dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcRootDN olcRootDN: cn=Manager,dc=mynet,dc=net - add: olcSyncRepl olcSyncRepl: rid=003 provider=ldap://server1.mynet.net binddn="cn=Manager,dc=mynet,dc=net" bindmethod=simple credentials=secret searchbase="dc=mynet,dc=net" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1 olcSyncRepl: rid=004 provider=ldap://server2.mynet.net binddn="cn=Manager,dc=mynet,dc=net" bindmethod=simple credentials=secret searchbase="dc=mynet,dc=net" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1 - add: olcMirrorMode olcMirrorMode: TRUE dn: olcOverlay=syncprov,olcDatabase={1}hdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov and cliet config : syncrepl rid=003 provider=ldap://server1.mynet.net:389 type=refreshOnly interval="00:00:00:10" retry="5 5 300 5" timeout="1" searchbase="dc=mynet,dc=net" bindmethod=simple binddn="cn=Manager,dc=mynet,dc=net" credentials=secret It was working for sometime ... but now i get the error message (on client): syncrepl_message_to_entry: rid 003 mods check (contextCSN: multiple values provided) do_syncrepl: rid 003 retrying (x retries left) all the time and no sync is happening. I was searching everywhere but i found no solution ... have somebody any idea what the problem is and how to solve it ? Thanks Kim

2 1

Proper Settings for DB_CONFIG
by Tim Gustafson 02 Feb '09

02 Feb '09

I am using the CentOS Yum repository and am running slapd version 2.3.27 on a CentOS 5.2 box. I've been trying to understand OpenLDAP's use of the DB_CONFIG file as well as other database-related directives that appear in slapd.conf. For example, I tried to set DB_LOG_AUTOREMOVE in DB_CONFIG but that seemed to do nothing. I have been having to run "slapd_db_archive -d" to remove old log files. If I don't do this, I often wind up with dozens of log files (at 10GB each) pretty quickly. There also seems to be some ambiguity as far as which options should be specified in slapd.conf versus placed in a DB_CONFIG. So my questions are: 1. Where should I be putting my Berkeley DB configuration options, especially related to automated checkpoints and automatic log removal? slapd.conf or DB_CONFIG? 2. Is there some other option I have to use to have slapd actually remove old log files once they're not needed for a transaction anymore? By the way, this is mostly a problem for my slapo-accesslog database, which has significantly more data in it (by a factor of almost 100) than my actual database. The insanity of all this is that I really just need to grab the last successful bind and last unsuccessful bind date for each user account, and I can't seem to find a better way to do it than with slapo-accesslog. Is there some other much more obvious flag or something I could set on my LDAP server that would just record the last bind attempt timestamps for each user account? Tim Gustafson BSOE Webmaster UC Santa Cruz tjg(a)soe.ucsc.edu 831-459-5354

2 2

Re: Entry cache hit ratio and aggregated logging
by kkalev 02 Feb '09

02 Feb '09

On Mon, Feb 2, 2009 at 7:47 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > --On Monday, February 02, 2009 7:42 PM +0200 kkalev <kkalev(a)gmail.com> > wrote: > > For the second part, why not just query it out of the cn=monitor backend? >> It keeps track of completed operations. >> >> --Quanah >> >> >> >> You are right on that. I originally had the Sun DS behaviour in mind >> where every so often it will post two lines like: >> [02/Feb/2009:15:14:29 +0200] - INFO: 205837 entries in the directory >> database. >> [02/Feb/2009:15:14:29 +0200] - INFO: add:16, modify:218, modrdn:0, >> search:117698, delete:5, compare:0, bind:217781 since startup. >> >> in the error log. Keeping track of operations from cn=monitor should be >> enough anyway. >> What about the entry cache hit ratio? >> > > Hi, > > Please keep replies on the list. (sorry, reply instad of reply-all) > > The entry cache is formed out of those entries that have been accessed the > most, and are aged out based on hits. So the entry cache should always have > the items with the most hits, as I understand it. AFAIK, there is no way to > get the hit ratio from back-monitor or by other means. But I could be > incorrect. ;) Well, being able to see the entry cache hit ratio would be nice so that i know if i got the value right :) Usually a small percentage of the entries are accessed every day and my goal is to keep those in the entry cache. -- Kostas Kalevras - Network Operations Center National Technical University of Athens http://kkalev.wordpress.com > > > --Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

1 0

Re: Entry cache hit ratio and aggregated logging
by Quanah Gibson-Mount 02 Feb '09

02 Feb '09

--On Monday, February 02, 2009 7:42 PM +0200 kkalev <kkalev(a)gmail.com> wrote: > For the second part, why not just query it out of the cn=monitor backend? > It keeps track of completed operations. > > --Quanah > > > > You are right on that. I originally had the Sun DS behaviour in mind > where every so often it will post two lines like: > [02/Feb/2009:15:14:29 +0200] - INFO: 205837 entries in the directory > database. > [02/Feb/2009:15:14:29 +0200] - INFO: add:16, modify:218, modrdn:0, > search:117698, delete:5, compare:0, bind:217781 since startup. > > in the error log. Keeping track of operations from cn=monitor should be > enough anyway. > What about the entry cache hit ratio? Hi, Please keep replies on the list. The entry cache is formed out of those entries that have been accessed the most, and are aged out based on hits. So the entry cache should always have the items with the most hits, as I understand it. AFAIK, there is no way to get the hit ratio from back-monitor or by other means. But I could be incorrect. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Entry cache hit ratio and aggregated logging
by kkalev 02 Feb '09

02 Feb '09

Hello, i 'd like to ask a couple of questions for which i haven't been able to find any obvious answers: 1. Is there a way to know the entry cache (slapd.conf cachesize directive) hit ratio? I haven't been able to find any such element in the cn=monitor structure (although the admin can find the current size of the entry and idl cache). 2. Is there a way to aggregate logging and only post operation numbers every 1 minute in the log file? I am not actually interested in each query run on my ldap server (and if i need that i can just set the log-level to Stats in cn=config) but i would like to be able to keep statistics of the server operations. The ideal situation would be for the server to send a sum of the completed operations during a configurable time interval. Thank you for your time -- Kostas Kalevras - Network Operations Center National Technical University of Athens http://kkalev.wordpress.com

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software February 2009