]> andersk Git - moira.git/commitdiff
Much revision from previous instructions, most of it apparently not
authordkk <dkk>
Tue, 4 Nov 1997 21:52:05 +0000 (21:52 +0000)
committerdkk <dkk>
Tue, 4 Nov 1997 21:52:05 +0000 (21:52 +0000)
checked in before (was named INSTRUCTIONS.new).  Made the instructions
more into a shell script (in several stages).  THIS PROCEDURE WAS USED
in October 1997 to resynchronize the athena.mit.edu AFS cell with Moira.

afssync/INSTRUCTIONS

index 05bc2502c5e168bb6bdaf8cc53171a5e2831a966..f20b6a6ea49651f2d39c647a8c2eeffe1a0b1e59 100644 (file)
-Date: Tue, 26 Jul 1994 14:37:39 -0400
-To: Kimberly Carney <kim@MIT.EDU>
-Cc: dkk@MIT.EDU, op@MIT.EDU
-In-Reply-To: Kimberly Carney's message of Tue, 26 Jul 1994 14:00:29 EDT,
-       <9407261800.AA13079@chich.MIT.EDU>
-Subject: Re: AFS prdb sync'd with Moira 
-From: "Richard Basch" <basch@MIT.EDU>
-
-[ Note: make sure that you have the binaries from afsuser copied
-  locally onto your local machine; also make sure that you have all
-  scripts (see below) copied locally before you start, since AFS may
-  disappear on you.  Altnertiavely, your machine should not be
-  depending on the Athena cell.  For syspacks, root.afs (/afs), etc.
-  Make sure you have superuser tokens for all cells that you might need.]
-
-The binaries are now in /moira/sync/ on the Moira server.
-Most of the commands must be done on the Moira server.
-
-  touch /moira/afs/noafs
-(This gives you some grace time, but watch for critical AFS errors after
-this happens, as you will have to handle those by hand.)
-
-[ 30 minutes after an AFS incrementals starts, they will time out.... 
-       So after that, they will log critical error and then they will
-       have to be done by hand! ]
-
-  /moira/sync/afssync /var/prdb.moira
-(I recommend that you do the following few steps concurrently with this,
-as the "noafs" lock file doesn't give you too much grace time.)
-[ ^^ This takes roughly 20-40 minutes.]
-
-[ Check all PTS servers to make sure they have a consistent versions.
-  Note the PTS database version number, make sure no write
-  transactions are in progress.   "udebug -p 7002".]
-
-  rcp root@orf:/usr/afs/db/prdb.DB0 /var/prdb.old
-(use "udebug <server> -p 7002" before and after to make sure the version
-hasn't changed.)
-
-[ Check to make sure that the version number is the same with udebug.]
-
-  /moira/sync/pt_util -x -m -u -g -d /var/prdb.extra -p /var/prdb.old
-  perl /moira/sync/pt_util.pl < /var/prdb.extra > /var/prdb.extra.sort
-(These two commands extract and prepare the personal groups and special
-user entries in the old prdb for being reincorporated into the new prdb.)
+[This is a still-under-construction rewrite of the afssync
+instructions, adapted to the Ingres/Maxine -> Oracle/SPARC port, and
+is also being updated and simplified.]
+
+
+The executables are in /moira/bin/ on the moira server, with sources
+in /mit/moiradev/src/afssync/.  Most of the commands are run on the
+Moira server.
+
+FULL INSTRUCTIONS
+("SUMMARY" is below)
+
+####   This is preparation for the resync, to save non-Moira users.    ####
+First, get a recent copy of the prdb, and extract non-Moira entries:
+
+       /moira/bin/udebug orf -port 7002
+       rcp root@orf:/usr/afs/db/prdb.DB0 /var/prdb.old
+       /moira/bin/udebug orf -port 7002
+If the two udebugs show that the version changed, lather-rinse-repeat.
+(udebug can be found in afsuser; "orf" here and below is some DB server)
+(Also check for "0 of them for write" at the end.  It might matter.)
+
+       /moira/bin/pt_util -x -m -u -g -d /var/prdb.extra -p /var/prdb.old
+       perl /moira/bin/pt_util.pl < /var/prdb.extra > /var/prdb.extra.sort
+to extract and prepare the personal groups and special user entries in
+the old prdb for being reincorporated into the new prdb.
+
+       awk '/^[^ ][^:]*@/ {printf "KERBEROS:%s\n",$1}' prdb.extra > foreign
+       blanche afs-foreign-users -f foreign
+Get a list of all the @andrew.cmu.edu type (non- athena.mit.edu cell)
+users, and sync the Moira list afs-foreign-users to this list.
+Moira then adds those entries to the group system:afs-foreign-users,
+thus keeping them from being lost in the prdb resync.
+
+       awk '/^[^ ][^:@]*$/ {printf "KERBEROS:%s\n",$1}' prdb.extra > oddities
+       echo "LIST:afs-foreign-users" >> oddities
+       blanche afs-odd-entities -f oddities
+Do the equivalent of afs-foreign-users for domestic users.  We make
+the afs-foreign-users list a member of the more general afs-odd-entities.
+WAIT for the incremental updates from the `blanche` changes to complete.
+
+####   Now the actual resync begins.  Incremental updates must stop.   ####
+
+       touch /moira/afs/noafs
+to disable AFS incremental updates during the synchronization.  The
+afs.incr (?) will wait 30 minutes on an incremental update before
+timing out, so the resync should complete in that time, or list
+changes in Moira might need to be propagated by hand.
+
+       /moira/bin/afssync /var/prdb.moira
+to dump the prdb data that is in Moira (users, groups, and group
+memberships).  This step takes about ten minutes, but can be done
+concurrently with the next few steps.
+
+REPEAT the first two sets of commands, above, thus regenerating
+prdb.extra from a now completely-up-to-date prdb.
 
 *** Make sure the "afssync" command has completed ***
-  cp /var/prdb.moira /var/prdb.new
-  /moira/sync/pt_util -w -d /var/prdb.extra.sort -p /var/prdb.new
-(This almost completes the preparation of the prdb.)
-[ ^^ This takes 40 minutes, may take longer.  Exponentially with
-number of personal groups.]
 
-  pts listmax
-(Save the numbers printed.)
-
-copy /var/prdb.new to *ALL* the database servers (/usr/afs/db/prdb.new)
-
-The following should be done as quickly as possible...
-
-foreach i ( <db servers> )
-  bos shutdown $i ptserver
-  bos exec $i "rm /usr/afs/db/prdb.DB*; mv /usr/afs/db/prdb.new /usr/afs/db/prdb.DB0"
-end
-
-foreach i ( <db servers> )
-  bos restart $i ptserver
-end
-
-Watch the status of the servers using "udebug" to make sure things are
-going well...  make sure the beacons are working, and that once quorom
-is established that the servers are resynchronizing their notions of the
-databases and that the dbcurrent and up fields all become set and the
-state goes to 1f.  Also watch out for large rx packet queues on port
-7002 using rxdebug, as the fileservers may get excessively backlogged,
-and restart servers, if necessary, if the congestion remains excessive.
-
-[ Use udebug on prill.... will take 75 seconds for the pts servers to
-elect a master, and then additional time for the master to propagate
-its database to the rest of the pts servers.]
-
-  pts listmax
-(if the id's are lower than the saved ones, reset them appropriately to
-the saved one's, using "pts setmax").
-
-  pts ex system:administrators
-(good spot check, especially since it has special people)
+       cp /var/prdb.moira /var/prdb.new
+       /moira/bin/pt_util -w -d /var/prdb.extra.sort -p /var/prdb.new
+This use of pt_util will presumably log errors about failed user
+creations and list additions.  (To start over, do both the `cp` and
+`pt_util` again.)  You can filter out the "User or group doesn't exist"
+type of lines that were caused by a user deactivation with something
+like:
+       awk -F\| '$8 == 3 {print $1}' /backup/backup_1/users > /tmp/deactivated
+       perl -e 'for(cat /tmp/deactivated`){ chop; $ex{$_}=1;} \
+               foreach $L (`cat prdb.extra.err`){ $f=0; \
+               @w=split(/[ :]/,$L); for(@w){ $f=1 if $ex{$_}; } \
+               next if $f; print $L; }'
+Now, back to the resync.
+
+       pts listmax > /var/prdb.listmax
+       foreach i ( <db servers> )
+           bos shutdown $i ptserver
+           bos exec $i "rm /usr/afs/db/prdb.DB*; mv /usr/afs/db/prdb.new /usr/afs/db/prdb.DB0"
+       end
+       foreach i ( <db servers> )
+           bos restart $i ptserver
+       end
+
+       /moira/bin/udebug prill -port 7002
+to watch the status of the servers to make sure things are going well,
+where "prill" is preferred db server (the sync site).
+
+Make sure the beacons are working, and that once quorom is established
+(~90 seconds) that the servers are resynchronizing their notions of
+the databases and that the "dbcurrent" and "up" fields all become set
+and the state goes to "1f".  Also, if "sdi" isn't running, watch out
+for large rx packet queues on port 7002 using rxdebug, as the
+fileservers may get excessively backlogged, and restart servers, if
+necessary, if the congestion remains excessive.
+
+       pts listmax
+       cat /var/prdb.listmax
+and if the id maxima are lower than the saved ones, reset them
+appropriately to the saved ones using `pts setmax`.
+
+       pts ex system:administrators
+as a good spot check, especially since it has special people.
 (also spot check one of the personal groups and perhaps, something like
 the membership of rcmd.ronald-ann)
 
-  rm /moira/afs/noafs
-(You need to remove the lock file you put on.)
-
--Richard
-
-***************************************************************************
-
-NOTES:
-
-1. There is also a faster pt_util command for integrating the various personal
-groups.  However, it has not been fully verified.  It can be found in the 
-development sources as pt_util-fast.c.  Feel free to try using this one, but
-I would also recommend generating the database the old way just in case...
+       rm /moira/afs/noafs
+to remove the lock file and let Moira's afs incrementals continue.
 
-2. The goal is to minimize the outage and minimize the potential for changes
-so concurrency is highly recommended.
 
-3. Make sure you copy the database to all the protection servers, as the
-servers will be more than happy to give "no such user" answers and users
-will not be able to reestablish authentic connections without doing
-"aklog -force".
+NOTES
 
-4. Don't do this when you're tired...  There may be no cleanup procedure
+1. Don't do this when you're tired...  There may be no cleanup procedure
 available, with certain mistakes.
 
-5. /moira/afs/noafs is only good for 30 minutes.  Keep track of the
+2. /moira/afs/noafs is only good for 30 minutes.  Keep track of the
 critical log, and you may have to do some operations by hand when the
 operation is complete.  Also, if requests depend on other requests, they
 may be processed out of order, and fail, and may need to be done by hand.
 
-***************************************************************************
 
-(The following is a very old message...)
-
-
-To: op@MIT.EDU, mar@MIT.EDU
-Cc: tjm@MIT.EDU
-Subject: AFS/Moira sync
-From: "Richard Basch" <basch@MIT.EDU>
-
-
-I have rebuilt the AFS protection database from the information in the
-Moira and old prdb (for the special entries and personal groups).  It
-has been installed without a problem.  The old prdb is in
-
-       prill:/usr/afs/db/prdb.old
-
-As usual, I installed it with no interruption of service (there may have
-been a couple minutes when AFS was a bit slow as the protection database
-servers were being restarted, but that's it).
-
-The following is the basic procedure I used to create the new prdb...
-
--Richard
-
-
-moira2# /moira/bin/afssync /var/prdb
-Doing users: Tue Sep  7 23:59:37 1993
-Doing groups: Wed Sep  8 00:16:26 1993
-Error adding group system:mit id -101: Entry for id already exists
-Error adding group system:authuser id -102: Entry for id already exists
-Error adding group system:administrators id -204: Entry for id already exists
-Reading/preparing members: Wed Sep  8 00:30:11 1993
-Doing members: Wed Sep  8 00:34:22 1993
-Done (16591 users, 18144 groups, 23 kerberos, 39097 members): Wed Sep  8 00:41:10 1993
+SUMMARY
+
+       # db servers with sync site first:
+set db=(prill agamemnon chimera orf)
+set u="/moira/bin/udebug -port 7002 -server"
+set prefix="/moira/sync/prdb"
+cd `dirname $prefix`
+
+#######    The following DOES NOT WORK currently.  pt_util needs fixing
+####   BEFORE Moira and afs.incr are closed off:
+       # repeat as necessary:
+$u $db[2]; rcp root@$db[2]\:/usr/afs/db/prdb.DB0 $prefix.old; $u $db[2]
+/moira/bin/pt_util -x -m -u -g -d $prefix.extra -p $prefix.old
+awk '/^[^ ][^:]*@/ {printf "KERBEROS:%s\n",$1}' $prefix.extra > extra.foreign
+blanche afs-foreign-users -f extra.foreign
+awk '/^[^ ][^:@]*$/ {printf "KERBEROS:%s\n",$1}' $prefix.extra > extra.domestic
+echo "LIST:afs-foreign-users" >> extra.domestic
+blanche afs-odd-entities -f extra.domestic
+
+####   WAIT for the above afs.incr events to take place (see moira.log)
+touch /moira/afs/noafs
+/moira/bin/afssync $prefix.moira >& $prefix.afssync.err &
+       # repeat as necessary:
+$u $db[2]; rcp root@$db[2]\:/usr/afs/db/prdb.DB0 $prefix.old; $u $db[2]
+/moira/bin/pt_util -x -m -u -g -d $prefix.extra -p $prefix.old
+perl /moira/bin/pt_util.pl < $prefix.extra > $prefix.extra.sort
+wait
+more $prefix.afssync.err
+cp $prefix.moira $prefix.new
+/moira/bin/pt_util -w -d $prefix.extra.sort -p $prefix.new >& $prefix.extra.err
+       # and review $prefix.extra.err
+
+pts listmax > $prefix.listmax
+set dbdir=/usr/afs/db
+foreach i ( $db )
+    echo "$i..."
+    rcp -px $prefix.new ${i}:$dbdir
+end
+foreach i ( $db )
+    bos shutdown $i ptserver
+    bos exec $i "rm $dbdir/prdb.DB*; mv $dbdir/prdb.new $dbdir/prdb.DB0"
+end
+foreach i ( $db )
+    bos restart $i ptserver
+end
 
-prill# /mit/opssrc/moira/afssync/pt_util -x -m -u -g -d /tmp/xxx
-prill# perl /mit/moiradev/pmax/afssync/pt_util.pl < /tmp/xxx > /tmp/prdb.extra
+       # checks, etc:
+$u $db[1]
 
-moira2# cd /var
-moira2# cp -p prdb prdb.new
-moira2# /mit/moiradev/pmax/afssync/pt_util -w -d /var/prdb.extra -p /var/prdb.new
-Ubik Version is: 0.0
-Error while creating who:rune-staff: User or group doesn't exist
-Error while creating system:gsipbbin: Entry for id already exists
-Error while creating celine:admin: User or group doesn't exist
-Error while creating celine:titan: User or group doesn't exist
+######## more on checks
 
+rm /moira/afs/noafs
This page took 2.122538 seconds and 5 git commands to generate.