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).

Now, we move on...




On Sat, Jul 30, 2016 at 4:50 PM, Gary Algier <gaalists@gmail.com> 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@redhat.com> 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@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org


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




--
Gary Algier



--
Gary Algier