December 2013 - openldap-technical

Upgrading from Ubuntu-packaged 2.4.28 to self-built 2.4.38

by Philip Colmer

Our current implementation of OpenLDAP is Ubuntu 12.04 running version 2.4.28 which has been installed as a package. To upgrade to 2.4.38, it looks like I need to remove that package and then install my own built binaries. Has anyone gone through this process before and got any tips/notes to share? I'm particularly thinking that there will be some path changes to contend with. For example, my main HDB database seems to be in /var/lib/ldap but the migration steps suggest that everything is in /usr/local/var/openldap-data/. Clearly I can work through this but if someone has already done it and can share lessons learnt, that would be much appreciated. Philip

9 years, 11 months

4
5
0 / 0

Running slapcat and slapd at the same time

by Chris Card

Hi all, I am running openldap 2.4.36 with Berkeley DB 4.6.21 under centos 6.3 64 bit on a Dell 710 with 96 Gb RAM. My slapd configuration sets the BDB cachesize to use a shared memory segment of 47 Gb (id2entry.bdb is about 40 Gb currently). I use slapcat to take regular backups using the same configuration as slapd, running in parallel with slapd, and the backup works successfully, but uses a lot of memory when it is running. I would like to be able to run slapcat with a smaller memory requirement, and to this end I have experimented with running slapcat with a different configuration as follows: 1. create a work directory 2. create links in the work directory to the .bdb files 3. slapcat cn=config to an ldif file 4. edit the ldif file to change the db data directory to the work directory and change the olcDbConfig settings to use less memory 5. slapadd the ldif file to create a new slapd.d config directory in the work directory 6. run slapcat with the new slapd.d config The reason for this approach is to allow slapcat to run with a different DB_CONFIG file to slapd. This appeared to work in testing, but in the production environment produced backups with data missing, while outputting no error messages. Is there a way to run slapcat with a different memory configuration to slapd? Chris

9 years, 11 months

2
1
0 / 0

please fix ITS#6825

by Michael Ströder

HI! I have a setup where I cannot work around ITS#6825 by putting posixGroup entries in a single container. So I hit this bug again where slapo-unique does not behave as documented: http://www.openldap.org/its/index.cgi?findid=6825 Is there a chance to get this fixed soon? Ciao, Michael.

9 years, 11 months

1
0
0 / 0

OPENLDAP BUILD/CONFIGURE

by Borresen, John - 0442 - MITLL

Attempting to upgrade to OpenLDAP 2.4.38 Receiving the following output : Configuring OpenLDAP 2.4.38-Release ... checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking configure arguments... done checking for ar... ar checking for style of include used by make... GNU checking for gcc... gcc checking whether the C compiler works... no configure: error: in `/opt/rpmbuild/BUILD/openldap-2.4.38': configure: error: C compiler cannot create executables See `config.log' for more details. Using the following options with ./configure: $ ./configure --disable-dependency-tracking --enable-ldap --enable-debug --prefix=/usr/local/openldap --libdir=/usr/local/openldap/lib64 --with-tls --with-cyrus-sasl --enable-spasswd --enable-overlays --enable-modules --enable-dynamic=no --enable-slapi --enable-meta --enable-crypt In the config.log seeing the following: configure:5744: $? = 127 configure:5764: checking whether the C compiler works configure:5786: gcc -DOPENLDAP_FD_SETSIZE=4096 -O2 -g -I/usr/local/berkeleydb/include -I/usr/kerberos/include -L/usr/local/berkeleydb/lib64 conftest.c -ldb -ldb-4.6 -ldb46 -ldb-4 -ldb-4-6 -lgcc_s >&5 ./configure: line 5788: gcc: command not found configure:5790: $? = 127 configure:5828: result: no configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "" | #define PACKAGE_TARNAME "" | #define PACKAGE_VERSION "" | #define PACKAGE_STRING "" | #define PACKAGE_BUGREPORT "" | #define PACKAGE_URL "" | #define OPENLDAP_PACKAGE "OpenLDAP" | #define OPENLDAP_VERSION "2.4.38" | #define LDAP_VENDOR_VERSION 20438 | #define LDAP_VENDOR_VERSION_MAJOR 2 | #define LDAP_VENDOR_VERSION_MINOR 4 | #define LDAP_VENDOR_VERSION_PATCH 38 | #define HAVE_MKVERSION 1 | /* end confdefs.h. */ ... configure:5833: error: in `/opt/rpmbuild/BUILD/openldap-2.4.38': configure:5837: error: C compiler cannot create executables See `config.log' for more details. Note: gcc is installed (/usr/bin/gcc) and is version 4.4.7 John D. Borresen (Dave) Linux/Unix Systems Administrator MIT Lincoln Laboratory Surveillance Systems Group 244 Wood St Lexington, MA 02420 Ph: (781) 981-1609 Email: john.borresen(a)ll.mit.edu<mailto:john.borresen@ll.mit.edu>

9 years, 11 months

4
6
0 / 0

2 way SSL configuration in OpenLDAP 2.4

by vidya bharadwaj

Hi, We have to implement a 2 way SSL mechanism on a LDAP connector in our product. In order to test the implementation, we have chosen openLDAP2.4 as the data source. Currently we have done the following steps: On the OpenLDAP end: 1. Installed OpenLDAP with TLS feature 2.Created a CA using OpenSSL /etc/pki/tls/misc/CA –newca 3.Created a certificate using OpenSSL openssl req -newkey rsa:1024 -nodes -keyout newreq.pem -out newreq.pem 4.Signed the certificate using the CA created /etc/pki/tls/misc/CA –sign 5. Finally stored the cacert.pem, newreq.pem and newcert.pem under /opt/openldap/certificate folder 6. Following changes were made in sldap.conf TLSCipherSuite MEDIUM:+SSLv2:+SSLv3:RSA TLSCACertificatePath /opt/openldap/certificate/ TLSCACertificateFile /opt/openldap/certificate/cacert.pem TLSCertificateFile /opt/openldap/certificate/servercrt.pem TLSCertificateKeyFile /opt/openldap/certificate/serverkey.pem # Use the following if client authentication is required TLSVerifyClient demand 7.Similarly a new certificate for client was created using client’s details such as host name etc 8.Signed by the previously created CA On the client side: 1. Following changes were made in ldap.conf HOST spsdel192 PORT 636 TLS_CACERTDIR/etc/openldap/certs TLS_REQCERT demand TLS_CACERT /etc/openldap/certs/cacert.pem Finally when executing [root@spsdel193 ~]# ldapsearch -v -Z -D cn=root,o=ShawEnterprise -w secret -b o=accounts,o=shawEnterprise ldap_initialize( <DEFAULT> ) ldap_start_tls: Connect error (-11) additional info: TLS error -12227:SSL peer was unable to negotiate an acceptable set of security parameters. ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) [root@spsdel193 ~]# Any solution to resolve this issue would be of great help. Thanks in advance. Regards Vidya

9 years, 11 months

2
1
0 / 0

Re: Recovering from a Single-Node downtime in a Multi-Master Setup

by Marco Nett

2013/12/10 Quanah Gibson-Mount <quanah(a)zimbra.com> > --On Tuesday, December 10, 2013 11:08 AM -0600 espeake(a)oreillyauto.comwrote: > > Do the slapcat on ldap2 and then delete the db files on ldap1 and then run >> the slapadd. you will not get duplicates because all of the CSN's will be >> the same. This is what I have done my migrations to the most recent >> versions and doing my own builds. Works great that way. >> > So by "delete the db files" you mean deleting the contents of the slapd home-dir (usually /var/lib/ldap)? Here's what I read out of your answer: (ldap2) slapcat -bcn=config -l config.ldiff (ldap2) slapcat -l actual-data.ldiff (ldap1) rm -rf /var/lib/ldap/* (ldap1) /etc/init.d/slapd start (ldap1) slapadd -bcn=config -l config.ldiff (ldap1) slapcat -l actual-data.ldiff Like this? Any traps or common problems I should be aware of? > > Huh? > > The CSNs contain the server IDs. Servers ignore their own changes. > You're saying I shouldn't delete the files before doing the cat/add business, right? If I'd do it like this, wouldn't stuff that got deleted on ldap2 (while ldap1 was down) still end up being on ldap1?

9 years, 11 months

3
2
0 / 0

Custom attribute values created prior to an index are not getting indexed by slapindex

by Jon C Kidder

I am running 2.4.36 with mdb and have discovered an interesting behavior that may be a bug but wanted some input before I opened an ITS. I can upgrade to .38 and verify the behavior if needed. I have a third party application that defines the following custom attribute: olcAttributeTypes: ( 1.3.6.1.4.1.8241.1.15 NAME 'ctscPropertyKeywords' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) I have recently added the following index to the database for this application: olcDbIndex: ctscPropertyKeywords pres,eq When I run a search using objectclass as a filter I see 17 records that contain the value "Exportable" for ctscPropertyKeywords. When I repeat the search using (ctscPropertyKeywords=Exportable) as the filter I only get back 9 records even though the value is present in 17 records. I have included examples of my searches and the results below. I have run slapindex on this database several times since the new index was added using: /appl/openldap/sbin/slapindex -v -F /appl/openldap/etc/openldap/slapd.d -b "dc=global,dc=aep,dc=com" I have also restarted slapd several times just for grins. The behavior has not changed. I have discovered that the 9 records I see have been modified since the index was created and the missing 8 records existed before the index was created. Modifying a record causes the index to get updated and adds the record to the results of my second search but re-indexing the database using slapindex does not. Any thoughts? Here are my sample searches and their output. /appl/openldap/bin/ldapsearch -H "ldap://localhost:389" -x -D {removed} -y {removed} -s sub -b 'dc=Global,dc=aep,dc=com' '(objectClass=ctscPropertyDefinition)' objectClass ctscPropertyKeywords # extended LDIF # # LDAPv3 # base <dc=Global,dc=aep,dc=com> with scope subtree # filter: (objectClass=ctscPropertyDefinition) # requesting: objectClass ctscPropertyKeywords # # 1102, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=1102,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Glo bal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable # 1103, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=1103,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Glo bal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable # 1104, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=1104,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Glo bal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable # 4305, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=4305,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Glo bal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable ctscPropertyKeywords: HelpDeskAccessible # 16802, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=16802,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable ctscPropertyKeywords: HelpDeskAccessible # 16803, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=16803,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable ctscPropertyKeywords: HelpDeskAccessible # 16804, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=16804,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable ctscPropertyKeywords: HelpDeskAccessible # 16805, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=16805,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable ctscPropertyKeywords: HelpDeskAccessible # 16806, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=16806,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable ctscPropertyKeywords: HelpDeskAccessible # 16808, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=16808,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable ctscPropertyKeywords: HelpDeskAccessible # 16810, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=16810,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable ctscPropertyKeywords: HelpDeskAccessible # 16813, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=16813,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable ctscPropertyKeywords: HelpDeskAccessible # 16814, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=16814,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable ctscPropertyKeywords: HelpDeskAccessible # 17702, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=17702,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable # 17703, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=17703,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable # 17803, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=17803,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable # 18902, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=18902,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable ctscPropertyKeywords: HelpDeskAccessible ctscPropertyKeywords: MultiValued # search result search: 2 result: 0 Success # numResponses: 18 # numEntries: 17 /appl/openldap/bin/ldapsearch -H "ldap://localhost:389" -x -D {removed} -y {removed} -s sub -b 'dc=Global,dc=aep,dc=com' '(ctscPropertyKeywords=Exportable)' objectClass ctscPropertyKeywords # extended LDIF # # LDAPv3 # base <dc=Global,dc=aep,dc=com> with scope subtree # filter: (ctscPropertyKeywords=Exportable) # requesting: objectClass ctscPropertyKeywords # # 1103, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=1103,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Glo bal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable # 1104, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=1104,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Glo bal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable # 4305, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=4305,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Glo bal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable ctscPropertyKeywords: HelpDeskAccessible # 16808, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=16808,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable ctscPropertyKeywords: HelpDeskAccessible # 16810, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=16810,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable ctscPropertyKeywords: HelpDeskAccessible # 17702, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=17702,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable # 17703, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=17703,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable # 17803, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=17803,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable # 18902, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=18902,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable ctscPropertyKeywords: HelpDeskAccessible ctscPropertyKeywords: MultiValued # search result search: 2 result: 0 Success # numResponses: 10 # numEntries: 9 -Jon C. Kidder American Electric Power Middleware Services Email: jckidder(a)aep.com<mailto:jckidder@aep.com> Phone: 614-716-4970

9 years, 11 months

1
0
0 / 0

Replicating cn=config in configuration tool

by Daniel J

Hi Openldap gents/ladies, For those who migrated over to cn=config and are replicating cn=config as well as other DIT using configuration tools like cfengine, puppet, chef etc... I have currently have set up to not replicate cn=config for the following reasons: - flexibility to run different cn=config if needed for testing/for a specific purpose - able to reduce the scope of changes that may be disastrous Curious to know how others have implemented and theirs reasoning behind his/hers implementation. Your comments and advise are very welcome. Thanks

9 years, 11 months

1
0
0 / 0

LTB DOWNLOAD

by Borresen, John - 0442 - MITLL

Sorry, if this is not the forum to post this issue...but...received the following error when downloading the LTB Packages: Is this ok [y/N]: y Downloading Packages: openldap-ltb-2.4.38-1.el5.x86_64.rpm | 3.9 MB 00:01 Running rpm_check_debug Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Error in PREIN scriptlet in rpm package openldap-ltb-2.4.38-1.el5.x86_64 error: %pre(openldap-ltb-2.4.38-1.el5.x86_64) scriptlet failed, exit status 1 error: install: %pre scriptlet failed (2), skipping openldap-ltb-2.4.38-1.el5 Failed: openldap-ltb.x86_64 0:2.4.38-1.el5 Complete! John D. Borresen (Dave) Linux/Unix Systems Administrator MIT Lincoln Laboratory

9 years, 11 months

2
1
0 / 0

Recovering from a Single-Node downtime in a Multi-Master Setup

by Marco Nett

Quick question: State 1: - I have two OpenLDAP slapd servers (ldap1 and ldap2) configured as Multi-master. - The both have the exact same data between the mirrored directories. - If I create a new directory entry on one server, it immediately gets mirrored to the second server. - I'm happy. State 2: - One LDAP-Master (ldap1) is down because of whatever. - Changes to the directory are made on the LDAP-Master which is still up (ldap2). - Changes are not mirrored to ldap1 because it's down. - I'm a little worried but still happy. State 3: - ldap1 is back up and running, but it's directory is not up to date. - The changes made to ldap2 in state 2 are not on ldap1 and aren't getting replicated automatically. - Mirroring again works fine, but ldap1 still doens't know about changes made in state 2. - I'm confused because I can't seem to find any information on how to recover from this. I couldn't just delete the directory on ldap1 and import the one from ldap2 because the importing would also be mirrored to ldap2. right? how would i go about recoverying from a downtime in a multi-master setup?

9 years, 11 months

4
6
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical December 2013