[Date Prev][Date Next]
Re: 2.0.27 replicating to 2.2.15
Thank you for the reply.
Pierangelo Masarati wrote:
This was only temporary. In order to convert the backend to Berkley I
did a slapcat/slapadd and was using replication across the versions to
keep the 2.2 server up to date until it could be placed in service as
the master. However I see now that did not work. Problem is, I cannot
afford the downtime to slapadd the new 2.2 master.
Curt Blank wrote:
I've got a 2.0.27 server set up as Master replicating via slurp to a
2.2.15 slave server.
In general, replicating across etherogeneous servers is a bad idea,
but read thru the whole answer.
Modifications are being replicated properly but adds are not, the new
dn is not added, I see this error message:
bdb_add: entry failed schema check: no structuralObjectClass
operational attribute (80)
because 2.2 slaves expect the operational attr structuralObjectClass
to be passed for adds.
Unfortunately I do have updatedn and rootdn set the same. I see in
the 2.2 documentation that shouldn't be done but the existing
environment is 2.0 and it was not a constraint there, at least
according to the the 2.0 Admin Manual.
That's a suggestion for security's sake, not a constraint.
So, anyone know if making the updatedn and rootdn different will
solve this problem?
No, it's totally unrelated.
Thanks. I will work towards changing that but at least I know it is not
And the intention is to replace the 2.0 Master with the 2.2 server as
Master then the 2.2 Master will be replicating to 2.0 servers until
they are upgraded to 2.2. It is being done this way as a rolling
upgrade because we cannot afford the luxury of an ldap outage.
The other way round, i.e. a 2.2 master replicating to 2.0 slaves
should be easier because in 2.2 you can filter out the operational
attributes that the 2.2 master routinely generates but earlier slaves
wouldn't accept. The topic has already been iscussed, you may find
something by browsing the mail archives. In any case, you need to
look at the "attr" parameter of the "replica" statement in 2.2's
slapd.conf(5) man page.
This is the intent for only as long as it takes to rotate in slaves
upgraded to 2.2 once the Master was at 2.2. So, will
attr!=structuralObjectClass work when replicating from a 2.2 Mater to a
2.0 Salve? (Short term.) Should there be a structuralObjectClass:
account associated with every dn in the database or is that just used
for replication protocol?
To be able to get the 2.2 server running temporarily as a slave so I can
slapadd it and then get replication from the 2.0 server, how hard/risky
would it be for me to modify the code so that the 2.2 server bypasses
this requirement? (Temporarily, until it is installed as the Master.) Or
would this not be recommended at all?
Just as a sidebar, I was wondering if you would explain why this
structuralObjectClass: account for replication was added? Is it
something I really need?
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497