[S] DNS Domain change and NSR

From: Tom Webster <webster_at_ssdpdc.lgb.cal.boeing.com>
Date: Tue, 21 Oct 1997 11:02:10 -0700

Hi,

Another late summary from me. Here is the original question:

----- snip ----- snip ----- snip ----- snip ----- snip -----
We are faced with having to change the DNS domain names on all of our
systems and we are still working out the impacts that these changes
will have on our day-to-day operations.

One of the areas that concerns us the most is the change's affect on
our backups. We are currently using DEC's NSR product to backup
about 20 systems, including an array of UNIX variants and a few
WinNT servers.

We are currently hoping that just adding the new FQDN of the client to
the list of hostname aliases in the client setup and adding the new
names of the servers to the list of authorized servers on the clients
will be sufficient.

I'm sure someone else has had to do this before, and we would like
to benefit from your experience in this matter. Are our plans
sufficient, or are we missing something?

Our servers are:

   AlphaServer 8400, DU 3.2g, NSR 4.2a
      TL812 Jukebox
      Archive Server
      Clients: DU, HP/UX, WinNT, Oracle (DMO2.0 run on remote system)
   AlphaServer 2100, DU 4.0b, NSR 4.2b
      2 TZ887 Jukeboxes
      DMO2.0 Running locally
      Clients: DU, HP/UX, IRIX, SunOS, WinNT, Oracle

Domain names:
   Old: mdc.com
   New: ???.???.boeing.com

   The first two parts of the domain name haven't been formally
   presented to us yet, but all of the rumored versions have four parts
   to them in addition to the hostname.

We are also interested in hearing about any other gotcha's involved
with changing the DNS domain names on DU systems.
----- snip ----- snip ----- snip ----- snip ----- snip -----

Thanks to:

Saul Tannenbaum <stannenb_at_emerald.tufts.edu>
William H. Magill <magill_at_isc.upenn.edu>

Who both responded in a timely fashion. I've been waiting to add our
experiences, but having grasped the scope of the changes, the higher-ups
have put the domain name change on hold indefinitely.

Here are Saul and William's replies:

On Sat, 2 Aug 1997, Saul Tannenbaum wrote:
----- snip ----- snip ----- snip ----- snip ----- snip -----
We had to do this on one system, and Digital CSC provided us with a
very comprehensive list, including NSR issues, to go by. If you have
a support contract, it's worth making the call.
----- snip ----- snip ----- snip ----- snip ----- snip -----

Unfortunatly the list in question was part of the personal toolkit of
one of the CSC techs, and has since been lost tothe world as the tech
moved on to greener pastures.

On Mon, 4 Aug 1997, William H. Magill wrote:
----- snip ----- snip ----- snip ----- snip ----- snip -----
We're forever changing domain names and addresses for systems around here.

Typically because we build a new system with name xxx; migrate the users
from yyy; and then rename xxx to be yyy; and rename yyy to be zzz.

The file /etc/rc.config contains the parts that need to be changed.
Personally, I am an advocate of rebooting once a week period. So I make the
changes and then reboot.

Some of the files/app-configs that will change/need to be changes which
come to mind are:

/etc/rc.config
sendmail.cf
/etc/resolv.conf
mph
decevent
dsnlink

Only dsnlink is really evil. You do need to completely re-install it.
(ie re-configure the bloody thing. You can try doing it manually, but I
find it's just faster and easier to use the DSNlink admin tool.)

There may be others, but the first 3 are what you need to get up and
running with a new name/address. (I'm assuming that somebody is doing the
DNS prep work independently, including MX records and Cnames etc.)

Now for nsr....
We have not done it correctly because I still haven't figured out how NSR
is really supposed to work. The "easy" thing to do is to add an alias
to the client record to allow the old "hostname" (which is the index files)
to still access the newly re-named host.

I don't know how one would maintain the dual naming over time in the NSR
database. We just use NSR for system backups - no user level archive
storage. So we only have a 2 month tape rotation cycle.... BIG difference
in the potential headaches! I can see many kinds of NSR problems relating
to trying to recover files 6 months from now which were saved under the
old name, and to be recoverd to the new.

And last but not least, ?obviously? firewalls routers and similar critters
will provide you with countless hours of joy because they only know about
the old (or new) names at the wrong times. (and heaven help you if you have
PCs that need to be re-configured....)
----- snip ----- snip ----- snip ----- snip ----- snip -----

Thanks again for the replies and the information. Sorry the summary was so
long in coming, but I thought we would have some information to add.

Tom
--
+-----------------------------------+---------------------------------+
| Tom Webster                       |  "Funny, I've never seen it     |
| SysAdmin MDA-SSD ISS-IS-HB-S&O    |   do THAT before...."           |
| webster_at_ssdpdc.lgb.cal.boeing.com |   - Any user support person     |
+-----------------------------------+---------------------------------+
|      Unless clearly stated otherwise, all opinions are my own.      |  
+---------------------------------------------------------------------+
Received on Tue Oct 21 1997 - 20:30:51 NZDT

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:37 NZDT