openldap-technical

openldap-technical@openldap.org

9 participants
9868 discussions

Re: Upgrading from Ubuntu-packaged 2.4.28 to self-built 2.4.38
by Philip Colmer 12 Dec '13

12 Dec '13

> You only responded about one My second paragraph addressed the second suggestion. I did *try* to edit the LDIF file and then use slapadd but it wasn't working. In retrospect, the reason it wasn't working was because I didn't have the correct slapadd command-line options. Therefore, I think that I didn't need to sym-link and that slapcat/slapadd was the appropriate way to go. On 12 December 2013 16:54, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Thursday, December 12, 2013 4:20 PM +0000 Philip Colmer > <philip.colmer(a)linaro.org> wrote: > >>> Huh? Why didn't you just use ldapmodify to modify it? Or, slapcat your >>> cn=config db, fix it in the LDIF, and reload it? >> >> >> Couldn't use ldapmodify to modify it because slapd wasn't running. >> Couldn't use ldapmodify to modify it whilst Ubuntu version was >> installed because that would break *that* version. Couldn't use >> ldapmodify to modify it whilst new version was installed because new >> version wouldn't start. > > > I listed two options. The other works when slapd is offline. You only > responded about one. > > > --Quanah > > > -- > > Quanah Gibson-Mount > Architect - Server > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: Upgrading from Ubuntu-packaged 2.4.28 to self-built 2.4.38
by Philip Colmer 12 Dec '13

12 Dec '13

> Huh? Why didn't you just use ldapmodify to modify it? Or, slapcat your cn=config db, fix it in the LDIF, and reload it? Couldn't use ldapmodify to modify it because slapd wasn't running. Couldn't use ldapmodify to modify it whilst Ubuntu version was installed because that would break *that* version. Couldn't use ldapmodify to modify it whilst new version was installed because new version wouldn't start. I think, in retrospect, that I was hitting two problems - the wrong path in cn=config and the wrong command to try and build a new cn=config from LDIF. It is possible that the correct command (which I eventually found in another mail thread) avoids this whole issue. On 12 December 2013 16:14, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Thursday, December 12, 2013 1:40 PM +0000 Philip Colmer > <philip.colmer(a)linaro.org> wrote: > >> dn: cn=module{0} >> objectClass: olcModuleList >> cn: module{0} >> olcModulePath: /usr/lib/ldap >> olcModuleLoad: {0}back_hdb >> >> olcModulePath, if defined, is referenced INSTEAD OF any environment >> variables like PATH or LD_LIBRARY_PATH. >> >> /usr/lib/ldap is the Ubuntu path. The new location is >> /usr/local/libexec/ldap. Since I can't edit the ldif file, I put in a >> symbolic link. > > > Huh? Why didn't you just use ldapmodify to modify it? Or, slapcat your > cn=config db, fix it in the LDIF, and reload it? > > --Quanah > > -- > > Quanah Gibson-Mount > Architect - Server > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration

2 1

Upgrading from Ubuntu-packaged 2.4.28 to self-built 2.4.38
by Philip Colmer 12 Dec '13

12 Dec '13

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

4 5

Running slapcat and slapd at the same time
by Chris Card 12 Dec '13

12 Dec '13

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

2 1

please fix ITS#6825
by Michael Ströder 12 Dec '13

12 Dec '13

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.

1 0

OPENLDAP BUILD/CONFIGURE
by Borresen, John - 0442 - MITLL 11 Dec '13

11 Dec '13

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>

4 6

2 way SSL configuration in OpenLDAP 2.4
by vidya bharadwaj 11 Dec '13

11 Dec '13

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

2 1

Re: Recovering from a Single-Node downtime in a Multi-Master Setup
by Marco Nett 11 Dec '13

11 Dec '13

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?

3 2

Custom attribute values created prior to an index are not getting indexed by slapindex
by Jon C Kidder 11 Dec '13

11 Dec '13

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

1 0

Replicating cn=config in configuration tool
by Daniel J 11 Dec '13

11 Dec '13

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

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