Mister Anonyme wrote:
8.0 had a problem in that it could not register a server with a remote configuration DS. This problem has been fixed in 8.1.Hi,I tried with setup-ds-admin.pl but the configuration files is already present so this setup fails. I forgot to add that I use the version 8.0.
If those docs need to be corrected, please send us the links. Also note that in 8.0: If you want to add new schema to an existing instance, you must add the files to /etc/dirsrv/slapd-instancename/schema, then restart the server for the schema changes to take effect /etc/dirsrv/schema is only for new instances only - existing servers don't use these files schema files are not replicated - the only way to replicate schema is to add the new schema over LDAPAnyway, if I completely re-install two masters servers, configurations files for slaves will be lost. It seems that I don't have a choice to re-install slaves too.As a final word, for those who use 8.0 and are using replication system, don't add a new schema file in /etc/dirsrv/slapd-XXXX/schema. I'll tell you why:I read the docs for DS 8.0 and anywhere it talks about add new schema file but I found it myself by digging in /etc/dirsrv and I tested it in the lab.
With 8.1 you have the ability to add schema files, then have the server reload them without having to restart the server, but the schema files added by copying them to the server instance schema directory will still not be replicated.
Later, when I added a new bunch of users, I noticed that the replication was stopped between two masters, but not between master and slaves. I tried to understand why it doesn't work anymore
Anything in the errors or access logs?
and I found out by reading in 8.1 (the next version that we don't use it yet) documentation that it says that we need to stop all replication before adding a new schema file.
Can you provide a link to the documentation?
I'm not really sure what's going on here. I seriously doubt there is any data corruption happening (unless there is some disk/hardware failure). I would first suggest you check your errors log in /var/log/dirsrv/slapd-instancename/errorsHeh, good to know, but it was already too late.I tried everything like removing/creating replication agreement, removing local database, recreate it, etc, the second master doesn't just want to start the replication. However, the replication between the first master and slaves is working well because I first added a new schema file on the slave, the restarted the slapd. After, I added it on the first master, and then restarted it. In fact, it worked very well until I added a new bunch of users with the new attribute that's only present from the new schema file that I added earlier. Since then, the replication between two master just stopped, even o=netscaperoot isn't replicated anymore.The worst thing is, I first tried adding a new schema in the lab and it worked flawlessly, even when I added some users. I found out that the problem arise only when I restart again one of two masters. In other words, I stop the slapd, I add a new schema, I fire it up. I do the same thing on the second master. It works. I stop again the second, and bam, you lost the replication and you just corrupted some database including the o=netscaperoot.
So, be cautious when you add a new schema file ;-) > Subject: Re: How to restore replica admin in the master > From: jsullivan@xxxxxxxxxxxxxxxxxxx > To: fedora-directory-users@xxxxxxxxxx > Date: Thu, 3 Sep 2009 14:14:04 -0400 > > On Thu, 2009-09-03 at 13:50 -0400, Mister Anonyme wrote: > > Hi, > > > > I have two masters (in multi-master mode, they replicate each other) > > and 6 slaves. > > > > I added a new schema file in /etc/dirsrv/slapd-XXX/schema and I > > restarted all dirsrv. I learned later that I had to stop the > > replication before adding a new schema file. Because of that, the > > netscaperoot seems to be corrupted because I wasn't able to do > > replication between two masters. > > > > So, I had to completely re-install two masters and re-import the > > database but is there a way to re-configure the admin part of each > > replica (slave) servers ? I could completely re-install slaves too > > but if I can reconfigure the admin so I can see all replicas in the > > Redhat Management Console, it would be nice. > > > <snip> > Ouch! I think I understand. Unfortunately, I'm on the run and can't > explore it in detail but here is an excerpt from our internal > documentation on restoring the admin relationship between slave and > master and losing and then restoring the master from the slave database: > > Once the data is restored, we need to tell LDAP1 that it is the > configuration master and that LDAP2 uses it. > On LDAP1 run "register-ds-admin.pl" > Then, on LDAP2 run "setup-ds-admin.pl -u" but, for some reason, it > insists on installing the CA cert and, since it already exists in the > database, it errors. So we first remove the existing CA cert: > cd /etc/dirsrv/admin-serv > certutil -D -d . -n "CA certificate" > then run setup-ds-admin.pl -u and take defaults except we must enter the > path the to CA cert (/etc/dirsrv/admin-serv/MyCA.pem). > > Hope this helps. I think the original threads where Rich Megginson > helped us through this scenario are still in the archive. Good luck - > John > -- > John A. Sullivan III > Open Source Development Corporation > +1 207-985-7880 > jsullivan@xxxxxxxxxxxxxxxxxxx > > http://www.spiritualoutreach.com > Making Christianity intelligible to secular society > > -- > 389 users mailing list > 389-users@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/fedora-directory-users ------------------------------------------------------------------------Faster Hotmail access now on the new MSN homepage. <http://go.microsoft.com/?linkid=9677399>------------------------------------------------------------------------ -- 389 users mailing list 389-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
<<attachment: smime.p7s>>
-- 389 users mailing list 389-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
