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....
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(a)gmail.com
<mailto: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(a)redhat.com <mailto: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...
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 list
> 389-users(a)lists.fedoraproject.org
> <mailto:389-users@lists.fedoraproject.org>
>
https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject...
--
389-users mailing list
389-users(a)lists.fedoraproject.org
<mailto:389-users@lists.fedoraproject.org>
https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject...
--
Gary Algier
--
Gary Algier
--
389-users mailing list
389-users(a)lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject...