openldap-technical January 2017

openldap-technical@openldap.org

47 participants
80 discussions

Re: Antw: Re: ContextCSN values in 3-multimaster setup
by Quanah Gibson-Mount 18 Jan '17

18 Jan '17

--On Thursday, January 19, 2017 8:50 AM +0100 Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de> wrote: > Can't it be done online (using ldapmodify), and wouldn't it be > re-replicated back? It won't remove the contextCSN from the root entry if you do it online. I missed noting that step was necessary as well. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: ContextCSN values in 3-multimaster setup
by PRATIK SINGAL 18 Jan '17

18 Jan '17

Hi if you are using syncReply then its ideally contextcsn#rid#sid#00000# also you can have a look at slap -c option you get some more idea about it. Regards, Pratik On 19-Jan-2017 03:29, "Marc Franquesa" <mark(a)l3jane.net> wrote: Hi all I finally got working a new setup with 3-node multimaster replication for both the main DIT and cn=config tree. Now I'm trying to monitor the replication status or all the nodes so I focused on examining the contextCSN value of the root of the DBs, and although I googled and reviewed other posts on the mailing list I'm still not sure to understand correctly its use. As far as I understood (please correct me if I'm wrong): - Each DB backend which is replicated will have its own and independent contextCSN at the root of the replicated DN (so I have 2 DBs: cn=config, and dc=domain,dc=net, each one will have its own contextCSN attribute). - Each master which is running as a sync provider will update one value on the contextCSN values. So, as I have multi-master replication between 3 nodes (3 providers), I should have 3 different values of contextCSN in each DB. ... so, why I'm seeing 4 values (identical on all servers as they are in sync): contextcsn: 20170111084028.692133Z#000000#001#000000 contextcsn: 20161228225757.121969Z#000000#004#000000 contextcsn: 20160201102250.543748Z#000000#005#000000 contextcsn: 20150917152138.054326Z#000000#006#000000 In the past I migrated some server, added some other node so is possible that a 'ghost' provider CSN is still on the DB ? Another point is the syntax of that value... Has any special meaning? It seems that the first part is a timestamp with milisecond resolution, but I would like to know the meaning of the 3 digits between #xxx# Are they the ServerId ? or the rid in the replication ? Please enlight me Thanks for any details

1 0

Re: Replication issue in 2.4
by Quanah Gibson-Mount 18 Jan '17

18 Jan '17

--On Tuesday, January 17, 2017 6:07 PM +0530 PRATIK SINGAL <pratik.singal13(a)gmail.com> wrote: > > Hello , > > > Can any one please help me with this.Am using BDB and openldap 2.4 with > multi master replication > below is my slapd.conf for replication OpenLDAP version? There are many point releases in the 2.4 series. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: slapd-meta with olc
by Quanah Gibson-Mount 18 Jan '17

18 Jan '17

--On Wednesday, January 11, 2017 10:23 AM +0000 Martin Stejskal <mstejskal(a)alps.cz> wrote: I'll fix this LDIF for you, although I don't know the answers to the rest of your questions. > $ cat add_meta_backend.ldif > dn: cn=module{},cn=config > objectClass: olcModuleList > cn: module{} > olcModulePath: /usr/lib/ldap > olcModuleLoad: back_meta > olcModuleLoad: back_ldap > olcModuleLoad: rwm As for olc attribute names, you can trivially grab these out of the source code. Or, you can use slaptest to convert a slapd.conf to cn=config to see the corresponding configuration. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

4 5

Odd ldapsearch behavior
by Frank Swasey 18 Jan '17

18 Jan '17

I have discovered that I have a development server that is giving back multiple copies of the entryDN and subschemaSubentry values when operational attributes are requested. However, my production server (running the same locally compiled version of 2.4.44) does not. My question is what the dickens have I misconfigured that would cause this? Examples: $ ldapsearch -x -H ldaps://production_server -D cn=manager,dc=example,dc=com -y password_file -b 'dc=example,dc=com' -s base '(objectclass=*)' '+' dn: dc=example,dc=com creatorsName: cn=Manager,dc=example,dc=com createTimestamp: 20020531160527Z modifiersName: cn=Manager,dc=example,dc=com modifyTimestamp: 20020531160527Z structuralObjectClass: organization entryUUID: b745df88-a640-1027-9374-fb1dd3799b92 entryCSN: 20031108140804.000000Z#000017#000#000000 contextCSN: 20161004102449.402212Z#000000#000#000000 contextCSN: 20170111164206.727511Z#000000#001#000000 contextCSN: 20161219150039.213065Z#000000#002#000000 entryDN: dc=example,dc=com subschemaSubentry: cn=Subschema auditContext: cn=accesslog hasSubordinates: TRUE $ ldapsearch -x -H ldaps://development_server -D cn=manager,dc=example,dc=com -y password_file -b 'dc=example,dc=com' -s base '(objectclass=*)' '+' dn: dc=example,dc=com creatorsName: cn=Manager,dc=example,dc=com createTimestamp: 20020531160527Z modifiersName: cn=Manager,dc=example,dc=com modifyTimestamp: 20020531160527Z structuralObjectClass: organization entryUUID: b745df88-a640-1027-9374-fb1dd3799b92 entryCSN: 20031108140804.000000Z#000017#000#000000 contextCSN: 20161004102449.402212Z#000000#000#000000 contextCSN: 20170111013201.758363Z#000000#001#000000 contextCSN: 20161219150039.213065Z#000000#002#000000 entryDN: dc=example,dc=com subschemaSubentry: cn=Subschema hasSubordinates: TRUE entryDN: dc=example,dc=com subschemaSubentry: cn=Subschema auditContext: cn=accesslog - Frank Swasey

2 2

ContextCSN values in 3-multimaster setup
by Marc Franquesa 17 Jan '17

17 Jan '17

Hi all I finally got working a new setup with 3-node multimaster replication for both the main DIT and cn=config tree. Now I'm trying to monitor the replication status or all the nodes so I focused on examining the contextCSN value of the root of the DBs, and although I googled and reviewed other posts on the mailing list I'm still not sure to understand correctly its use. As far as I understood (please correct me if I'm wrong): - Each DB backend which is replicated will have its own and independent contextCSN at the root of the replicated DN (so I have 2 DBs: cn=config, and dc=domain,dc=net, each one will have its own contextCSN attribute). - Each master which is running as a sync provider will update one value on the contextCSN values. So, as I have multi-master replication between 3 nodes (3 providers), I should have 3 different values of contextCSN in each DB. ... so, why I'm seeing 4 values (identical on all servers as they are in sync): contextcsn: 20170111084028.692133Z#000000#001#000000 contextcsn: 20161228225757.121969Z#000000#004#000000 contextcsn: 20160201102250.543748Z#000000#005#000000 contextcsn: 20150917152138.054326Z#000000#006#000000 In the past I migrated some server, added some other node so is possible that a 'ghost' provider CSN is still on the DB ? Another point is the syntax of that value... Has any special meaning? It seems that the first part is a timestamp with milisecond resolution, but I would like to know the meaning of the 3 digits between #xxx# Are they the ServerId ? or the rid in the replication ? Please enlight me Thanks for any details

1 0

RE: openldap-technical Digest, Vol 110, Issue 14
by BENICHOU Fabrice - Contractor 16 Jan '17

16 Jan '17

Hello, I would like to clarify my problem: My 2 LDAP servers (configured as Provider) shares the same Tree (DIT) (same part of tree): - "Server local" manages the whole tree with the structure : dc=com ou=People,dc=com uid=local_admin,ou=People,dc=com ou=Group,dc=com - "Server central" manages a database with the SAME tree structure but with other account dc=com ou=People,dc=com uid= central_admin ,ou=People,dc=com ou=Group,dc=com Is it possible to configure the "Server local" to delegates the request to "Server Central" if an account is not found locally? For example, with LDAPSEARCH: >ldapsearch -H ldaps://Server-local.com -b ou=dcom -w private -D "cn=Admin,dc=com" uid=central_admin mail -x -C => This Fails: the Serve Local does not return the "Server central" to Ldapsearch. However, if I change the DIT of "Server central" in order to be different, the Ldap delegation works. For example: - "Server central" 's DIT: dc=com2 ou=People,dc=com2 uid= central_admin ,ou=People,dc=com2 ou=Group,dc=com2 >ldapsearch -H ldaps://Server-local.com -b ou=com2 -w private -D "cn=Admin,dc=com" uid=central_admin mail -x -C => This works: Dn: uid=adminCentral,ou=People,dc=com2 Mail: admin_central(a)com2.com Ldapsearch 's traces contains referral url: "ldap_chase_v3_referral: msgid 2, url "ldaps:// Server-central.com /dc=com2 ??sub" It seems that no referral is returned if the tree are identical: it is possible to configure the Ldap server "local" to return the referral to the "central (root) if the local query fails? OpenLdap Admin Guide (version 2.4) , chapter 5.2.1.3 (olcReferral) says "This directive specifies the referral to pass back when salpd cannot find a local database to handle a request". Best regards Fb [@@ THALES ALENIA SPACE INTERNAL @@] -----Message d'origine----- De : openldap-technical [mailto:openldap-technical-bounces@openldap.org] De la part de openldap-technical-request(a)openldap.org Envoyé : dimanche 15 janvier 2017 13:00 À : openldap-technical(a)openldap.org Objet : openldap-technical Digest, Vol 110, Issue 14 Send openldap-technical mailing list submissions to openldap-technical(a)openldap.org To subscribe or unsubscribe via the World Wide Web, visit http://www.openldap.org/lists/mm/listinfo/openldap-technical or, via email, send a message with subject or body 'help' to openldap-technical-request(a)openldap.org You can reach the person managing the list at openldap-technical-owner(a)openldap.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openldap-technical digest..." Send openldap-technical mailing list submissions to openldap-technical(a)openldap.org When replying, please edit your Subject: header so it is more specific than "Re: openldap-technical digest..." Today's Topics: 1. Re: Generic Referrals never received. (Quanah Gibson-Mount) ---------------------------------------------------------------------- Message: 1 Date: Sat, 14 Jan 2017 11:57:57 -0800 From: Quanah Gibson-Mount <quanah(a)symas.com> To: BENICHOU Fabrice - Contractor <fabrice.benichou(a)external.thalesaleniaspace.com>, openldap-technical(a)openldap.org Subject: Re: Generic Referrals never received. Message-ID: <F3905FAB793AC520D721F0B1(a)[192.168.1.30]> Content-Type: text/plain; charset=us-ascii; format=flowed --On Friday, January 13, 2017 5:16 PM +0100 BENICHOU Fabrice - Contractor <fabrice.benichou(a)external.thalesaleniaspace.com> wrote: > the configuration of "localserver.domain.com" is: > > dn: cn=config > > objectClass: olcGlobal > > cn: config > > olcArgsFile: /var/run/openldap/slapd.args > > olcPidFile: /var/run/openldap/slapd.pid > > olcTLSCACertificatePath: /etc/openldap/certs > > olcTLSCertificateFile: "OpenLDAP Server" > > olcTLSCertificateKeyFile: /etc/openldap/certs/password > > structuralObjectClass: olcGlobal > > creatorsName: cn=config > > olcReferral: ldaps://centralserver.domain.com > > olcLogLevel: -1 This is not a full configuration. It looks like you simply cut and pasted the cn=config.ldif file. You would want to slapcat the cn=config DB to get the full config database. I'm assuming you're trying to report a configuration issue on your end with back-ldap or similar. You'd most likely want to only provide the relevant configuration details for that portion of the configuration database. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com> ------------------------------ Subject: Digest Footer _______________________________________________ openldap-technical mailing list openldap-technical(a)openldap.org http://www.openldap.org/lists/mm/listinfo/openldap-technical ------------------------------ End of openldap-technical Digest, Vol 110, Issue 14 ***************************************************

1 0

Re: Generic Referrals never received.
by Quanah Gibson-Mount 14 Jan '17

14 Jan '17

--On Friday, January 13, 2017 5:16 PM +0100 BENICHOU Fabrice - Contractor <fabrice.benichou(a)external.thalesaleniaspace.com> wrote: > the configuration of "localserver.domain.com" is: > > dn: cn=config > > objectClass: olcGlobal > > cn: config > > olcArgsFile: /var/run/openldap/slapd.args > > olcPidFile: /var/run/openldap/slapd.pid > > olcTLSCACertificatePath: /etc/openldap/certs > > olcTLSCertificateFile: "OpenLDAP Server" > > olcTLSCertificateKeyFile: /etc/openldap/certs/password > > structuralObjectClass: olcGlobal > > creatorsName: cn=config > > olcReferral: ldaps://centralserver.domain.com > > olcLogLevel: -1 This is not a full configuration. It looks like you simply cut and pasted the cn=config.ldif file. You would want to slapcat the cn=config DB to get the full config database. I'm assuming you're trying to report a configuration issue on your end with back-ldap or similar. You'd most likely want to only provide the relevant configuration details for that portion of the configuration database. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Odd ldapsearch behavior
by Quanah Gibson-Mount 13 Jan '17

13 Jan '17

--On Wednesday, January 11, 2017 2:50 PM -0500 Frank Swasey <Frank.Swasey(a)uvm.edu> wrote: > My slapd.conf files are built using mustache templates with minimal > differences... Is there a specific config option I should be looking at > that could cause the operational attributes to be duplicated in the > output of ldapsearch but not slapcat? Well, it'd be a bug, so I've no idea what would specifically trigger it. :) I guess you could diff the slapd.conf files and see what differences exist and start from there? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Antw: Odd ldapsearch behavior
by Frank Swasey 13 Jan '17

13 Jan '17

Ulrich, You are correct, the development system is copied from the production system. The process is to perform the same ldapsearch that is producing a corrupted ldif from the development system against the production system on my management system. I then scp the ldif file over to the development system and use slapadd to load it on the development system. I have noted that slapcat on the development system does not produce the corrupted ldif file - so I do not believe my "copy production data to development system" procedure is the cause. - Frank On Thu, 12 Jan 2017 at 2:08am, Ulrich Windl wrote: > Hi! > > From your data it seems your development database is somewhat a copy of your production database, right? How did you copy? I suspect the procedure produced a currupted database (MHO).

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical January 2017