Re[2]: 2.4.13 slapacl strange behavior
by Irina Shetuhina
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
14 years, 7 months
Initializing cn=config from existing multi-master setup via syncrepl - "new entry is older than ours"
by Jonathan Clarke
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
14 years, 7 months
GSSAPI and LVS Load balanced ldap servers
by Francis Swasey
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)
14 years, 7 months
2.4.13 slapacl strange behavior
by Dmitriy Kirhlarov
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
14 years, 7 months
stable version 2.3
by Lise Didillon
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
14 years, 7 months
contextCSN: multiple values provided
by Kim Jelmoni
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
14 years, 7 months
Proper Settings for DB_CONFIG
by Tim Gustafson
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
14 years, 7 months
Re: Entry cache hit ratio and aggregated logging
by kkalev
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
>
14 years, 7 months
Re: Entry cache hit ratio and aggregated logging
by Quanah Gibson-Mount
--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
14 years, 7 months
Entry cache hit ratio and aggregated logging
by kkalev
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
14 years, 7 months
