Well, I discovered a small error in my summary. Below is the corrected plan
(Might as well save someone else the pain...). Ignore the first summary.
Basically, you have to swap my steps 5 and 6 and create the nonstandard
key-value tables (like auto_direct) as a "normal" user who is a member of the
admin group. Otherwise the group ownership of the tables will be wrong and the
group permissions of the tables will be wrong. Things will still work, but
you'll only be able to edit the tables are root, which is not good.
Clem
wckarl@bu.edu
Steps to changing a root domain name under NIS+.
Overview: Basically the root domain must be removed then recreated
through 5 steps:
1) Dump existing NIS+ tables to files using nisaddent -d
Also back up /var/nis for safety and to bail if necessary
2) Remove existing NIS+ setup on root master via rm /var/nis, rm
/etc/.rootkey
3) Reinstall NIS+ on root master using nisserver -r -d NEWDOMAINNAME
4) Repopulate the tables from the dumped files via nisaddent or
nispopulate
5) Update the clients by similarly first removing the current NIS+
configuration info (rm /var/nis, rm /etc/.rootkey), then reinitalizing
via nisclient -v -i
Excrutiating Step by Step Details of what I did:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Step 1: Dump existing NIS+ tables to files and back up /var/nis
a) Login to root master as root and make backup of /var/nis
# TMPDIR=/tmp
# export TMPDIR
# ufsdump 0f $TMPDIR/nis-backup/nis-dump /var/nis
# cp /etc/.rootkey $TMPDIR/nis-backup/dot.rootkey
Move the ufsdump to someplace safe (since /tmp may be wiped if a reboot
is necessary).
b) Now dump the tables (can be done as a member of admin group):
i) First the standard tables plus the cred information. Cred info is
contained in netid and publickey:
setenv TMPDIR /tmp
foreach t (aliases bootparams ethers group hosts netgroup \
netmasks networks passwd protocols rpc services shadow timezone)
echo $t
/usr/lib/nis/nisaddent -d $t > $TMPDIR/nis-tables/$t
end
ii) Now dump the cred information. This will enable us to reconstruct
the credentials later. The cred information is kept in netid and
publickey (see below).
setenv TMPDIR /tmp
foreach t ( netid publickey )
echo $t
/usr/lib/nis/nisaddent -d $t > $TMPDIR/nis-cred/$t
end
iii) Now the key-value tables (like the automount tables). For us:
foreach t (auto_master auto_home auto_local auto_direct sendmailvars)
echo $t
/usr/lib/nis/nisaddent -d -t $t.org_dir key-value > $TMPDIR/nis-tables/$t
end
c) Backup /etc/nsswitch.conf and /etc/init.d/rpc since nisserver will
alter them (well at least /etc/init.d/rpc. I'm not sure about
nsswitch.conf):
# cp /etc/nsswitch.conf /etc/nsswitch.bak
# cp /etc/init.d/rpc /etc/init.d/rpc.bak
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Step 2: On root master, change domainname and Purge the old NIS+
information (as root):
# domainname NEWDOMAINNAME
# domainname > /etc/defaultdomain
# sh
# /etc/init.d/rpc stop
# rm -f /etc/.rootkey
# rm -rf /var/nis/*
# /etc/init.d/rpc start
Note: Sometimes the rpc shutdown can take some time.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Step 3: On root master, create the NIS+ root server from scratch
a) Create server
# /usr/lib/nis/nisserver -v -r -d NEWDOMAINNAME
This creates the new root master for the new domain name and, in
particular creates new credentials for the new root master (but only the
root master).
b) Restore rpc and nsswitch
# cp /etc/init.d/rpc.bak /etc/init.d/rpc
# cp /etc/nsswitch.bak /etc/nsswitch.conf
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Step 4: On root master, reload the standard tables and the cred info
There now appear to be a number of ways to go. I only used Option 2, but
will also outline the "simpler" (though more user pain) Option 1.
Option 1: Simpler: Just reload the info and lose user and workstation
creds, which then must be recreated for each user separately :(
a) Populate the standard tables
# /usr/lib/nis/nispopulate -v -F -p $TMPDIR/nis-tables
This will populate the auto_master, auto_home, ethers, group, hosts,
networks, passwd, protocols, services, rpc, netmasks, bootparams,
net-group, aliases and shadow tables.
b) The above populate process creates credentials for all users and
hosts in the hosts table. However, the network passed created for all
the users is "nisplus" and thus needs to be changed. In particular,
*every* user should now run "keylogin" with the new network password
("nisplus") then do a "chkey" to change the network password to their
login password. This is the downside to this approach. In addition, the
nispolulate command will create credentials for *all* the hosts in the
hosts file, all with the network password "nisplus".
Option 2: More complicated up front, but less work later (I think): Play
some games with the dumped files to preserve the existing
credentials. Avoids users having to resynch their passwords and avoids
creating creds for all hosts. There are appearently a number of
equivalent ways to do this, from not creating the credentials to begin
with to creating new credentials but then overwriting them with the old
information. Heres what I did:
a) Populate the standard tables:
# TMPDIR=/tmp
# export TMPDIR
# /usr/lib/nis/nispopulate -v -F -p $TMPDIR/nis-tables -S 0
The standard tables get reloaded. The "-S 0" option prevents creation of
the standard credentials (with "nisplus" password) for workstations
listed in the hosts file and users listed in the password file. Thus at
the end of this step the only DES/network credentials that exist are for
the root master server.
b) Make copies of the previously dumped cred files (netid and
publickey). netid controls LOCAL credentials, and thus only contains
users. publickey controls DES credentials and thus contains both users
and workstations.
# cp $TMPDIR/nis-cred/netid $TMPDIR/nis-cred/netid.bak
# cp $TMPDIR/nis-cred/publickey $TMPDIR/nis-cred/publickey.bak
c) Edit netid and do a global replacement of the old NIS+ domain name
for the new NIS+ domain name, using e.g. vi.
d) Edit publickey and delete the credentials for the root master
workstation from the publickey file. Specifically, delete the line starting:
unix.MASTERSERVERNAME@OLDDOMAINENAME .....
This will prevent overwriting the credentials which were newly created
in Step 3 when the publickey file is loaded.
e) Edit publickey and do a global replacement of the old NIS+ domain
name for the new NIS+ domain name (as in 2c), using e.g. vi.
At this point, netid holds the previous local creds and publickey holds
the DES creds for every workstation and individual EXCEPT the root
master.
f) Reload the edited cred files to restore the missing credential info:
# /usr/lib/nis/nisaddent -av -f $TMPDIR/nis-cred/publickey publickey
# /usr/lib/nis/nisaddent -av -f $TMPDIR/nis-cred/netid netid
This will populate the cred table with the old credentials for all users
and workstations except for the new root master server. At this point
all users should exist on the master server with their old credentials.
Note: make sure you use the "-a" option. If you use the "-m" option
stuff not in the files are deleted from the tables -- in particular the
newly created root master creds will be deleted. I made this mistake.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Step 5: Add users to admin group, since they have been erased
in the server recreation:
# nisgrpadm -a admin USER1.NEWDOMAINNAME.
# nisgrpadm -a admin USER2.NEWDOMAINNAME.
Now administration can be done as nonroot, which we will need next.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Step 6:
Populate any nonstandard "key-value" tables. The tables must first be
(re)created by hand using nistbladm and only then can they be
restored. For example to restore our direct and indirect automounter
maps:
a) Create the tables. Note: Appearently this should be done as a normal
user who is a member of the admin group, or else group ownership and
permissions will not be correct. I discovered this the hard way:
nistbladm -c automount_map key=S value=S auto_direct.org_dir.NEWDOMAINNAME.
nistbladm -c automount_map key=S value=S auto_local.org_dir.NEWDOMAINNAME.
b) Verify the tables exist:
nisls org_dir
nisls org_dir
c) Populate them from the files:
/usr/lib/nis/nispopulate -v -F -p $TMPDIR/nis-tables auto_direct
/usr/lib/nis/nispopulate -v -F -p $TMPDIR/nis-tables auto_local
d) Verify the tables:
niscat -v auto_direct.org_dir
niscat -v auto_local.org_dir
e) Reboot
# init 6
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Step 7: Fix up the client machines. Do the following on each client
machine:
a) Change domainname and remove old NIS+ setup
# domainname NEWDOMAINNAME
# domainname > /etc/defaultdomain
# /etc/init.d/rpc stop
# rm -f /etc/.rootkey
# rm -rf /var/nis/*
# /etc/init.d/rpc start
b) Backup /etc/nsswitch.conf and /etc/init.d/rpc since nisclient will
alter them:
# cp /etc/nsswitch.conf /etc/nsswitch.bak
# cp /etc/init.d/rpc /etc/init.d/rpc.bak
c-1) For Option 1 above: the old workstation credentials have been lost
and must be recreated. I think you do the following (but haven't tested
this):
On the root master, for each client do:
# nisclient -o -c client_name
Then on each the client, do:
nisclient -i -d NEWDOMAINNAME. -h ROOTMASTER.COM
c-2) For Option 2 above: We have hopefully preserved the workstation
creds, which will just need reinitializing
On each client do:
# /usr/lib/nis/nisclient -v -i -d NEWDOMAINNAME. -a 128.197.57.120 -h ROOTMASTER
d) Restore rpc and nsswitch
# cp /etc/init.d/rpc.bak /etc/init.d/rpc
# cp /etc/nsswitch.bak /etc/nsswitch.conf
e) Reboot the client machine
# init 6
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Final notes:
a) The NIS+ caches will persist through a reboot, so you may want to
force it to purge the old information (I don't know if it matters):
# ps -ef|grep nis_cachemgr
# kill PID
# /usr/sbin/nis_cachemgr -i
b) To function properly the permissions on /var/nis must be 755, owned
by root and group sys. If this is not the case you may get the error
"NIS+ servers unreachable" when doing e.g. nisls org_dir. If normal
users get this error but root doesn't, the problem is probably the
permissions on /var/nis
c) We have no replicas and only a single domain, so I haven't worried
about those issues.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:01 CDT