My original post was a request for information on migrating users from one NIS+ domain to another
without loosing their current passwords. Using information provided from the replies to my post, I
wrote a script to migrate my users. The script I created and my original post can be found below.
Although the script I created used portions of all of their suggestions, my script most closely
matches instructions that Willi Burmeister provided.
My thanks to:
Willi Burmeister (email@example.com)
Balamunrugan Krishnan (firstname.lastname@example.org)
The following script (o2z) moves a specified user from one NIS+ domain to another. The script
should be run on the root master of the domain the user is moving to. The script requires that the
root master on the new domain has root rsh permissions on the old root master. A NIS+ ping is
required after the script is run. Although this example moves users from a sub-domain into the root
master, it works equally as well when moving users from one root domain to another root domain.
------------- Begin Included Message -------------
# Program: o2z
# By: William Kuderka
# Check for required field on command line
if [ $# -ne 1 ]
echo "o2z: invalid number of arguments"
echo "usage: o2z [uname]"
# When making changes, look for the hard coded domain names in the SED
# statements used during the public and private key conversion.
echo User $uname from $FROM
# This script assumes the users exists in the old domain. It
# may make unpredictable entries in the new domain if no user
# is found in the old.
# Get user info from old domain
passwd=`rsh quasi /usr/lib/nis/nisaddent -d -M passwd $FROM|grep "^$uname:"`
UID=`echo $passwd|grep "^$uname:"|cut -d":" -f3`
shadow=`rsh quasi /usr/lib/nis/nisaddent -d -M shadow $FROM |grep "^$uname:"`
netid=`rsh quasi /usr/lib/nis/nisaddent -d -M netid $FROM|grep "^unix.$UID@"`
publickey=`rsh quasi /usr/lib/nis/nisaddent -d -M publickey $FROM |grep "^unix.$UID@"`
auto_home=`rsh quasi /usr/bin/niscat -M auto_home.org_dir.$FROM|grep "^$uname "`
# Convert user public and private key for new domain
# THE SED STATEMENTS ARE HARD CODED
echo Converting $uname with uid $UID to $TO
newnetid=`echo $netid|sed -e 's/omp.Zenith.att./Zenith.att./g'`
# Note: Publickey does not have the trailing period
newpublickey=`echo $publickey|sed -e 's/omp.Zenith.att/Zenith.att/g`
# Add user info to new domain
echo Adding to $TO
echo $passwd |/usr/lib/nis/nisaddent -a passwd $TO
echo $shadow |/usr/lib/nis/nisaddent -a shadow $TO
echo $netid |/usr/lib/nis/nisaddent -a netid $TO
echo $newpublickey|sed -e 's/::/:/g' |/usr/lib/nis/nisaddent -a publickey $TO
echo $auto_home|/usr/lib/nis/nisaddent -a -t auto_home.org_dir key-value $TO
------------- End Included Message -------------
My orginal post to the group:
> NIS+ admins:
> We currently have a NIS+ domain with a sub-domain. Our building is undertaking a
> "lan optimization" which will require us to change the IP addresses of all of
> our systems. The domain/sub-domain environment has always been an administrative
> nightmare so we are looking to consolidate the existing domains into one new
> domain (with a new name) while changing the IP address of the new domain master
> and eventually changing the IP addresses of 30+ servers and 105+ workstations.
> I've read several FAQ's from Sun and others which discuss changing the IP
> address of the domain master. Based on the information provided it seems that we
> should be able to bring up a new NIS+ master for the new domain with the new IP
> and then dump the tables from the old domain masters and use the nispopulate
> command to populate the new tables.
> The one drawback to this method seems to be that the nispopulate command can't
> populate the cred table so it changes the existing creds (and subsequently the
> passwrods) to a default of "nisplus".
> Does anyone know of a way to populate the passwd and cred tables using the
> existing passwd and cred information? Our goal would be to keep the existing
> client passwords in the new domain (resetting user passwords for 300+ users
> would cause a lot of unhappy clients). Please keep in mind that the names of
> the existing domains would be changing.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:13:19 CDT