openldap-technical

openldap-technical@openldap.org

21 participants
9802 discussions

Re: Mirror mode replication
by Philip Colmer 03 Jul '13

03 Jul '13

> Just curious, why would you do "mirror mode" MMR vs just plain MMR? Do you feel you have a specific > requirement that only one master ever receive the write traffic? No specific requirement but the documentation made various points that suggested "mirror mode" MMR would be easier to support ... For example, for plain MMR, the arguments against included: If connectivity with a provider is lost because of a network partition, then "automatic failover" can just compound the problem Typically, a particular machine cannot distinguish between losing contact with a peer because that peer crashed, or because the network link has failed If a network is partitioned and multiple clients start writing to each of the "masters" then reconciliation will be a pain; it may be best to simply deny writes to the clients that are partitioned from the single provider but the arguments against mirror mode were more semantics (e.g. "MirrorMode is not what is termed as a Multi-Master solution" and "MirrorMode can be termed as Active-Active Hot-Standby") rather than any real negatives. I'm essentially looking to have two LDAP servers and keep them in sync. LDAP consumers will be configured to query both and the web interfaces would be configured to talk to their "local" instance with DNS pointing at a preferred instance. For me, the biggest concern I have about implementing MMR - plain or mirror mode - is the challenge of recovering from a problem. Mirror mode seems to be simpler in that respect because only one node has the writes and therefore reconciliation should be straightforward. Philip On 2 July 2013 16:27, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Tuesday, July 02, 2013 10:25 AM +0100 Philip Colmer < > philip.colmer(a)linaro.org> wrote: > > >> At the moment, we have a single LDAP server which we are using with LDAP >> Account Manager for web-based object management and Atlassian Crowd for >> authentication. The LDAP server is queried directly by other servers for >> UNIX-level authentication, i.e. SSH and group membership. >> >> >> I'm looking at introducing a second LDAP server and I'm leaning towards >> choosing mirror mode as the replication methodology. Since the only >> writes to LDAP come via LAM or Crowd, and these are both web-based, I >> think I could set up an almost identical server to the one I have at the >> moment and use a system like Amazon's Route 53 DNS service with health >> checks to allow me to redirect users off to the second server if the >> first server fails. >> > > Just curious, why would you do "mirror mode" MMR vs just plain MMR? Do > you feel you have a specific requirement that only one master ever receive > the write traffic? > > --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 >

1 0

Corrupted cn=config on multimaster configuration
by paolo penzo 02 Jul '13

02 Jul '13

Hi all, recently I've upgraded some OpenLDAP installations running MM replica from version 2.4.23 to version 2.4.34 (both compiled and packaged locally on RHEL6). At the beginning everything worked fine but then on a cluster I got a corrupted cn=config database after that some modifications were made. When this arose on all the nodes but one the cn=config database was missing of all the other database definitions. I've made a little investigation on this with no luck but I was able to reproduce this behaviour with a simple script which is attached whenever the replication is configured. In my tests both the nodes are configured with the monitor database but after the replica is activated, on the second one, this database is removed and the logs reports "be_delete olcDatabase={1}monitor,cn=config" Did I miss something? Regards, Paolo. ________________________________ Non stampare questa e-mail. Questo documento e' formato esclusivamente per il destinatario. Tutte le informazioni ivi contenute, compresi eventuali allegati, sono soggette a riservatezza a termini del vigente D.Lgs. 196/2003 in materia di privacy e quindi ne e' proibita l'utilizzazione. Se avete ricevuto per errore questo messaggio, Vi preghiamo cortesemente di contattare immediatamente il mittente e cancellare la e-mail. Grazie. Please don't print this e-mail. Confidentiality Notice - This e-mail message including any attachments is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

1 0

Mirror mode replication
by Philip Colmer 02 Jul '13

02 Jul '13

At the moment, we have a single LDAP server which we are using with LDAP Account Manager for web-based object management and Atlassian Crowd for authentication. The LDAP server is queried directly by other servers for UNIX-level authentication, i.e. SSH and group membership. I'm looking at introducing a second LDAP server and I'm leaning towards choosing mirror mode as the replication methodology. Since the only writes to LDAP come via LAM or Crowd, and these are both web-based, I think I could set up an almost identical server to the one I have at the moment and use a system like Amazon's Route 53 DNS service with health checks to allow me to redirect users off to the second server if the first server fails. It occurs to me, though, that either LAM or Crowd could have failed, leaving the LDAP service itself quite healthy. In that situation, all of the writes would still be directed to one of the LDAP servers so is that a problem? The documentation says that "the two providers are set up to replicate from each other but an external frontend is employed to direct all writes to only one of the two servers. The second provider will only be used for writes if the first provider crashes, at which point the frontend will switch to directing all writes to the second provider. When a crashed provider is repaired and restarted it will automatically catch up to any changes on the running provider and resync." So the only requirement of mirror mode *seems* to be that all writes just go to one provider at a time, i.e. the replication model must be as close to single-master as possible, presumably because of consistency requirements? Or do I need to introduce yet another layer of "something" to direct the writes? The documentation suggests slapd in proxy model or a hardware load balancer, but would my scenario as described above meet the needs? Thanks. Philip

2 1

OpenLDAP multimaster
by 25Dollar Tech 02 Jul '13

02 Jul '13

Hello Team, I have a few concern about OpenLDAP multimaster restoration and migration. Scenario I have OpenLDAP multimaster configured on ubuntu 9.04 and OPenLDAP version is 2.4.15. i.e. NODE1 and NODE2 Unfortunatly NODE2 has crashed due to server hardware failure. and running my OpenLDAP infra for a while without multi-master server but I have multimaster confoguraiton on NODE1 which is working without any issues. Question 1) Is it possible to bind new OpenLDAP version and OS ubuntu 12.04 with existing OpenLDAP multimaster server; existing NODE1 server has config DB and HDB already configured and it contains more than 10000 entry. and NODE2 is already crashed. 2) If yes then what will be procedure to replicate config DB or how to equalize the database. -- *Thanks & Regards, 25dollarTech Team https://sites.google.com/site/25dollartech/* *Email: 25dollartechhelp(a)gmail.com*

2 1

pure_ftpd & LDAP
by maral 01 Jul '13

01 Jul '13

hey! I installed Pure-ftpd + Ldap and add a user in Ldap but Pure-ftpd don't recognize that user how can i fix this issue?

2 2

OpenLDAP Proxy using PKCS#11/SmartCard client authentication
by Stefan Scheidewig 01 Jul '13

01 Jul '13

Hello, we have two LDAP instances. LDAP A acts as proxy for LDAP B using the ldap-backend. Now we configured LDAP B to use client authentication. We successfully established a connection to LDAP B using OpenSSL s_client and the PKCS#11 engine (OpenSSL engine library). Now we want the LDAP proxy to establish the connection using this pkcs11 engine (we compiled the ldap proxy to use OpenSSL as TLS implementation). Is there a posibility to tell the LDAP proxy to use the certificate and key from the smartcard (e.g. something like pkcs11:slot_1-id_42) ? Thank you in advance, Stefan Scheidewig -- Mit freundlichen Grüßen, Stefan Scheidewig T-Systems Multimedia Solutions GmbH BU Content & Collaboration Solution PF 54 Integrated Content Portals Dipl.-Inf. Stefan Scheidewig Softwareentwickler Hausanschrift: Riesaer Str. 5, 01129 Dresden, Germany Postanschrift: Postfach 10 02 24, 01072 Dresden, Germany +49 351 2820 2924 (Tel) +49 351 2820 5118 (Fax) Stefan.Scheidewig(a)t-systems.com (E-Mail) Internet: http://www.t-systems-mms.com T-Systems Multimedia Solutions GmbH Aufsichtsrat: Klaus Werner (Vorsitzender) Geschäftsführung: Peter Klingenburg, Susanne Heger Handelsregister: Amtsgericht Dresden HRB 11433 Sitz der Gesellschaft Dresden Ust-IdNr.: DE 811 807 949

4 9

ACL - grant access to subtree by regex
by Ole 29 Jun '13

29 Jun '13

Hi, I'm really new to OpenLDAP and try to grant domain-admins access to their domain-subtree in our historicaly grown LDAP Structure. The Structure is like this: ou=somedomain.tld,ou=mail,dc=example,dc=tld ou=admins,ou=somedomain.tld,ou=mail,dc=example,dc=tld cn=admin(a)somedomain.tld,ou=admins,ou=somedomain.tld,ou=mail,dc=example,dc=tld The ACL I try to use (according to [1]) is: access to dn.regex=".+,ou=([^,]+),ou=mail,dc=example,dc=tld$" by dn.onelevel,expand="ou=admins,ou=$1,ou=mail,dc=example,dc=tld" write by * break but it doesn't take effect. After hours of thinking about the problem and searching in the internet I still can't get the poit. Thank you for reading, Ole [1] http://www.openldap.org/faq/data/cache/973.html

2 4

Types of Groups, Structural objects and Inheritance
by Brendan Kearney 29 Jun '13

29 Jun '13

list members, As a caveat to my ACLs, most of my groups are the posixGroup class. from what i understand, that means i need to use set ACLs, instead of group ACLs. this does not seem to be a big deal, and is covered in the admin guide. that being said, i am looking to find out what the functional differences between a posixGroup and groupOfNames are? are there significant reasons to use one over the other? in my environment, i have the ability to recreate all the posixGroup objects as groupOfNames objects, if it would help with the creation of ACLs and other work to be done. is that a worthwhile effort? In my searching, i have found an explicit reason to keep using the posixGroup type, as NFSv4 ACLs can only use posixGroup types of groups. the dependency is because of the use of memberUid attributes. would there be any other explicit reasons to use one group type over another? my users have inetOrgPerson as their structural class, and as such i cannot add the NFSv4RemotePerson class to their list of objectClass attributes. the NFSv4RemotePerson class is structural as well. i have heard about the ability to create a hierarchy of objectClass objects so that an object can inherit the properties of all the SUP classes. is there a way i can create this hierarchy to allow multiple structural class attributes to be inherited by user objects? i have not found much info around doing this. are there any pointers? thanks in advance, brendan

3 3

Openldap-2.4.35 TLS/SSl
by Darouichi, Aziz 29 Jun '13

29 Jun '13

Hi, I am trying to configure TLS/SSL and I have a Cert from Geotrust . I configure slapd.conf with the followings: # TLS/SSL information # TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCACertificateFile /opt/local/etc/openldap/GeoTrust_Global_CA.cer TLSCertificateFile /opt/local/etc/openldap/rhea.curry.edu.pem.cer TLSCertificateKeyFile /opt/local/etc/openldap/rhea.key.pem But when I check the cert using "openssl s_client -connect 192.168.60.43:636 -CApath /opt/local/etc/openldap/" I get CONNECTED(00000003) 140230373582504:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 321 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE I checked the log I see TLS connection

3 2

LB health check during syncrepl refresh
by Michael Ströder 28 Jun '13

28 Jun '13

HI! Inspired by ITS#7616 and looking at our monitoring: If I bring up a syncrepl consumer with empty DB it seems contextCSN attribute is missing in DB base entry during refresh phase. This is nice because we could use that in the load-balancer health check to prevent clients to connect to this replica until all data is loaded into the consumer and contextCSN is present. So is it guaranteed that contextCSN is missing during lengthy refresh phase? Ciao, Michael.

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical