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