[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Trying to set up multimaster syncrepl, error attribute 'olcTLSCertificateFile' not allowed , why?
- To: betsy.schwartz@gmail.com
- Subject: Re: Trying to set up multimaster syncrepl, error attribute 'olcTLSCertificateFile' not allowed , why?
- From: Quanah Gibson-Mount <quanah@zimbra.com>
- Date: Mon, 23 Nov 2015 19:38:07 -0800
- Cc: openldap-technical@openldap.org
- Content-disposition: inline
- Dkim-filter: OpenDKIM Filter v2.9.3 edge02.zimbra.com CA571A617B
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zimbra.com; s=C2AA288C-EE47-11E2-9BB0-E820BDD9BDBF; t=1448336289; bh=FptaBIP+XZ0mQzVlAlrgq84ibZsnt57ns/roFZjZkKs=; h=Date:From:To:Message-ID:MIME-Version; b=bDWIdTJSH8FiBMeO5P6zvJ1ChdNYfExRad3oExdoDYi0e54oqeNn6LhKhyecfO5RL fhPThYJ7ZuqcQzG+UDl+avUn0WGMpTKTxyk3GYiCJq/iIpgpbl7WTowJ3YZx/Mqdm7 2xCld0jZtHD8nK0YvsaZY6e+h7mUQCskxuMoe4ZU=
- In-reply-to: <CAAVLHR1n-VhP3dEEf3Shxgng8tp_R1QVt=3TKQtn5FkRDkuk4w@mail.gmail.com>
- References: <CAAVLHR1+x+DEvN=60jRwfCgWRvxOOTGT-S+2OXb1cZhBj8UU1A@mail.gmail.com> <BA007438D98C7F307BAF7F85@192.168.1.9> <CAAVLHR1n-VhP3dEEf3Shxgng8tp_R1QVt=3TKQtn5FkRDkuk4w@mail.gmail.com>
--On Monday, November 23, 2015 7:12 PM -0500 Betsy Schwartz
<betsy.schwartz@gmail.com> wrote:
On Sat, Nov 21, 2015 at 2:00 PM, Quanah Gibson-Mount <quanah@zimbra.com>
wrote:
I would suggest using slapcat to export the config database and clean up
the invalid attribute values that were incorrectly added to the bdb
database.
Thank you very much! I have made progress but am now in an entertaining
new place (having *overwritten* my database with my overlay files). But
I'm going to go RTFM and see if I can't dig myself out of that one.
Well, generally you would want to do something like:
slapcat -F /path/to/config/db -n 0 -l config.ldif
mv /path/to/config/db somwhere else
mkdir -p /path/to/config/db
modify config.ldif to be correct
slapadd -F /path/to/config/db -n 0 -l config.ldif
That should reload your config db in full, minus what you fixed.
a) Upgrading to a current openldap release
b) Switching to back-mdb, assuming a 64-bit OS.
Thank you! Sigh, 2.4.40 seems to be the latest in the Oracle repo (we are
using Oracle's version of RHEL6). It looks like there have been some
good bug fixes and I'll make the case for going outside the repo.
Sometime in the next couple months these two new servers will become the
primary production servers and then we'll be able to do what we want with
them.
It is extremely ill advised to ever use distro builds. They are not
supported by the OpenLDAP project, and issues with distro builds need to be
taken to the distro provider. I would note that RHEL builds are
particularly bad, as they link to a known insecure and problematic crypto
library that is not supported by the OpenLDAP project.
I also suggest reading over
<http://www.openldap.org/faq/data/cache/1456.html>. It was written some
time ago, but is still completely relevant.
If building OpenLDAP yourself isn't something you really want to get into,
then the LTB project builds
(<http://ltb-project.org/wiki/download#openldap>) are a great starting
point if you don't require support. If you require builds backed by
support, I strongly recommend Symas (http://www.symas.com).
The two old servers, current production, are running 2.4.39 and 2.4.23
(and not syncing with each other!) . I've been hoping that I could sync
data between at least these two new servers and the 2.4.39 server, is
that possible or a foolish hope? Again, once these new ones become
primary I'll be able to keep them identical to each other, but I don't
really 'own' the old ones and don't want to break them. I'm still working
through the manual and the configuration settings.
It's possible, but probably unrealisitc to expect it will work well, given
the significant replication bugs fixed since 2.4.23 in particular.
One more question - still trying to understand what was done on these old
servers - on these servers the config database is 0, the monitor database
is 1 and the bdb database is 2. I can't slapcat the monitor database, is
that normal? I get
slapcat -n 1
slapcat: database doesn't support necessary operations.
This is normal, the monitor database isn't an actual on disk DB. There is
no real configuration for it beyond instantiating it. This is how the
export for it looks from my config DB:
dn: olcDatabase={1}monitor
objectClass: olcDatabaseConfig
olcDatabase: {1}monitor
olcAccess: {0}to dn.children="cn=monitor" by
dn.children="cn=admins,cn=zimbra
" read
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=config
olcMonitoring: FALSE
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration