Re: [389-users] Clarification on admin server and console

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>
>> There is still some haziness in my mind about the admin server...
>>
>> I setup a server called master01 using setup-ds-admin.pl and then setup another physical server called master02 also using setup-ds-admin.pl. The only difference >was that I "registered" master02 with master01. The effect is that when I run 389-console from the command line logging into either master01 or master02 I get both >master01 and master02 listed in the directory tree. Each one has a server group with an admin server and directory server listed. However the admin server for >master02 points to master01 by default when looking at the settings.
>>
>Right.  Unfortunately, the admin server/console do not failover
>automatically to another configuration directory server.  But see this -
>http://www.redhat.com/docs/manuals/dir-server/8.2/admin/html/Managing_Replication-Replicating-ADS-for-Failover.html

Thanks for the link, I have tried doing it but I am running into problems... when trying to do it at setup.
The relevant part of my inf file looks as follows:

[slapd]
ServerIdentifier = 389-master01
ServerPort = 389
AddOrgEntries = No
RootDN = cn=Directory Manager
RootDNPwd = secret
SlapdConfigForMC = yes
Suffix = dc=betfair
UseExistingMC = 0
AddSampleEntries = No
ConfigFile = repluser.ldif
ConfigFile = changelog.ldif
ConfigFile = replica.ldif
ConfigFile = replagreement.ldif

repluser gets added fine but the last 3 ldif files fail for the following reason in the log file:

+Processing repluser.ldif ...
+++check_and_add_entry: Entry not found cn=replication manager,cn=config error No such object
+Entry cn=replication manager,cn=config is added
+Processing changelog.ldif ...
+++check_and_add_entry: Entry not found cn=changelog5,cn=config error No such object
+++check_and_add_entry: attepting to add the entry cn=changelog5,cn=config that does not exist
+Processing replica.ldif ...
+++check_and_add_entry: Entry not found cn=replica,cn=o\3Dnetscaperoot,cn=mapping tree,cn=config error No such object
+++check_and_add_entry: attepting to add the entry cn=replica,cn=o\3Dnetscaperoot,cn=mapping tree,cn=config that does not exist
+Processing replagreement.ldif ...
+++check_and_add_entry: Entry not found cn=test-aggreement-name,cn=replica,cn=o\3Dnetscaperoot,cn=mapping tree,cn=config error No such object
+++check_and_add_entry: attepting to add the entry cn=test-aggreement-name,cn=replica,cn=o\3Dnetscaperoot,cn=mapping tree,cn=config that does not exist


I am not sure what I am doing wrong, probably something obvious...
changelog.ldif
~~~~~~~~~
dn: cn=changelog5,cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
cn: changelog5
nsslapd-changelogdir: /var/lib/dirsrv/slapd-389-master01/changelogdb
nsslapd-changelogmaxage: 10d

replica.ldif
~~~~~~~
dn: cn=replica,cn=o\3Dnetscaperoot,cn=mapping tree,cn=config
changetype: add
objectClass: top
objectClass: nsDS5Replica
cn: replica
nsDS5ReplicaRoot: o=netscaperoot
nsDS5ReplicaId: 1
nsDS5ReplicaType: 3
nsDS5Flags: 1
nsds5ReplicaPurgeDelay: 604800
nsDS5ReplicaBindDN: cn=Replication Manager,cn=config

replagreement.ldif
~~~~~~~~~~~~
dn: cn=test-aggreement-name,cn=replica,cn=o\3Dnetscaperoot,cn=mapping tree,cn=config
changetype: add
objectClass: top
objectClass: nsDS5ReplicationAgreement
cn: test-aggreement-name
description: test-description
nsDS5ReplicaHost: 389-master02.example
nsDS5ReplicaPort: 389
nsDS5ReplicaBindDN: cn=Replication Manager
nsDS5ReplicaBindMethod: SIMPLE
nsDS5ReplicaRoot: o=netscaperoot
nsDS5ReplicaTransportInfo: TLS
nsDS5ReplicaCredentials: {DES}blahblah


I noticed that the netscaperoot db only gets created long after the ldif files were attempted to be added. It is then understandable that they would fail since the object does not yet exists. Is there a way of having ldif files executing later or am I doing it wrong or interpreting the debug information incorrectly?

I used setup-ds-admin.pl --silent -f setup-master01.inf -dd to test.

Best Regards

________________________________________________________________________
In order to protect our email recipients, Betfair Group use SkyScan from 
MessageLabs to scan all Incoming and Outgoing mail for viruses.

________________________________________________________________________
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users


[Index of Archives]     [Fedora Directory Users]     [Fedora Directory Devel]     [Fedora Announce]     [Fedora Legacy Announce]     [Kernel]     [Fedora Legacy]     [Share Photos]     [Fedora Desktop]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Big List of Linux Books]     [Gimp]     [Yosemite News]

  Powered by Linux