Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!rice!sun-spots-request
From: merlyn@iwarp.intel.com (Randal Schwartz)
Newsgroups: comp.sys.sun
Subject: Re: Changing Client IP Address
Keywords: Networks
Message-ID: <8761@brazos.Rice.edu>
Date: 11 Jun 90 17:37:28 GMT
Sender: root@rice.edu
Organization: Sun-Spots
Lines: 44
Approved: Sun-Spots@rice.edu
X-Refs:  Original: v9n205
X-Sun-Spots-Digest: Volume 9, Issue 205, message 7

In article <8715@brazos.Rice.edu>, woodb!tkevans@cs writes:
| 
| Now, however, we have a shiny new domain name and Class B IP address.  As
| a result, I need to change all the IP addresses we have been using.  When
| I made changes in the /etc/hosts file on the server machines, everything
| went ok, but the clients could not find the server to boot up.  They were
| able to get their (new) IP address from the server, but couldn't boot.
| 
| There doesn't seem to be anything in TFM about how to _change_ an existing
| client's IP address...

Yeah, I just went through renaming 14 uVaxen and 50 Suns (Sun 3, Sparc,
Sun-386, with about 30 diskless clients) from our old class C to our new
class B net number.

Here's what I had to do:

 1. Disable the three YP slave servers, because they would have the old
    hosts entries, and there's no way to force an update in sync with the
    world.  This required deleting /var/yp/`domain-name` on each slave and
    editing the 'ypservers' map on the master.
 2. Halt all the clients.
 3. Unmount all the NFS disks from the YP master.
 4. Halt all machines except the YP master.
 5. Edit /etc/hosts, /etc/netmasks, /etc/networks on the YP master.  (Don't
    forget to cd /var/yp && make.)
 6. Reboot the YP master.  (slow, because it tried to mount all those
    disks...)
 7. Reboot everything but the clients.
 8. Rename all /tftpboot/AABBCC12 files on all boot servers to
    /tftpboot/DDEEFF12, where AABBCC was the old net number in hex, and DDEEFF
    was the new net number.
 9. Boot the clients.
10. Add the three slave YP servers back.

Took me a good long day.  Step 8 was the hardest... I couldn't figure out
why the clients weren't booting.  I sp'ose it's documented down in the
bowels somewhere, but I didn't have it in front of me.

Just another (tired) sysadmin,

Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095
on contract to Intel's iWarp project, Beaverton, Oregon, USA, Sol III
merlyn@iwarp.intel.com ...!any-MX-mailer-like-uunet!iwarp.intel.com!merlyn