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:
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(a)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(a)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...
>
>
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10...
>
>
> 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...
>
> 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...
>
> 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...
>
>
> Regards,
> Mark
>
> I don't think I am ready to go there yet.
>
>
> --
> Gary Algier
>
>
> --
> 389-users mailing
list389-users@lists.fedoraproject.orghttps://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
>
>
>
> --
> 389-users mailing list
> 389-users(a)lists.fedoraproject.org
>
>
https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject...
>
>
--
Gary Algier