openldap-technical

openldap-technical@openldap.org

2 participants
9852 discussions

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

Generic Referrals never received.
by BENICHOU Fabrice - Contractor 13 Jan '17

13 Jan '17

Hello, I have 2 LDAP servers: -machine 1:" localserver.domain.com" : the DIT is dn: dc=example dc: bsr-ivv objectClass: top objectClass: dcObject objectclass: organization o: AAA dn: ou=Users,dc=example objectClass: top objectClass: organizationalUnit ou: Users dn: ou=Groups,dc=example objectClass: top objectClass: organizationalUnit ou: Groups -machine 2: "centralserver.domain.com": the DIT is the SAME. and i want that request not found on "localserver.domain.com" should be delegated to "centralserver.domain.com" 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 I use the command "ldapsearch" on "localserver" to request data about "admincentral1" that only exists on "centralserver.domain.com" machine: >ldapsearch -H ldaps://localserver.domain.com -b ou=Users,dc=bsr-ivv -w password -D "cn=Admin,dc=example" uid=admincentral1 mail -x -C -d 129 But the client "ldapsearch" does not get the refferal of "centralserver" LDAP from "localserver". I look at slap logs and ldapsearch logs but the refferal is never received. Shall i activate anything else? NB: if i use referral Objects, this works fine: i found logs like : " Jan 13 13:44:55 m-deploy slapd[24898]: send_ldap_result: referral="ldaps://centralserver.external.domain.com/ou=Users,dc=example" " but with that configuration, no referral are received by client... Best regards Fabrice

1 0

Re: ppolicy overlay and MMR experiencing frequent delta-sync lost issue
by Quanah Gibson-Mount 13 Jan '17

13 Jan '17

--On Thursday, January 12, 2017 10:20 AM -0500 Beth Halsema <bhalsema(a)purdue.edu> wrote: > > Quanah, are you suggesting that the ppolicy attributes (i.e. > pwdGraceUseTime, pwdFailureTime, etc.) not be replicated? Hi Beth, This is clearly noted in the slapo-ppolicy(5) man page: Note that the current IETF Password Policy proposal does not define how these operational attributes are expected to behave in a replication environment. In general, authentication attempts on a slave server only affect the copy of the operational attributes on that slave and will not affect any attributes for a user's entry on the master server. Operational attribute changes resulting from authentication attempts on a master server will usually replicate to the slaves (and also overwrite any changes that originated on the slave). These behaviors are not guaranteed and are subject to change when a formal specification emerges. The correct fix is to modify your syncrepl configuration so that those attributes are ignored by the syncrepl client. There is no patch to the code necessary. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 3

Re: ppolicy overlay and MMR experiencing frequent delta-sync lost issue
by Quanah Gibson-Mount 12 Jan '17

12 Jan '17

--On Thursday, January 12, 2017 11:27 PM +0100 Michael Ströder <michael(a)stroeder.com> wrote: > Mark Cairney wrote: >> On 12/01/17 16:06, Quanah Gibson-Mount wrote: >> >>> The correct fix is to modify your syncrepl configuration so that those >>> attributes are ignored by the syncrepl client. There is no patch to the >>> code necessary. >>> >> >> Possibly a dumb question but do you have a worked example of this? The >> usual "get-all" stanza for this would "*, +" and as far as I'm aware you >> can't subtract attributes from the list returned i.e. search for all >> attributes *except* pwdFailureTime. > > You could try using option exattrs with syncrepl statement, see > slapd.conf(5). One could also change the olcAccess on the accesslog DB to exclude problem attributes from being visible. But exattrs is probably the best route. --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 Howard Chu 12 Jan '17

12 Jan '17

Quanah Gibson-Mount wrote: > --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. There is no need to read source code. Just read the cn=schema,cn=config entry using ldapsearch for all of the relevant definitions. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

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

12 Jan '17

--On Thursday, January 12, 2017 4:23 PM +0000 Martin Stejskal <mstejskal(a)alps.cz> wrote: > > > > Hi Quannah, > > thanks for support. Now I understand little bit more ldif syntax/rules. > Yes, the source code is option as well, but I tried to avoid it :) > > I know there is slapd.conf to cn=config converter, but unfortunately I > was not able to make it work (errors during conversion). I would note that slaptest will report errors during conversion sometime and then note that they should be ignored, since the configuration isn't actually being used against a running slapd. Since you provide no details about the errors encountered, it's impossible to determine if it was a valid error or simply a note about the difference between the conversion process and an active slapd. You could of course take the configurations from test035 and test036 to trivially come up with working configurations to be converted to cn=config as a starting point. :) Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical