FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Directory

 
 
LinkBack Thread Tools
 
Old 08-12-2010, 08:06 PM
Jonathan Boulle
 
Default Clarification on admin server and console

I've been trawling through the documentation trying to get a better
understanding of "best practices" for use of the console and admin
server in an environment with a large number of directory servers. In
the perfect scenario, we would like to be able to manage the entire
estate (multiple locations) using one instance of the console; or
perhaps one console per location. Unfortunately I'm not finding it
straightforward.

I understand that on a (physical/virtual) server there can be multiple
directory server instances but only one admin server instance. However,
what I'm wondering is whether it is possible for an instance of the
admin server to manage directory servers on different boxes. For
example, could I have one admin server per location - where a location
houses X physical servers each running a DS instance (a mix of read-only
consumers and read-write suppliers)? This brings obvious benefits as
regards easier backup and a single point of administration, but also
becomes a bit of a single point of failure.

If not, is it necessary/standard to run an admin server per physical
server, and then group them in the console by having them all share a
single configuration server (as specified in setup-ds-admin.pl)?
Although again this creates a single POF, at least with administration -
or have I got the wrong end of the stick entirely?

One more point: the Console and Admin Server documentation has diagrams
which reference "external programs"; what kind of things does this refer
to? Is there a typical use case?

Thanks
Jonathan

__________________________________________________ ______________________
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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 08-12-2010, 08:21 PM
Jonathan Boulle
 
Default Clarification on admin server and console

I've been trawling through the documentation trying to get a better understanding of "best practices" for use of the console and admin server in an environment with a large number of directory servers.* In the perfect scenario, we would like to be able to manage the entire estate (multiple locations) using one instance of the console; or perhaps one console per location. Unfortunately I'm not finding it straightforward.
*
I understand that on a (physical/virtual) server there can be multiple directory server instances but only one admin server instance. However, what I'm wondering is whether it is possible for an instance of the admin server to manage directory servers on different boxes. For example, could I have one admin server per location - where a location houses X physical servers each running a DS instance (a mix of read-only consumers and read-write suppliers)? This brings obvious benefits as regards easier backup and a single point of administration, but also becomes a bit of a single point of failure.
*
If not, is it necessary/standard to run an admin server per physical server, and then group them in the console by having them all share a single configuration server (as specified in setup-ds-admin.pl)? Although again this creates a single POF, at least with administration - or have I got the wrong end of the stick entirely?
*
One more point: the Console and Admin Server documentation has diagrams which reference "external programs"; what kind of things does this refer to? Is there a typical use case?
*
Thanks
Jonathan


__________________________________________________ ______________________

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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 08-13-2010, 02:46 PM
Rich Megginson
 
Default Clarification on admin server and console

Jonathan Boulle wrote:
>
> I've been trawling through the documentation trying to get a better
> understanding of "best practices" for use of the console and admin
> server in an environment with a large number of directory servers. In
> the perfect scenario, we would like to be able to manage the entire
> estate (multiple locations) using one instance of the console; or
> perhaps one console per location. Unfortunately I'm not finding it
> straightforward.
>
>
>
> I understand that on a (physical/virtual) server there can be multiple
> directory server instances but only one admin server instance.
> However, what I'm wondering is whether it is possible for an instance
> of the admin server to manage directory servers on different boxes.
> For example, could I have one admin server per location - where a
> location houses X physical servers each running a DS instance (a mix
> of read-only consumers and read-write suppliers)? This brings obvious
> benefits as regards easier backup and a single point of
> administration, but also becomes a bit of a single point of failure.
>
There must be an admin server on the physical machine that hosts the
directory server. Some of the admin server tasks are CGI based e.g.
certificate management, log viewing, server stop/start/restart. These
cannot be done remotely.
>
>
>
> If not, is it necessary/standard to run an admin server per physical
> server, and then group them in the console by having them all share a
> single configuration server (as specified in setup-ds-admin.pl)?
> Although again this creates a single POF, at least with administration
> - or have I got the wrong end of the stick entirely?
>
>
>
> One more point: the Console and Admin Server documentation has
> diagrams which reference "external programs"; what kind of things does
> this refer to? Is there a typical use case?
>
I'm not sure (can you provide a URL?) but the "external programs" are
probably the aforementioned CGI programs.
>
>
>
> Thanks
>
> Jonathan
>
>
> __________________________________________________ ______________________
> 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@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 08-16-2010, 12:44 PM
Gerrard Geldenhuis
 
Default Clarification on admin server and console

>> I understand that on a (physical/virtual) server there can be multiple
>> directory server instances but only one admin server instance.
>> However, what I'm wondering is whether it is possible for an instance
>> of the admin server to manage directory servers on different boxes.
>> For example, could I have one admin server per location - where a
>> location houses X physical servers each running a DS instance (a mix
>> of read-only consumers and read-write suppliers)? This brings obvious
>> benefits as regards easier backup and a single point of
>> administration, but also becomes a bit of a single point of failure.
>>
>There must be an admin server on the physical machine that hosts the
>directory server. Some of the admin server tasks are CGI based e.g.
>certificate management, log viewing, server stop/start/restart. These
>cannot be done remotely.

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.

I have a configured client that authenticates against master02 and then fails over to master01. If I shutdown master01(shutdown -h now) and restart master02 I am still able to authenticate from the client server or at least get results for getent passwd.

master02 does not have a netscaperoot so that seems shared if you register master02 with master01.

Now for my question, I have read above that you have said that we must have an admin server on each physical server. I believe we have... I can do a service dirsrv-admin start/stop/restart on master02.
* So what does the "registration" during installation actually do?
* I registering one physical server to another physical server a bad idea as I described above.
* What is the reliance of master02 on master01. I did notice that I can't start the 389-console at all if master01.dirsrv service is not running.

We plan to have quite a number of servers and it would be nice to have a "centralized control panel" where you can easily access all servers and select servers from a drop down box when setting up replication agreements. Thus what I have experimented with above is basically trying to achieve this control panel but I would like to be sure that it is done correctly. The other concern is that we don't want to introduce a central point of failure for the convenience of having a centralized control panel.

>>
>>
>>
>> If not, is it necessary/standard to run an admin server per physical
>> server, and then group them in the console by having them all share a
>> single configuration server (as specified in setup-ds-admin.pl)?
>> Although again this creates a single POF, at least with administration
>> - or have I got the wrong end of the stick entirely?
>>
>>
>>
>> One more point: the Console and Admin Server documentation has
>> diagrams which reference "external programs"; what kind of things does
>> this refer to? Is there a typical use case?
>>
>I'm not sure (can you provide a URL?) but the "external programs" are
>probably the aforementioned CGI programs.


http://www.redhat.com/docs/manuals/dir-server/8.2/console/html/chap-Console_Guide-Introducing_Red_Hat_Console_and_Administration_Ser ver.html
Figure 1.2 was what Jonathan referred to.

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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 08-16-2010, 02:57 PM
Rich Megginson
 
Default Clarification on admin server and console

Gerrard Geldenhuis wrote:
>>> I understand that on a (physical/virtual) server there can be multiple
>>> directory server instances but only one admin server instance.
>>> However, what I'm wondering is whether it is possible for an instance
>>> of the admin server to manage directory servers on different boxes.
>>> For example, could I have one admin server per location - where a
>>> location houses X physical servers each running a DS instance (a mix
>>> of read-only consumers and read-write suppliers)? This brings obvious
>>> benefits as regards easier backup and a single point of
>>> administration, but also becomes a bit of a single point of failure.
>>>
>>>
>> There must be an admin server on the physical machine that hosts the
>> directory server. Some of the admin server tasks are CGI based e.g.
>> certificate management, log viewing, server stop/start/restart. These
>> cannot be done remotely.
>>
>
> 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
> I have a configured client that authenticates against master02 and then fails over to master01. If I shutdown master01(shutdown -h now) and restart master02 I am still able to authenticate from the client server or at least get results for getent passwd.
>
Right. Regular LDAP clients don't know anything about the admin
server/console.
> master02 does not have a netscaperoot so that seems shared if you register master02 with master01.
>
It's "sort of" shared.
> Now for my question, I have read above that you have said that we must have an admin server on each physical server. I believe we have... I can do a service dirsrv-admin start/stop/restart on master02.
> * So what does the "registration" during installation actually do?
>
It allows you to see both servers at the same time in the console i.e.
centralized administration. Otherwise, if you set up every master to be
its own configuration directory server, you have to connect the console
to each master, and can only use the console to manage one server at a time.
> * I registering one physical server to another physical server a bad idea as I described above.
>
I don't understand the question.
> * What is the reliance of master02 on master01. I did notice that I can't start the 389-console at all if master01.dirsrv service is not running.
>
Right. See the link I posted above.
> We plan to have quite a number of servers and it would be nice to have a "centralized control panel" where you can easily access all servers and select servers from a drop down box when setting up replication agreements. Thus what I have experimented with above is basically trying to achieve this control panel but I would like to be sure that it is done correctly. The other concern is that we don't want to introduce a central point of failure for the convenience of having a centralized control panel.
>
See the link I posted above.
>
>>>
>>> If not, is it necessary/standard to run an admin server per physical
>>> server, and then group them in the console by having them all share a
>>> single configuration server (as specified in setup-ds-admin.pl)?
>>> Although again this creates a single POF, at least with administration
>>> - or have I got the wrong end of the stick entirely?
>>>
>>>
>>>
>>> One more point: the Console and Admin Server documentation has
>>> diagrams which reference "external programs"; what kind of things does
>>> this refer to? Is there a typical use case?
>>>
>>>
>> I'm not sure (can you provide a URL?) but the "external programs" are
>> probably the aforementioned CGI programs.
>>
>
>
> http://www.redhat.com/docs/manuals/dir-server/8.2/console/html/chap-Console_Guide-Introducing_Red_Hat_Console_and_Administration_Ser ver.html
> Figure 1.2 was what Jonathan referred to.
>
Yes, the external programs are the admin server CGI programs.
> 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@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 08-17-2010, 11:08 AM
Gerrard Geldenhuis
 
Default Clarification on admin server and console

>>
>> 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=o3Dnetscaperoot,cn=mapping tree,cn=config error No such object
+++check_and_add_entry: attepting to add the entry cn=replica,cn=o3Dnetscaperoot,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=o3Dnetscaperoot,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=o3Dnetscaperoot,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=o3Dnetscaperoot,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=o3Dnetscaperoot,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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 08-17-2010, 11:12 AM
Gerrard Geldenhuis
 
Default Clarification on admin server and console

I forgot to add that all the ldifs works if I run them afterwards just not during installation.

This string also baffled me a bit:
cn=replica,cn=o3Dnetscaperoot,cn=mapping tree,cn=config

what does the o3Dn mean?

I sourced it from the audit log when doing the change in the GUI.

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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 08-17-2010, 02:15 PM
Rich Megginson
 
Default Clarification on admin server and console

Gerrard Geldenhuis wrote:
> I forgot to add that all the ldifs works if I run them afterwards just not during installation.
>
> This string also baffled me a bit:
> cn=replica,cn=o3Dnetscaperoot,cn=mapping tree,cn=config
>
> what does the o3Dn mean?
>
See http://www.ietf.org/rfc/rfc4514.txt
> I sourced it from the audit log when doing the change in the GUI.
>
> 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@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 08-17-2010, 02:22 PM
Rich Megginson
 
Default Clarification on admin server and console

Gerrard Geldenhuis wrote:
>>> 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
>
This means it was successfully 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=o3Dnetscaperoot,cn=mapping tree,cn=config error No such object
> +++check_and_add_entry: attepting to add the entry cn=replica,cn=o3Dnetscaperoot,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=o3Dnetscaperoot,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=o3Dnetscaperoot,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=o3Dnetscaperoot,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=o3Dnetscaperoot,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
>
You should add the nsDS5ReplicaCredentials as clear text and let the
server encrypt it.

This is a bug - if you remove the changetype: add it should work.
Please file a bug about this issue.
>
> 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?
>
This is a bug - it should work if you remove the changetype: add
> 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@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 08-17-2010, 03:42 PM
Gerrard Geldenhuis
 
Default Clarification on admin server and console

>> replagreement.ldif
>> ~~~~~~~~~~~~
>> dn: cn=test-aggreement-name,cn=replica,cn=o3Dnetscaperoot,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
>>
>You should add the nsDS5ReplicaCredentials as clear text and let the
>server encrypt it.
>
>This is a bug - if you remove the changetype: add it should work.
>Please file a bug about this issue.

Will file bug shortly. It still however does not work when I remove the changetype: add line.
Adding the replication user works,
Enabling the changelog works
but enabling the replica fails.
I have changed the ldif slightly to:

dn: cn=replica,cn="o=NetscapeRoot",cn=mapping tree,cn=config
objectClass: top
objectClass: nsDS5Replica
objectclass: extensibleObject
cn: replica
nsDS5ReplicaRoot: o=NetscapeRoot
nsDS5ReplicaId: 1
nsDS5ReplicaType: 3
nsDS5Flags: 1
nsds5ReplicaPurgeDelay: 604800
nsDS5ReplicaBindDN: cn=Replication Manager,cn=config


The log file:

+Entry cn=changelog5,cn=config is added
+Processing 03replica.ldif ...
+++check_and_add_entry: Entry not found cn=replica,cn="o=NetscapeRoot",cn=mapping tree,cn=config error No such object
+ERROR: adding an entry cn=replica,cn="o=NetscapeRoot",cn=mapping tree,cn=config failed, error: No such object
dn: cn=replica,cn="o=NetscapeRoot",cn=mapping tree,cn=config
objectclass: top
objectclass: nsDS5Replica
objectclass: extensibleObject
cn: replica
nsds5replicaroot: o=NetscapeRoot
nsds5replicaid: 1
nsds5replicatype: 3
nsds5flags: 1
nsds5replicapurgedelay: 604800
nsds5replicabinddn: cn=Replication Manager,cn=config

+ERROR: There was an error processing entry cn=replica,cn="o=NetscapeRoot",cn=mapping tree,cn=config
+Cannot continue processing entries.
Error adding entry 'cn=replica,cn="o=NetscapeRoot",cn=mapping tree,cn=config'. Error: No such object
Error: Could not create directory server instance '389-master01'.
Exiting . . .


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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 

Thread Tools




All times are GMT. The time now is 08:29 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org