Very Computer

1. Make the new NIS+ root master a client of the old NIS+ root master.

2. Make the new NIS+ root master a NIS+ replica, using
   nismkdir -s newmaster on all directories..

2a. Wait at least 12 hours and make sure, the changes have propagated
    to the NIS_COLDSTART file on every client.

3. Make the new NIS+ root master the NIS+ master server for using
   nismkdir -m newmaster onm all directories.

3a. Again wait at least 12 hours till the changes have propagated to
    all clients. I am not sure, what will happen to modify requests,
    sind to the old master during this time. In doubt don't change
    anything during this time.

4. Remove the NIS+ directories from the old root master using
   nisrmdir -s oldmaster.

4a. Once again 12 more houres until the changes have propagated.

5. Now you can remove the old master from the network and use it for
   any purpose, you like.

Remember to always make a backup of /var/nis on the master server
(backing in up on the replicas, too is no miskate), before doing
experiments like this. It is also a good idea to create ASCII files
from the tables using nisaddent -d.

I also have to mention that I never did this procedure. I never had to
move a NIS+ root master server.

And one more problem, I ran into. I once wanted to add a new
replica. This failed, because I used FQDNs in the host tables cname
field. After changing is to a simple hostname, I was able to to add
the replica. This is the reason, why I prefer DNS lookups on hosts
over NIS+ lookups.

73, Mario
--

Institut fuer Robotik und Prozessinformatik der TU Braunschweig
Hamburger Strasse 267, 38114 Braunschweig, Germany

Just a comment.  If you use 'nischttl' first to lower the Time To live on
the NIS+ directory objects (including org_dir and groups_dir) you do NOT have
to wait 12 hours twice, (just the first time you do it).  You can reset the
TTL's to 12 hours later if you like.

Another even simpler method for this problem is to build a 2.5.1 machine
and then rename it to the the oldmaster's name (including the IP address, the
/etc/.rootkey and copy over the /var/nis directory).  This replacement is
much faster so long as you do not have to change the servers IP address.

=wpm    William P. Malloy       SunSoft         Networking

: Just a comment.  If you use 'nischttl' first to lower the Time To live on
: the NIS+ directory objects (including org_dir and groups_dir) you do NOT have
: to wait 12 hours twice, (just the first time you do it).  You can reset the
: TTL's to 12 hours later if you like.

: Another even simpler method for this problem is to build a 2.5.1 machine
: and then rename it to the the oldmaster's name (including the IP address, the
: /etc/.rootkey and copy over the /var/nis directory).  This replacement is
: much faster so long as you do not have to change the servers IP address.

I think there is a difference between the 2.4 and 2.5.1 nis+ directory
structure. Am I correct to assume that 2.5.1's nis+ server can read the
/var/nis directory from 2.4 machine or will do the conversion automatically
if it sees the old directory structure?

Thanks.

Best regards,

King Ho
Global Link Information Services Ltd.

=wpm    William P. Mallot       SunSoft         Networking

Two comments:

In article <5e217o$6s...@unix2.glink.net.hk>, kin...@glink.net.hk (King Chung Ho) writes:

Actually, I did what you proposed first: Moving NIS+ from one host to another
(without waiting 12 hours twice!). There is a description on how to do that
available from the NIS+ FAQ (http://www.eng.auburn.edu/users/rayh/solaris/NIS+_FAQ.html), but be careful
with that ... there are a couple of bugs. I'll append this document including
some notices I made while I was doing the procedure (actually I did it three
times):

...

I attached the document as I received it from Sun
and included some comments in lines starting with '!'. The old lines
are preceeded by a '<' the new once by a '>'.

----- Begin Included Message -----

INFODOC ID: 11742
STATUS: Issued

SYNOPSIS: How to convert a NIS+ root replica server to a root master server.
DETAIL DESCRIPTION:

Use the following steps if you need to convert one of your root replica
servers to be the root master server:

< NOTE: In the following examples, <master> indicates the name of the old
< master server, <replica> indicates the name of the old replica server,
! this sounds nice but obviously there appears 'old master' 'new replica'
! and even 'master' when the old replica is meant. So we should better
! call the old master 'hostA' and the old replica 'hostB'

        ps -ef|grep <processname>

All other punctuation should be typed as written.

1 - Create master's objects for replica:

<        On Master machine:
<        # nsmkdir -m <replica> groups_dir.`domainname`.
<        # nsmkdir -m <replica> org_dir.`domainname`.
<        # nsmkdir -m <replica> `domainname`.

3 - Kill rpc.nisd and nis_cachemgr on both master and replica:

4 - Restart rpc.nisd and nis_cachemgr on the new replica server:

<        On new replica machine:

< 5 - Access the domainname directory and verify that the old replica is
< now the master:

6 - If the contents of the cache still shows the old master server to be
the old master, do the following on the new master:

! I'm really not sure whether the following work always. The first time I tried it, I made
! what the original document said and I know that this did *not* work. What I'm sure about
! is that 'nismkdir' does not work without the rpc.nisd being startet
<        # nsmkdir -m <hostB> groups_dir.`domainname`.
<        # nsmkdir -m <hostB> org_dir.`domainname`.

<        # for tables in `nisls org_dir groups_dir`
<        > do
<        > nischown <master> $tables
<        > done
! The above certainly does not work. This should do what we wanted ...

niscat -o org_dir
niscat -o hosts.org_dir  etc...

10 - Remove the old replica from replicating the directory structures

11 - Checkpoint the domain

13 - Check as users and root that all is well.
! This advice is really great! A good check would be ...

16 - On each client, kill nis_cachemgr

        # kill <nis_cachemgr pid>

17 - On each client, get a new coldstart file from the new master server ...

read more »

Quote:>>Greetings all!
>>From what I have read, it doesn't appear to be an easy way to upgrade
>>from 2.4 to 2.5.1 without breaking NIS+, and moving the NIS+ master
>>doesn't seem terribly easy, either.  So, the solution that I'm planning
>>is to export the relevant NIS+ tables into flat files, completely
>>remove NIS+ from the network, and then do a fresh install of NIS+ on
>>newmaster (Unless anyone can suggest a better alternative).  FYI: We've
>>only got about 20 NIS+ clients on the network, so removing NIS+ and then
>>reinitializing the clients from the new server shouldn't be TOO much
>>work...
>Doing this you'll loose all your credentials ... everybody gets 'nisplus'
>as nis+-password.

I agree with Neil's post - as long as you reload the 2.4 cred table with
nispopulate and copy over the /etc/.rootkey file you should be fine,
right? Please tell me this is so because I have to upgrade a 2.4 machine
to 2.5.1 in the near future and I wasn't planning on needing Divine
Intervention to get it to work right.

Now, changing the IP address of the master server is another matter. The
clients have this in their configuration, so if you ever need to change
the IP of the master server you are in deep doo doo.

-w

Bah!  If you change a NIS+ master's IP address don't worry about
the fact that all his clients contain the IP address.  Be concerned
about the fact that the IP encrypts into the creds and that the NIS+
master will no longer be authenticated to connect to itself anymore.

I believe Sun has an SRDB out on this, anyone know the number?
-Scott