Re: Promoting two replicas to master/replica

[Mark Reynolds <mareynol@xxxxxxxxxx>]

On 07/31/2016 11:47 AM, Gary Algier wrote:

Here I am answering my own question...

On a new day, with fresher eyes, I used Wireshark to capture the traffic leaving the client for each possible server.  I found an error when the Solaris client queried the 389ds server that was not there for the Solaris ds server:

    searchResDone(2) insuffientAccessRights (VLV Control)

after some Googling, I found the following:
    https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Creating_Indexes-Creating_VLV_Indexes.html

It turns out one needs to create browse indices and more importantly, allow anonymous access to them (or bind with any valid user -- a much more involved fix).

Right, vlv indexes, and other configurations are not replicated.  So, make sure there are not other configurations are need to be migrated.  This is easier said than done, but I would look through your server config file from the Solaris server(dse.ldif) and do some comparison with the 389-ds-base config file (/etc/dirsrv/slapd-INSTANCE/dse.ldif).  While SunDS(ODSEE) and 389-ds-base were based off the same source code from 10+ years ago it has significantly diverged.  So what you see in DSEE will not match 100% with 389-ds-base and visa-versa, but you should look through them and look for things like cache sizes, indexed attributes, password policy, etc.

Good luck,
Mark

Now, we move on...

On Sat, Jul 30, 2016 at 4:50 PM, Gary Algier <gaalists@xxxxxxxxx> wrote:

Mark:

Thanks for the information.  I got as far as step [2] and ran into a road block.

Linux clients work fine, Solaris clients not so fine.

I started pointing my clients to server B, but now that I am trying to get Solaris 10 clients to work, a "getent passwd" will not list everyone. If I type "getent passwd someuser", they show.  People can login just fine.  But there is no way to enumerate the passwd database.  I have several scripts that perform a "getent passwd" to get a full list of users and they are all failing.

I am using a DUAConfigProfile from before with the following contents:
----------------------------------------------------------------------------------------------------------
dn: cn=default,ou=profile,dc=example,dc=com
defaultserverlist: 172.25.0.1
defaultsearchscope: sub
serviceSearchDescriptor: passwd:ou=People,dc=example,dc=com?sub?objectclass=po
 sixAccount
serviceSearchDescriptor: shadow:ou=People,dc=example,dc=com?sub?objectclass=sh
 adowAccount
serviceSearchDescriptor: group:ou=Group,dc=example,dc=com?sub?objectclass=posi
 xGroup
objectClass: top
objectClass: DUAConfigProfile
defaultsearchbase: dc=example,dc=com
searchtimelimit: 30
profilettl: 43200
cn: default
credentiallevel: anonymous
bindTimeLimit: 10
authenticationmethod: none
followreferrals: TRUE
serviceauthenticationmethod: pam_ldap: simple
----------------------------------------------------------------------------------------------------------

The IP address 172.25.0.1 is the old server (A).  With this setting, "getent passwd" will list everyone.  If I change that to the IP address of server B, it will only list people in the /etc/passwd file.

I ran tcpdump on server B while trying a "getent passwd" and there is no traffic.

Oh, and the /etc/nsswitch.conf on Solaris says:
----------------------------------------------------------------------------------------------------------
passwd: files ldap
group:  files ldap
----------------------------------------------------------------------------------------------------------

Any ideas why identical content, but on a different server, would result in not being able to enumerate?  And only for Solaris 10 clients?

Gary

On Thu, Jul 28, 2016 at 4:54 PM, Mark Reynolds <mareynol@xxxxxxxxxx> wrote:

Hi Gary

On 07/28/2016 03:55 PM, Gary Algier wrote:

Hello,

I have an old directory server (Sun's) as a master and it is replicating to two slave 389 servers.  I want to pull the plug on the old server and promote one of the replicas to a master.

Here's what it looks like:

• Server A, running old DS.   Master.
  
• Server B, running 389 DS.  Consumer of A.
• Server C, running 389 DS.  Consumer of A.

I want:

• Server B, running 389 DS. Master.
• Server C, running 389 DS. Consumer of B.

What's the easiest way to make this happen with minimal (0?) downtime?

My guess would be I should first make C and consumer of B.  But how do I easily "promote" B?

All the docs I find talk about multimaster.

There is some documentation on this:

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Making_a_Replica_Updatable.html
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/removing-supplier-cleanly.html


Anyway, this is actually pretty easy and there should not be any down time.

[1] First, you need to convert Server B to a Master.  Follow these steps

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Configuring-Replication-cmd.html#Configuring-Replication-Suppliers-cmd

Basically you are just creating a change log and updating the replication configuration. 

If there are any agreements to Server A remove them.

[2]  Then you need to start pointing your clients to Server B, as opposed to Server A

[3]  Decommission Server A:  Remove the agreements if nothing else!

[4]  Run the cleanAllRUV task to remove the old rid (replica ID) that came from Server A

http://www.port389.org/docs/389ds/howto/howto-cleanruv.html

[5]  Initialize Server C:

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Initializing_Consumers.html#Initializing_Consumers-Online_Consumer_Initialization_cmd

If you have a large database you might want to do a LDIF file initialization:

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Initializing_Consumers.html#Initializing_Consumers-Manual_Consumer_Initialization_Using_the_Command_Line


Regards,
Mark

I don't think I am ready to go there yet.

--

Gary Algier

--
389-users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/389-users@xxxxxxxxxxxxxxxxxxxxxxx

--
389-users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/389-users@xxxxxxxxxxxxxxxxxxxxxxx

--

Gary Algier

--

Gary Algier

--
389-users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/389-users@xxxxxxxxxxxxxxxxxxxxxxx

--
389-users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/389-users@xxxxxxxxxxxxxxxxxxxxxxx