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).https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Creating_Indexes-Creating_VLV_Indexes.html
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:
There is some documentation on this:All the docs I find talk about multimaster.My guess would be I should first make C and consumer of B. But how do I easily "promote" B?What's the easiest way to make this happen with minimal (0?) downtime?Hello,Here's what it looks like:
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.
- 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.
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
