debugging syncrepl issue

Hello list.

I'm facing a syncrepl issue really strange. Sofar, everytime I had sync 
issue, I just had to stop the consumer, delete its database, and restart 
it again to make it work. However, this time it seems unsufficient, and 
synchronisation hangs on some entries.

In the consumer logs, with loglevel set to sync, starting with an empty 
base, I get lots of successfully synced entries:
Oct  7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123 be_search (0)
Oct  7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123 
uid=test,ou=users,dc=msr-inria,dc=inria,dc=fr
Oct  7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123 be_add (0)
Oct  7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123 
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct  7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123 inserted 
UUID 86a10a62-ddf2-102c-9dfe-558a8530d5ee

Then I get a warning for some strange entry:
Oct  7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123 be_search (0)
Oct  7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123 
ou=kerberos,dc=msr-inria,dc=inria,dc=fr
Oct  7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123 be_add (68)
Oct  7 17:55:25 nation slapd[30453]: dn_callback : new entry is older 
than ours ou=kerberos,dc=msr-inria,dc=inria,dc=fr ours 
20080704085717.749336Z#000000#000#000000, new 
20080704085416.079377Z#000000#000#000000
Oct  7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123 entry 
unchanged, ignored (ou=kerberos,dc=msr-inria,dc=inria,dc=fr)
Oct  7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123 

Problem with adding entries

I am unable to add any entries to my Openldap server. Here is the error message that I'm getting: 

ldap_bind: Server is unwilling to perform (53)
	additional info: operation not supported within naming context

I have no idea what this means. 

Here is my configuration file (slapd.conf): 

#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#

include		/etc/openldap/schema/core.schema
include		/etc/openldap/schema/cosine.schema
include		/etc/openldap/schema/inetorgperson.schema
include		/etc/openldap/schema/nis.schema

# Allow LDAPv2 client connections.  This is NOT the default.
allow bind_v2

# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral	ldap://root.openldap.org

pidfile		/var/run/openldap/slapd.pid
argsfile	/var/run/openldap/slapd.args

slapd hangs on startup from unclean shutdown

I'm running openldap 2.3.43 on a Fedora 9 Linux x64-bit system.  I've 
had to hard reboot this system a few times without cleanly shutting it 
down.  upon startup, most of the time slapd hangs when trying to start 
due to not shutting down cleanly.  The only way to get it going again is 
to go into single user mode, delete everything in /var/lib/ldap and then 
loading a nightly backup.ldif with slapadd.  Is are there any 
settings/configuration changes I can make to slapd to have it start up 
from unclean shutdowns?

ldapdelete struggle

Hi!

I'm having this problem with deleting an entry from my ldap database.
Here is what I'm doing:
# search for the entry
$ ldapsearch -ZZWx '(mail=*uzem*)'
Enter LDAP Password:
[...]
dn::
Y249w5x6ZW1lbHRldMO1IEJyaWfDoWQsY249ZGFuaWVsbCxjbj1hZGRyZXNzYm9va3MsZGM9Z
  WNlbnRydW0sZGM9aHU=
[...]
# numResponses: 2
# numEntries: 1

# got the dn, it is encoded in base64, so I'm trying to delete it:
$ cat ldap_delete.ldif
dn::
Y249w5x6ZW1lbHRldMO1IEJyaWfDoWQsY249ZGFuaWVsbCxjbj1hZGRyZXNzYm9va3MsZGM9Z
# ^^ that is one line in the file
$ ldapdelete -ZZWx -vf ldap_delete.ldif
ldap_initialize( <DEFAULT> )
Enter LDAP Password:
deleting entry "dn::
Y249w5x6ZW1lbHRldMO1IEJyaWfDoWQsY249ZGFuaWVsbCxjbj1hZGRyZXNzYm9va3MsZGM9Z"
ldap_delete: Invalid DN syntax (34)
         additional info: invalid DN

I've tried it without the dn:: prefix too, but it didn't work.

ACL regex and attribute value

Helo

Is the kind of ACL below supported?
access to dn.regex="^uid=.+,(ou=.+),o=org$" attrs=foo val.regex="^(.*)$"
  by ...

I expect $1 to hold ou=whatever and $2 to hold attribute foo value that
gets modified. I have trouble to get it working, and I wonder if
1) are $<digit> supported in val.regex ?
2) is it allowed touse $<digit> with multiples regex? Ot will the values
gathered by the last match overwrite the first one?

--

-- 
Emmanuel Dreyfus
manu <at> netbsd.org

openldap 2.4.11 and test018

Error while importing base ldif

Hey everybody,

I'm trying to import the base ldif file to the OpenLDAP server 
configured with back-sql using MySQL as backend.  Everything is fine 
except that I'm unable to import my ldif's into the database.

it gives an error:
slapadd: database doesn't support necessary operations.

When i try to shutdown slapd and add with ldapadd i get the error 
message of
ldap_bind: Invalid credentials (49)

Can't figure it out at all.

Please badly in need of help.

Regards,

Arun Nair

My ldif file is below
dn: dc=abc,dc=corp
objectClass: top
objectClass: dcObject
objectClass: organization
dc: abc
o: ABC Corp
description: ABC Corporation

dn: cn=root,dc=abc,dc=corp
objectClass: organizationalRole
objectClass: sim[pleSecurityObject
cn: admin
description: LDAP Administrator
userPassword: {SSHA}Kv+99W65RwsYJQNxUuD90X5WZXyH+irl

relay backend doesn't support pagedResult control

Hello list.

I managed to get a correct relay backend configured, so as to remap 
attributes, thanks to previous help from people here. It works OK 
through ldapsearch. However, I still can't use it with the target cisco 
appliance, as pagedResult control doesn't work:
Oct  2 14:07:29 etoile slapd[30006]: conn=118 op=1 SRCH 
base="ou=telephony,dc=msr-inria,dc=inria,dc=fr" scope=2 deref=3 
filter="(objectClass=inetOrgPerson)"
Oct  2 14:07:29 etoile slapd[30006]: conn=118 op=1 SRCH attr=uid 
givenname initials sn manager departmentnumber telephonenumber mail 
title homephone mobile pager
Oct  2 14:07:29 etoile slapd[30006]: conn=118 op=1 SEARCH RESULT tag=101 
err=12 nentries=0 text=critical control unavailable in context

When debug level is set to 1, I get this:
Oct  2 14:16:15 etoile slapd[6002]: => get_ctrls
Oct  2 14:16:15 etoile slapd[6002]: => get_ctrls: 
oid="1.2.840.113556.1.4.319" (critical)
Oct  2 14:16:15 etoile slapd[6002]: <= get_ctrls: n=1 rc=0 err=""

Reading ITS 5191, I understand it is supposed to have been fixed in 2.4 
release. However, I'm using 2.4.11, and I'm still getting the problem. 
Should I reopen the ticket ?

Here's my configuration, if that matters. Trying to make the relay 
database subordinate to the other one doesn't change the problem.

database          relay
suffix            ou=telephony,dc=msr-inria,dc=inria,dc=fr
overlay           rwm
rwm-suffixmassage ou=users,dc=msr-inria,dc=inria,dc=fr

rwm-map attribute telephoneNumber homePhone
rwm-map attribute telephoneNumber

database        bdb
suffix          "dc=msr-inria,dc=inria,dc=fr"
rootdn          "cn=root,dc=msr-inria,dc=inria,dc=fr"

--

-- 
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62

dn cache size exceeds the limits

Hi,

During performance testing with SLAMD we noticed the dncache exceeds the limit. As a result the system
starts to swap a lot and the responses of slapd are very slow.

Has anyone seen that behavior before?

Here are the facts:

slapd.conf 
monitoring      on
tool-threads    4
cachesize       450000
dncachesize     450000
idlcachesize    450000
cachefree       90000

# ldapsearch -x -D "cn=xxxx" -w xx -b 'cn=database 2,cn=databases,cn=monitor' -s sub '(objectclass=*)'
'*' '+' | grep -i Cache

olmBDBEntryCache: 398306
olmBDBDNCache: 482001 <<==========
olmBDBIDLCache: 449999

# slapd -V
@(#) $OpenLDAP: slapd 2.4.11 (Sep 11 2008 10:58:58) $
        root <at> node3:/usr/src/redhat/BUILD/openldap-2.4.11/servers/slapd

#db_stat -V
Berkeley DB 4.6.21: (September 27, 2007)

# uname -r
2.6.9-67.ELsmp

# cat /etc/redhat-release
Red Hat Enterprise Linux AS release 4 (Nahant Update 6)

Cheers,
Pavlos

Synchronizing with backend mysql

Hi,

I was wondering if openLDAP has any connectors to synchronize the users, groups in the directory to an
external database such as mysql.

Thank you.
_________________________________________________________________

chaining and proxy

Hello.

I successfully setup the chain overlay, so as to push changes from a 
slave to a master, with something as:
overlay             chain
chain-uri           "ldap://ldap1.domain.tld"
chain-idassert-bind bindmethod="simple"
                     binddn="cn=chain,ou=roles,dc=domain,dc=tld"
                     credentials="s3cr3t"
                     mode="self"
chain-idassert-authzFrom "*"
chain-tls           start
chain-return-error  TRUE

I'm curious, tough, why the slave has to use a proxy identity to 
authenticate on the master, instead of reusing original query 
credentials. Is there something preventing it, or is just that all 
examples I found sofar were using it ?

I was also curious to know if the slapauth tool was usable to test such 
kind of proxy setup. Reading the man page, it seems rather adapted to 
testing identity mapping through authz-regexp directives.