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/ht...

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/ht...

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/ht...

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/ht...

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/ht...

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

-- 389-users mailing list 389-users@lists.fedoraproject.org

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

On 07/31/2016 11:47 AM, Gary Algier wrote:

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/h...

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@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@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/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
    <mailto: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
    <mailto:389-users@lists.fedoraproject.org>
    https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org




-- 
Gary Algier

-- Gary Algier

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