openldap-technical

openldap-technical@openldap.org

9 participants
9868 discussions

Replication mode - glibc detected *** slapd: double free or corruption
by Sterling Sahaydak 09 Jul '15

09 Jul '15

I've had replication working for the last few months and now running into the following when I run: slapd -h "ldapi:/// ldap:///ldaps:///" -d 4 I installed GIT on the server, version 1.7.1 which is a couple years old, but was wondering would that have anything causing replication to stop working? ... <= ldap_bv2dn(cn=Database 3,cn=Databases,cn=Monitor)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=database 3,cn=databases,cn=monitor)=0 559edda4 hdb_db_open: "dc=pi-coral,dc=com" 559edda4 hdb_db_open: database "dc=pi-coral,dc=com": unclean shutdown detected; attempting recovery. 559edda4 => bdb_entry_get: ndn: "dc=pi-coral,dc=com" 559edda4 => bdb_entry_get: oc: "(null)", at: "contextCSN" 559edda4 bdb_idl_fetch_key: 559edda4 bdb_idl_fetch_key: 559edda4 send_ldap_result: err=0 matched="" text="" 559edda4 [rw] searchDN: "ou=Users,ou=example,dc=ad,dc=example,dc=com" -> "ou=Users,ou=example,dc=ad,dc=example,dc=com" *** glibc detected *** slapd: double free or corruption (out): 0x00007f3382f44bb0 *** ======= Backtrace: ========= /lib64/libc.so.6(+0x75e66)[0x7f339ab17e66] /lib64/libc.so.6(+0x789b3)[0x7f339ab1a9b3] slapd(filter_free_x+0x13a)[0x7f339ebd72da] /usr/lib64/openldap/rwm-2.4.so.2(+0xb34d)[0x7f3397d0c34d] /usr/lib64/openldap/rwm-2.4.so.2(rwm_filter_map_rewrite+0x2b)[0x7f3397d0c99b] /usr/lib64/openldap/rwm-2.4.so.2(+0x6c3a)[0x7f3397d07c3a] slapd(overlay_op_walk+0x4a)[0x7f339ec41efa] slapd(+0xbaa3b)[0x7f339ec42a3b] slapd(+0xb87ab)[0x7f339ec407ab] slapd(overlay_op_walk+0x4a)[0x7f339ec41efa] slapd(+0xbaa3b)[0x7f339ec42a3b] /usr/lib64/openldap/syncprov-2.4.so.2(+0x70ae)[0x7f3397afb0ae] /usr/lib64/openldap/syncprov-2.4.so.2(+0x72a0)[0x7f3397afb2a0] /lib64/libpthread.so.0(+0x79d1)[0x7f339b0489d1] /lib64/libc.so.6(clone+0x6d)[0x7f339ab8a8fd] ======= Memory map: ======== 7f337c000000-7f337c021000 rw-p 00000000 00:00 0 7f337c021000-7f3380000000 ---p 00000000 00:00 0 7f3381743000-7f3382745000 rw-p 00000000 00:00 0 7f3382745000-7f3382746000 ---p 00000000 00:00 0 7f3382746000-7f3382f46000 rw-p 00000000 00:00 0 7f3382f46000-7f3382f4e000 rw-s 00000000 ca:01 795307 /var/lib/ldap/__db.006 7f3382f4e000-7f3383006000 rw-s 00000000 ca:01 795306 /var/lib/ldap/__db.005 7f3383006000-7f3383246000 rw-s 00000000 ca:01 794767 /var/lib/ldap/__db.004 7f3383246000-7f3397248000 rw-s 00000000 ca:01 794749 /var/lib/ldap/__db.003 7f3397248000-7f3397af4000 rw-s 00000000 ca:01 794744 /var/lib/ldap/__db.002 7f3397af4000-7f3397b00000 r-xp 00000000 ca:01 538738 /usr/lib64/openldap/syncprov-2.4.so.2.10.2 7f3397b00000-7f3397cff000 ---p 0000c000 ca:01 538738 /usr/lib64/openldap/syncprov-2.4.so.2.10.2 7f3397cff000-7f3397d00000 r--p 0000b000 ca:01 538738 /usr/lib64/openldap/syncprov-2.4.so.2.10.2 ... 7f339f6ac000-7f339f9ee000 rw-p 00000000 00:00 0 [heap] 7fff8ad37000-7fff8ad4c000 rw-p 00000000 00:00 0 [stack] 7fff8ad84000-7fff8ad85000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Aborted

2 1

mdb wont replicate
by Brendan Kearney 08 Jul '15

08 Jul '15

at some point in the past, i wound up taking drastic measures and rebuilt my two ldap boxes after taking a backup of the data. i think my process could use some fine tuning and polishing, as a weird nuance has found its way into my environment. i am replicating, using MMR, both config and data between two servers. the config and schemas replicate without issue, as well as the data in the mdb, but not any of the settings for the mdb. if i try, for example, to add an ACL or Index to the mdb, i get an error "ObjectClass modifications are not allowed". i think the root of my issue is that i backed up one of the two boxes and restored the one backup to both boxes while they were both offline. i believe that because they both have the same backed up data on them, some of the internal attributes are identical and therefore conflict. i have seen logs about ContextCSNs being identical, but haven't had time to investigate those messages till now. in any case, whatever i did wrong now does not allow the mdb settings to be replicated between the boxes. what i am looking to understand is how to i correct the situation. i am looking to avoid recreating all of the data, so using backups, exports, etc is something i want to do, and do correctly. would i need to capture slapcat output to a file, or is ldapsearch the correct way to export the data for backup/restore needs? do i need to follow a destructive path to correct this issue or will surgery on the mdb correct my issue? i am running 2.4.39 on Fedora 20. any pointers would be appreciated. brendan

3 7

LDIF modify in a replication server
by mdii 08 Jul '15

08 Jul '15

Hi all, I'm trying to do a LDIF import (via Apache Directory Studio) after a replication issue. The goal is to correct a replication error. The problem is that when I try to import the LDIF file, I'm receiving the following error : > #!ERROR [LDAP: error code 53 - shadow context; no update referral] > I found that is related to the replication, and probably the server is in read-only mode. I also saw several solutions, as changing the olcMirrorMode to FALSE or even delete it from the slapd.conf file. My problem is that I can't find the olcMirrorMod in my slapd.conf file, I just found it in the file \openldap\slapd-oldschema.d\cn=config\cn=schema.ldif. Here is my slapd.conf file (without the comments): > include /usr/local/openldap/etc/openldap/schema/core.schema > include /usr/local/openldap/etc/openldap/schema/cosine.schema > include > /usr/local/openldap/etc/openldap/schema/inetorgperson.schema > include /usr/local/openldap/etc/openldap/schema/nis.schema > > pidfile /usr/local/openldap/var/run/slapd.pid > argsfile /usr/local/openldap/var/run/slapd.args > > ####################################################################### > # MDB database definitions > ####################################################################### > database mdb > suffix "o=xxxxxxxxxx" > rootdn "cn=admin,ou=programmes,o=xxxxxxxxxxxxx" > > rootpw secret > > directory /custom/data/openldap-data > maxsize 5368709120 > > > index objectClass eq > database monitor > > database config > > rootdn "cn=admin,cn=config" > rootpw secret > And here is the LDIF file that I'm trying to import: > version: 1 > > dn: xxxxxxxxxxxxxxxxxxxxxxxxxxxxx > objectClass: top > objectClass: organizationalUnit > objectClass: organizationalentity > ou: xxxxxxxxxxxxxxxxxxxxxxxxxxxxx > additionalmail: xxxxxxxxxxxxxx > businessCategory: xxxxxxxxxxxxxx > codecommune: xxxxxxx > codespecialite: xxxxxxxxxxxxxxx > codetypologie: xxxxxxxxxxx > cta: xxxxxxxxxxxxxxxxx > department: xxxxxxxxxxxxxxxxx > departmentNumber: xxxxxxxxxxxxx > destinationIndicator: xxxxxxxxxx > facsimileTelephoneNumber: xxxxxxxxxxxxxx > financialcode: xxxxxxxxxxxxxx > l: xxxxxxxxxxxxxxx > mail: xxxxxxxxxxxxxx > postalAddress: xxxxxxxxx > postalCode: xxxxxxxxxx > seeAlso: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > > > Are these information correct ? Do you think I can try to log onto ApacheDS avec le compte root (cn=admin,cn=config / secret) to try the import ? If not, is there anyway to see why my replication is not changing these particular entry? Thanks in advance for all the help, Marc

1 0

ldap.conf not being used for TLS_CERT/TLS_KEY
by Deon George 06 Jul '15

06 Jul '15

Hi, Looking for feedback on why this is not working, or if it is a bug. The details of my configuration are here: http://serverfault.com/questions/702739 <http://serverfault.com/questions/702739> I discovered (and proved), that ldapsearch is not honouring TLS_CERT/TLS_KEY in /etc/openldap/ldap.conf. I’m running the query as “root” and selinux is disabled. If however, I put the TLS_CERT/TLS_KEY in my ~/ldaprc or ~/.ldaprc, then they are honoured. Is this a bug? What is stopping the “global default” of TLS_CERT/TLS_KEY from being read? …deon

3 2

relax rules control and MMR
by Michael Ströder 03 Jul '15

03 Jul '15

HI! It seems that some issues with relax rules control and delta-syncrepl-MMR have been fixed in 2.4.41. But I vaguely remember that there was another issue with MMR in case the relax rules control is used. I did not find anything else related in ITS in state non-closed. Should updating the attributes 'authTimestamp' and 'pwdFailureTime' work with relax rules control also with MMR? Ciao, Michael.

2 1

gidNumber uniqueness
by Ferenc Wagner 03 Jul '15

03 Jul '15

Hi, We use (among others) this unique domain in a database: olcUniqueURI: ldap:///?gidNumber?sub?objectClass=posixGroup so that we can't create two groups with the same gidNumber. The problem is that this rule also denies the creation of a posixAccount belonging to an already existing posixGroup. Of course there is no problem creating the account first and the group later. How could we overcome this ordering limitation? -- Thanks, Feri.

2 2

ACL filter and posix group
by Nicolas RENAULT 03 Jul '15

03 Jul '15

Hi, I search a lot but can't find solution so I post here : I have to allow a user to get informations from internal ldap for enterprise external software (cloud backup for laptop). only some accounts have to be retreive by this external user. I create a group (posixgroup) and add members to this one (memberUid) I create the posixAccount that will be used by external software to get informations on the member of the new group. (uid,userPassword,mail,givenName,sn) so I want to make an acl that limit access for the create account to read only informations of users from the created group. I already test overlay memberOf but it's not working with memberUid (not dn style) info openldap server 2.4.40+dfsg-1 on debian jessie simple ldap ou=Users,dc=exemple,dc=com <-- all my users uid=readers,ou=Users,dc=exemple,dc=com <-- the user i want to use to see only cn=externalgroupaccess ou=Groups,dc=exemple,dc=com <-- posixGroup with memberUid cn=arcaboxUser,ou=Groups,dc=exemple,dc=com <-- the group that users have to be visible. acl : access to dn.subtree="dc=Comptes,dc=com" attrs=entry,uid,userPassword,mail,givenName,sn filter=() by dn="uid=readers,ou=Users,dc=exemple,dc=com" read by * break access to dn.subtree="dc=Comptes,dc=com" by dn="readers,ou=Users,dc=exemple,dc=com" search by * break My problem is on the filter (I think) if I use this : filter=(uid=accountuid) the user "readers" can see the information from accountuid and not from others. but cn=arcaboxUser,ou=Groups,dc=exemple,dc=com wil have more than 200 accounts. Question : Someone have an idea to build a filter that containt all cn=arcaboxUser,ou=Groups,dc=exemple,dc=com memberUid value ? I see "set" but if I understand this : http://www.openldap.org/faq/data/cache/1133.html , set is only use in by statement of acl not in filter. Thank you Nicolas (sorry for bad english) I want to make an acl that limit access for a account to read only informations of users from one group

1 0

Problems with openLDAP + GSSAPI + JAVA
by Andreas Laesser 03 Jul '15

03 Jul '15

Hi @all I have a (maybe) a problem with my openldap server authenticating over a JAVA tool (Apache Directory Studio LDAP Browser V2.0.0.v20130628, jXplorer) via GSSAPI. When I do a ldapsearch from command line via GSSAPI it works fine... ~ % klist Ticket cache: FILE:/tmp/krb5cc_1086_lR4Nxxxxrs Default principal: admin(a)SPSC.TUGRAZ.AT Valid starting Expires Service principal 30/06/2015 10:54 02/07/2015 10:54 krbtgt/SPSC.TUGRAZ.AT(a)SPSC.TUGRAZ.AT renew until 10/07/2015 10:54 30/06/2015 10:54 02/07/2015 10:54 ldap/ldap1.spsc.tugraz.at(a)SPSC.TUGRAZ.AT renew until 10/07/2015 10:54 ~ % ldapsearch -H ldaps://ldap1.spsc.tugraz.at -b "dc=SPSC,dc=TUGRAZ,dc=AT" This works well.... but if I try the same from one of the two tools mentioned above it simply not bind or connects.... Does anybody had the same problems, or knows a solution? Thanks for help regards Andreas -- ========================================================================= _____________ / ___________/ Andreas Laesser / //_// /____/ Signal Proc.& Speech Communication Lab. __/ /___/ / __ Graz University of Technology /___//____//___/ Inffeldgasse 16c/EG | A-8010 Graz | Austria http://www.spsc.tugraz.at Tel: +43 (0)316 873 -4443 Fax: DW 104439 =========================================================================

4 4

luseradd 30 minutes after restore ldif backup.
by Fabián M Sales 02 Jul '15

02 Jul '15

I install a new server with LDAP: slapd 2.4.39 And database "MDB". After installation, I use luseradd and adds the user very quickly. But if I restored a backup file BKP.LDIF another server you are running with bdb. /etc/init.d/slapd stop rm -f / var / lib / ldap / * -v -l slapadd /root/BKP.LDIF slapindex -v ldap.ldap chown -R / var / lib / ldap / /etc/init.d/slapd start Luseradd command takes more than 30 minutes. I starting the slapd service with the option "-d 1" I see this: 55957574 mdb_search: 38848 does not match filter 55957574 => mdb_entry_decode: 55957574 <= mdb_entry_decode 55957574 mdb_search: 38854 does not match filter 55957574 => mdb_entry_decode: 55957574 <= mdb_entry_decode 55957574 mdb_search: 38860 does not match filter 55957574 => mdb_entry_decode: 55957574 <= mdb_entry_decode 55957574 mdb_search: 38868 does not match filter No it should be. I need to index any field indexed? /etc/openldap/slapd.conf in my file I have: objectclass index, entryCSN, entryUUID, eq cn Any help? -- Firma Institucional *Fabián* *M. Sales *Soporte Técnico & I.T.I Linux *DonWeb * La Actitud Es Todo www.DonWeb.com ------------------------------------------------------------------------ Nota de confidencialidad: Este mensaje y archivos adjuntos al mismo son confidenciales, de uso exclusivo para el destinatario del mismo. La divulgación y/o uso del mismo sin autorización por parte de DonWeb.com queda prohibida. DonWeb.com no se hace responsable del mensaje por la falsificación y/o alteración del mismo. De no ser Ud el destinatario del mismo y lo ha recibido por error, por favor, notifique al remitente y elim?elo de su sistema. Confidentiality Note: This message and any attachments (the message) are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited by DonWeb.com. DonWeb.com shall not be liable for the message if altered or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender Nota de Confidencialidade: Esta mensagem e seus eventuais anexos podem conter dados confidenciais ou privilegiados. Se você os recebeu por engano ou não é um dos destinatários aos quais ela foi endereçada, por favor destrua-a e a todos os seus eventuais anexos ou copias realizadas, imediatamente. É proibida a retenção, distribuição, divulgação ou utilização de quaisquer informações aqui contidas. Por favor, informenos sobre o recebimento indevido desta mensagem, retornando-a para o autor.

1 0

A new open-source TLS implementation
by Andrew Findlay 02 Jul '15

02 Jul '15

Amazon have just announced a completely new implementation of TLS. By avoiding all the history and ignoring features that they don't need the code has been cut by a factor of 10 when compared with the equivalent part of OpenSSL. OpenSSL or some other crypto library is still needed, but this is surely worth a look for future use with LDAP: http://blogs.aws.amazon.com/security/post/TxCKZM94ST1S6Y/Introducing-s2n-a-… https://github.com/awslabs/s2n/blob/master/README.md Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

4 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical