openldap-technical

openldap-technical@openldap.org

13 participants
9906 discussions

Syncrepl unregularly stops on slaves, leaving DB in inconsistent state
by Karsten.Kroesch＠swisscom.com 22 May '13

22 May '13

Hello OpenLDAP users, I have a Syncrepl setup with one master server and seven slaves. The slaves are mail servers running Postfix, SpamAssassin and Amavis as LDAP clients and have a relatively heavy load. Every two weeks or so (not regularly) the Syncrepl stops on some of the slaves are stopping; there are no Syncrepl requests from the slaves any more. Restarting the Slapd on the slaves fixes the problem in most cases, but sometimes some entries are not replicated until I modify them manually on the master. After that, it works fine again. My OpenLDAP version is 2.4.23 running on SunOS 5.10 Generic_139555-08 sun4v sparc SUNW,Sun-Fire-T1000 Solaris. The servers that are affected more often are running in non-global zone. Any ideas would be helpful. Thanks in advance, Karsten Kroesch ____________________________ Internet Application Engineer Applications Operations karsten.kroesch(a)swisscom.com ____________________________ Swisscom (Schweiz) AG Corporate Business Unit Müllerstrasse 16 8004 Zürich ____________________________ -------8<--------------------------------------- Affected entries, log files and configuration see below: # # On the master: # ldapsearch mail=mthudianplackal(a)[domain-deleted].ch # extended LDIF # # LDAPv3 # base <dc=ip-plus, dc=net> (default) with scope subtree # filter: mail=mthudianplackal(a)[domain-deleted].ch # requesting: ALL # # mthudianplackal(a)[domain-deleted].ch, [domain-deleted].ch, vsf, ip-plus.net dn: mail=mthudianplackal(a)[domain-deleted].ch,dc=[domain-deleted].ch,ou=vsf,dc=ip-plus, dc=net objectClass: top objectClass: mailObject objectClass: amavisAccount mail: mthudianplackal(a)[domain-deleted].ch # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 # On some of the slaves: $ ldapsearch mail=mthudianplackal(a)[domain-deleted].ch # extended LDIF # # LDAPv3 # base <dc=ip-plus, dc=net> (default) with scope subtree # filter: mail=mthudianplackal(a)[domain-deleted].ch # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 Log files at the time, the entries were made: May 16 11:56:20 v-vsf4 slapd[14302]: [ID 538834 local4.debug] daemon: select: listen=7 active_threads=0 tvp=zero May 16 11:56:20 v-vsf4 slapd[14302]: [ID 538834 local4.debug] daemon: select: listen=8 active_threads=0 tvp=zero May 16 11:56:31 v-vsf4 slapd[14302]: [ID 538834 local4.debug] daemon: select: listen=7 active_threads=0 tvp=zero May 16 11:56:31 v-vsf4 slapd[14302]: [ID 538834 local4.debug] daemon: select: listen=8 active_threads=0 tvp=zero May 16 11:56:31 v-vsf4 slapd[14302]: [ID 365351 local4.debug] do_syncrep2: rid=000 LDAP_RES_SEARCH_RESULT # 15 Seconds no action -- unusual on a server with heavy load. May 16 11:56:46 v-vsf4 slapd[14302]: [ID 538834 local4.debug] daemon: select: listen=7 active_threads=0 tvp=zero May 16 11:56:46 v-vsf4 slapd[14302]: [ID 538834 local4.debug] daemon: select: listen=8 active_threads=0 tvp=zero May 16 11:56:46 v-vsf4 slapd[14302]: [ID 977386 local4.debug] syncrepl_entry: rid=000 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) May 16 11:56:46 v-vsf4 slapd[14302]: [ID 580501 local4.debug] syncrepl_entry: rid=000 inserted UUID a36b3802-525a-1032-9442-17888436c71f May 16 11:56:46 v-vsf4 slapd[14302]: [ID 565591 local4.debug] syncrepl_entry: rid=000 be_search (0) May 16 11:56:46 v-vsf4 slapd[14302]: [ID 709484 local4.debug] syncrepl_entry: rid=000 mail=mthudianplackal(a)[domain-deleted].ch,dc=[domain-deleted].ch,ou=vsf,dc=ip-plus,dc=net May 16 11:56:48 v-vsf4 slapd[14302]: [ID 601841 local4.debug] daemon: activity on 1 descriptor May 16 11:56:48 v-vsf4 slapd[14302]: [ID 538834 local4.debug] daemon: select: listen=7 active_threads=0 tvp=zero May 16 11:56:48 v-vsf4 slapd[14302]: [ID 300852 local4.debug] daemon: listen=8, new connection on 91 May 16 11:56:48 v-vsf4 slapd[14302]: [ID 538834 local4.debug] daemon: select: listen=8 active_threads=0 tvp=zero May 16 11:56:48 v-vsf4 slapd[14302]: [ID 368480 local4.debug] daemon: added 91r (active) listener=0 May 16 11:56:48 v-vsf4 slapd[14302]: [ID 848112 local4.debug] conn=35253 fd=91 ACCEPT from IP=192.168.1.4:45922 (IP=0.0.0.0:389) May 16 11:56:48 v-vsf4 slapd[14302]: [ID 601841 local4.debug] daemon: activity on 1 descriptor May 16 11:56:48 v-vsf4 slapd[14302]: [ID 609413 local4.debug] daemon: waked May 16 11:56:48 v-vsf4 slapd[14302]: [ID 538834 local4.debug] daemon: select: listen=7 active_threads=0 tvp=zero May 16 11:56:48 v-vsf4 slapd[14302]: [ID 538834 local4.debug] daemon: select: listen=8 active_threads=0 tvp=zero May 16 11:56:48 v-vsf4 slapd[14302]: [ID 601841 local4.debug] daemon: activity on 1 descriptor May 16 11:56:48 v-vsf4 slapd[14302]: [ID 802679 local4.debug] daemon: activity on: May 16 11:56:48 v-vsf4 slapd[14302]: [ID 522297 local4.debug] 91r May 16 11:56:48 v-vsf4 slapd[14302]: [ID 100000 local4.debug] May 16 11:56:48 v-vsf4 slapd[14302]: [ID 694296 local4.debug] daemon: read activity on 91 May 16 11:56:48 v-vsf4 slapd[14302]: [ID 538834 local4.debug] daemon: select: listen=7 active_threads=0 tvp=zero May 16 11:56:48 v-vsf4 slapd[14302]: [ID 215403 local4.debug] conn=35253 op=0 BIND dn="" method=128 May 16 11:56:48 v-vsf4 slapd[14302]: [ID 538834 local4.debug] daemon: select: listen=8 active_threads=0 tvp=zero May 17 08:43:18 v-vsf4 slapd[14302]: [ID 515743 local4.debug] syncrepl_entry: rid=000 be_add mail=mthudianplackal(a)[domain-deleted].ch,dc=[domain-deleted].ch,ou=vsf,dc=ip-plus,dc=net (0) May 17 08:43:34 v-vsf4 slapd[3312]: [ID 709484 local4.debug] syncrepl_entry: rid=000 mail=mthudianplackal(a)[domain-deleted].ch,dc=[domain-deleted].ch,ou=vsf,dc=ip-plus,dc=net May 17 08:43:34 v-vsf4 slapd[3312]: [ID 515743 local4.debug] syncrepl_entry: rid=000 be_add mail=mthudianplackal(a)[domain-deleted].ch,dc=[domain-deleted].ch,ou=vsf,dc=ip-plus,dc=net (68) May 17 08:43:34 v-vsf4 slapd[3312]: [ID 933660 local4.debug] syncrepl_entry: rid=000 be_modify mail=mthudianplackal(a)[domain-deleted].ch,dc=[domain-deleted].ch,ou=vsf,dc=ip-plus,dc=net (0) May 17 08:43:47 v-vsf4 slapd[3312]: [ID 338579 local4.debug] nonpresent_callback: rid=000 nonpresent UUID a36b3802-525a-1032-9442-17888436c71f, dn mail=mthudianplackal(a)[domain-deleted].ch,dc=[domain-deleted].ch,ou=vsf,dc=ip-plus,dc=net May 17 08:43:48 v-vsf4 slapd[3312]: [ID 905397 local4.debug] syncrepl_del_nonpresent: rid=000 be_delete mail=mthudianplackal(a)[domain-deleted].ch,dc=[domain-deleted].ch,ou=vsf,dc=ip-plus,dc=net (0) May 17 10:11:05 v-vsf4 slapd[3312]: [ID 469902 local4.debug] conn=1480 op=1 SRCH base="dc=ip-plus,dc=net" scope=2 deref=0 filter="(mail=mthudianplackal(a)[domain-deleted].ch)" May 17 10:39:39 v-vsf4 slapd[3312]: [ID 469902 local4.debug] conn=1595 op=1 SRCH base="dc=ip-plus,dc=net" scope=2 deref=0 filter="(mail=mthudianplackal(a)[domain-deleted].ch)" May 17 10:41:15 v-vsf4 slapd[3312]: [ID 469902 local4.debug] conn=1599 op=1 SRCH base="dc=ip-plus,dc=net" scope=2 deref=0 filter="(mail=mthudianplackal(a)[domain-deleted].ch)" May 17 10:41:22 v-vsf4 slapd[3312]: [ID 709484 local4.debug] syncrepl_entry: rid=000 mail=mthudianplackal(a)[domain-deleted].ch,dc=[domain-deleted].ch,ou=vsf,dc=ip-plus,dc=net May 17 10:41:22 v-vsf4 slapd[3312]: [ID 515743 local4.debug] syncrepl_entry: rid=000 be_add mail=mthudianplackal(a)[domain-deleted].ch,dc=[domain-deleted].ch,ou=vsf,dc=ip-plus,dc=net (0) May 17 10:41:37 v-vsf4 slapd[3312]: [ID 469902 local4.debug] conn=1601 op=1 SRCH base="dc=ip-plus,dc=net" scope=2 deref=0 filter="(mail=mthudianplackal(a)[domain-deleted].ch)" May 17 10:41:37 v-vsf4 slapd[3312]: [ID 580335 local4.debug] conn=1601 op=1 ENTRY dn="mail=mthudianplackal(a)[domain-deleted].ch,dc=[domain-deleted].ch,ou=vsf,dc=ip-plus,dc=net" Master configuration: # 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 include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/amavisd-new.schema include /etc/openldap/schema/ipplus.schema pidfile /var/run/slapd.pid argsfile /var/run/slapd.args # allow ldap protocol v2 allow bind_v2 # debug level loglevel 256 ####################################################################### # ldbm database definitions ####################################################################### database bdb suffix "dc=ip-plus,dc=net" rootdn "cn=root,dc=ip-plus,dc=net" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw swisscom # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd/tools. Mode 700 recommended. directory /var/openldap-data # Indices to maintain index objectclass,entryCSN,entryUUID eq index dc,cn,mail eq ####################################################################### # replication ####################################################################### overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 On the slaves, the config looks like: [ ... same as above, execpt replication: ] ####################################################################### # replication ####################################################################### syncrepl rid=0 provider=ldap://v-ldapmaster-lan:389 type=refreshOnly interval=00:00:00:15 searchbase="dc=ip-plus,dc=net" filter="(objectClass=*)" scope=sub attrs="*" bindmethod=simple binddn="cn=root,dc=ip-plus,dc=net" credentials=swisscom schemachecking=off retry="5 +"

2 1

Rationale for compulsory objectClass top in RFC2256 5.1
by Christian Kratzer 21 May '13

21 May '13

Hi, I have always wondered about directories that have included objectClass top in every entry even though practically any usefull objectClass inherits from top eventually. Apparantly RFC2256 5.1 requests this: 5.1. objectClass The values of the objectClass attribute describe the kind of object which an entry represents. The objectClass attribute is present in every entry, with at least two values. One of the values is either "top" or "alias". ( 2.5.4.0 NAME 'objectClass' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) It seems RFC4512 addresses the matter in: A.3. Changes to RFC 2256 This document incorporates Sections 5.1, 5.2, 7.1, and 7.2 of RFC 2256. Section 5.1 of RFC 2256 provided the definition of the 'objectClass' attribute type. This was integrated into Section 2.4.1 of this document. The statement "One of the values is either 'top' or 'alias'" was replaced with statement that one of the values is 'top' as entries belonging to 'alias' also belong to 'top'. So this means objectClass top is still compulsory in every entry as in: dn: cn=bar,dc=example,dc=com objectClass: top objectClass: alias objectClass: extensibleObject which means somehting like the following would be illegal: dn: cn=Hugo,dc=example,dc=com objectClass: person Can anybody comment on the rationale why this is needed ? I somehow completely fail to see the purpose. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer

1 0

standalone and master slave ldap behave differently
by Desiree Klecker 20 May '13

20 May '13

Hello, to update entry persistend in a master slave openldap environment the following steps are performed using Java : 1. The entry is removed. 2. The entry is created again. This does not result in faulty behavior using a single/simple OpenLdap directory. Using a master slave configuration this results in unpredictable errors claiming that the item still exists (the remove statement has ran immediately before) if it is recreated. I cannot see why the master slave environment should not behave in a tranparent way. It seems the remove statement was not executed in complete allthough the call is synchronous. Which additional information are required to analyse the problem? Do similar problems exist/ is this a known problem? Regards, Desiree

2 1

olcAccess replication - error 80 attributes not within database namespace
by Igor Zinovik 20 May '13

20 May '13

Hello. I'm trying to replicate access rules and limits for one of my databases, but with no success: suse:~ # cat olcAccess-syncrepl.ldif dn: olcDatabase={1}mdb,cn=config changetype: modify add: olcSyncrepl olcSyncrepl: {1}rid=002 provider=ldap://ldap1.local bindmethod=simple binddn="cn=admin,cn=config" credentials="TopSecret" searchbase="olcDatabase={1}mdb,cn=config" attrs="olcAccess,olcLimits" timeout=3 network-timeout=0 starttls=yes tls_cert="/etc/openldap/ldap.pem" tls_key="/etc/openldap/ldap.key" tls_cacert="/etc/ssl/local-ca.pem" tls_reqcert=demand tls_crlcheck=none suse:~ # ldapmodify -H ldap://ldap2.local -ZZxWD cn=admin,cn=config -f olcAccess-syncrepl.ldif Enter LDAP Password: modifying entry "olcDatabase={1}mdb,cn=config" ldap_modify: Other (e.g., implementation specific) error (80) additional info: Base DN "olcAccess,olcLimits" is not within the database naming context slapd-2.4.33 if it matters.

3 5

translucent overlay - bogus local entries
by Steve Eckmann 19 May '13

19 May '13

We noticed that adding a local entry for which there is no corresponding remote entry doesn't cause an error to be reported, but the bogus local entry cannot then be found or deleted, as far as I can tell. I realize it was a mistake to add such an entry, but is it possible to configure the translucent overlay to prevent the client from making this mistake, or is it up to the client to ensure a remote entry exists before adding a local entry? And is there some way to find and delete such bobus local entries, either via LDAP commands or by directly querying and managing the local mdb instance? Thanks. Steve

2 2

Re: ldap_add: Invalid syntax (21) additional info: objectclass: value #0 invalid per syntax
by Quanah Gibson-Mount 16 May '13

16 May '13

--On Friday, May 17, 2013 12:38 AM +0100 Youssef Said Khloufi <mragrid(a)yahoo.fr> wrote: > > - stoping and restarting slapd does not resolve the problem. > - i checked all schemes loaded in the configuration DIT using the command > : > sudo ldapsearch -Y EXTERNAL -H ldapi:/// -b "cn=schema,cn=config" > and my scheme is not there (it seems to be the problem). > - i am using openldap-2.4.28 on Ubuntu 12.04.2 LTS. Please do not top post. Please always copy the list in replies if you want further help. I don't see any obvious changes between OpenLDAP 2.4.28 and current release (2.4.35) addressing why your schema wasn't added, but my first step would be to confirm whether or not you see this behavior if you use a release of OpenLDAP that isn't a year and a half old. It certainly works (in general) for me with OpenLDAP 2.4.35: zimbra@zre-ldap002:~$ ldapadd -x -H ldapi:/// -D cn=config -w zimbra dn: cn=stSchema,cn=schema,cn=config objectClass: olcSchemaConfig olcObjectClasses: ( 1.3.6.1.4.1.4203.666.1.1 NAME 'stPerson' SUP inetOrgPerson STRUCTURAL MUST correo) olcAttributeTypes: ( 1.3.6.1.4.1.4203.666.1.2 NAME 'correo' SUP mail) adding new entry "cn=stSchema,cn=schema,cn=config" zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra -b "cn=schema,cn=config" 1.1 dn: cn=schema,cn=config dn: cn={0}core,cn=schema,cn=config dn: cn={1}cosine,cn=schema,cn=config dn: cn={2}inetorgperson,cn=schema,cn=config dn: cn={3}dyngroup,cn=schema,cn=config dn: cn={4}zimbra,cn=schema,cn=config dn: cn={5}amavisd,cn=schema,cn=config dn: cn={6}opendkim,cn=schema,cn=config dn: cn={7}stSchema,cn=schema,cn=config --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

2 1

ldap_add: Invalid syntax (21) additional info: objectclass: value #0 invalid per syntax
by Youssef Said Khloufi 16 May '13

16 May '13

I have the problem that the title mention. I am trying to create this entry : dn: cn=usuario2,ou=st,o=um,c=es changetype: add objectclass: stPerson sn: usuario2 mobile: 657132819 correo: usuario2(a)st.um using the command : ldapmodify -D "cn=admin,o=um,c=es" -W -H ldap://ldap -f st.ldif if i only change the objectclass to "inetOrgPerson" and the attribute "correo" to "mail", everything works well so my DIT is just fine and it's my objectclass "stPerson" that is giving me the problem. This is my definition of the "stPerson" objectclass : #Definición de ObjectClass "stPerson" y atributo "correo" dn: cn=stSchema,cn=schema,cn=config objectClass: olcSchemaConfig olcObjectClasses: ( 1.3.6.1.4.1.4203.666.1.1 NAME 'stPerson' SUP inetOrgPerson STRUCTURAL MUST correo) olcAttributeTypes: ( 1.3.6.1.4.1.4203.666.1.2 NAME 'correo' SUP mail) I already added this scheme to the configuration DIT using the command : ldapadd -Y EXTERNAL -H ldapi:/// -f stSchema.ldif and it says : SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=stSchema,cn=schema,cn=config" I do not see where is the problem.

2 1

Re: getting bindDN in perl script
by Benin Technologies 16 May '13

16 May '13

yes I'm using Net::LDAP in my back-perl to access a back-hdb server and it works, but I always use the same hardcorded $bindDN and $password (for example : $binddn = cn=admin,dc=my-domain and $password = secret) But I'd like to use the same bindDN and the same password as the one that has been used to bind to the back-perl backend Le 15/05/2013 17:14, Brian Reichert a écrit : > On Wed, May 15, 2013 at 03:42:44PM +0100, Benin Technologies wrote: >> thanks, but I'm surprised, I don't see the bindDN and password in the >> parameter list of the perl subs > This has nothing to to with OpenLDAP. > > > From perl, you fird get an LDAP object: > > my $ldap = Net::LDAP->new($uri->as_string); > > then bind: > > my $mesg = $ldap->bind($bindDN, password=> $passwd); > > then search: > > $mesg = $ldap->search( @search_args ); > > once the bind has completed, nothing retains that information; it > was only needed to bind. > > I have no idea what the architecture of your project is, but you'd > be better off asking on one of the perl lists to work this stuff out. >

6 15

openldap client wasn't able to authenticate SSH
by ded1＠MyBSD.org.my 16 May '13

16 May '13

Hi, I have issue with my openldap client to authenticate on SSH using openldap server. It's failed to authenticate using account that i create on openldap server OR default user !. I have to reboot to single mode and change everything back to default. The SSH account that i use is "labu" Output from /etc/passwd on openldap server (10.1.1.1): # more /etc/passwd | grep labu labu:x:1003:1003::/home/labu:/bin/sh Here's what i'm using on the setup: Server (10.1.1.1): i. openldap 2.4.28-1.1 on Linux Ubuntu 12.04 Client (10.1.1.2): i. libpam-ldapd 0.8.4 on Linux Ubuntu 12.04 Here's the output when i do on openldap server itself: # ldapsearch -h localhost -D "cn=admin,dc=ROSAK,dc=COM" -w openiam -b "dc=ROSAK,dc=COM" -s sub "objectclass=*" ldap_bind: Invalid credentials (49) _BUT_ i'm am able to login using admin account on phpldapadmin. Here's my /etc/ldap/slapd.conf ############################################################## # S L A P D . C O N F # ############################################################## include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema password-hash {CLEARTEXT} allow bind_v2 pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args modulepath /usr/lib/ldap moduleload back_bdb.la #moduleload back_@BACKEND@ access to dn.exact="cn=admin,ou=Roles,dc=ROSAK,dc=COM" by * manage access to dn.exact="cn=admin,ou=Roles,dc=ROSAK,dc=COM" by * read access to attrs=userPassword by self write by anonymous auth by * none access to * by self write by users read by anonymous auth database bdb suffix "dc=ROSAK,dc=COM" rootdn "cn=admin,dc=ROSAK,dc=COM" rootpw {CLEARTEXT}123456 directory "/var/lib/ldap" index objectClass eq loglevel 2048 Here's /etc/nsswitch.conf from my openldap client: # /etc/nsswitch.conf passwd: files ldap group: files ldap shadow: files ldap sudoers: files ldap services: files ldap automount: files ldap Here's /etc/pam.d/sshd from my openldap client: # auth include system-auth account required pam_nologin.so account include system-auth password include system-auth session optional pam_keyinit.so force revoke session include system-auth session required pam_loginuid.so Appreciate anyone help / advice. Thanks. --- ded1 "The end is the beginning, the beginning is the end"

2 1

Re: getting bindDN in perl script
by Pierangelo Masarati 16 May '13

16 May '13

Please reply on the mailing list. On 05/16/2013 01:00 AM, Benin Technologies wrote: > yes but...where is this perl function called for binds ??? it isn't in > SampleLDAP.pm... > servers/slapd/back-perl/bind.c calls a method "bind" as much as servers/slapd/back-perl/search.c calls a method "search". Apparently, who wrote "SampleLDAP.pm" did not provide a "bind" example. Note that I've been working for 15 years with OpenLDAP and I never used back-perl; I discovered all of this last night by opening 2 files and reading about 10 lines of code. You should probably try to do something like this yourself. p. > Le 15/05/2013 22:20, Pierangelo Masarati a écrit : >> binddn and bindpw are the first two parameters of the perl function >> called for binds. >> > > -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

3 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical