Grapevine was designed to allow decentralized administration. To a large extent this succeeded, but there are some things that must be centralised (like running the GV registry or making new versions of the software), and there are some things that the various local administrators are unqualified to do (like patching disks to recover from disk errors), and there are some things that we don't trust them to do (like purging dead names before the normal 14 day timeout), and there are some things where we got it wrong (like adding or removing registries, or verious aspects of archived mailboxes). So the central administrators are needed fairly often. The local administrators have always been friendly and helpful, and they are quite well trained at calling for help before they produce a disaster. Most of them are quite non technical.

Make use of the local administrators. If you don't, you will spend absurd amounts of time running Grapevine. It is often tempting to do something yourself because it's easier than sending a message to the local administrator, but remember that whatever problem you're solving will recur someday and life will be easier if the local administrators learn to deal with the problem. Mike Schroeder and I ended up spending a total of about a day or two per month on Grapevine (averaged - it can be quite bursty). Ron Weaver is quite helpful and experienced at providing non-technical assistance.

Local administrators get their privileges by being on the owners or friends acls of the appropriate registry. The precise rights endowed by those two acls are described in the Grapevine Interface protocol specification, or look in the source module ACL.mesa. There doesn't seem to be a useful distinction between those acls, so I tend to ignore the friends acl. Note that registry owners/friends cannot change these acls (nor the membership lists of those groups!) We've been maintaining a distribution list GVAdmin^.pa for sending messages to the local administrators. Remember that you can also send messages to names such as Owners-ES.gv.

There is a list LogReaders^.ms which permits people to read the file GV.log from a server; this isn't particularly useful. At present the log files (but not the archive files) on IFS's are publicly readable; this is probably a bad idea but I haven't had the energy to go fix it. Transport^.ms is the major acl defining who are the central administrators. This list is the acl checked by the viticulturists' entrance Enable command. It is also an owner of GV.gv and therefore has complete access to the database. It is also used by the built in FTP server to allow reading or writing files on the local file system. The individual Wizard.gv can also use the Enable command and is also an owner of GV.gv. This is so that you can acquire privileges on a server without needing to access a group membership list (handy if the server's disk is entirely full, or if enough servers are down that it's hard to perform the recursive membership check on Transport^.ms). If you are logged in as an individual in the GV registry, you can read someone's password by using Maintain. It's also possible to log in as a server; this is occasionally useful for using Lily to look at a server's mailbox. The group IFSAccounts^.ms has owners rights to the DMS directory on each IFS, and so can manipulate the log files and archive files there. Each mail server is a member of that list, and central administrators may want to add themselves (or maybe you should just add Transport^.ms to it).

The individual DeadLetter.ms receives a message whenever a server returns a message to its sender. The name PostMaster.pa is used by Arpanet people to ask about our mail system. The name LaurelSupport.pa is intended for user enquiries about Laurel, but they also use that for enquiries about Grapevine.

The group GVSupport^.pa is on DeadLetter.ms, PostMaster.pa, LaurelSupport.pa and Transport^.ms, and also protects access to the Grapevine directories on [Ivy] and [Indigo], where the sources are kept.

The group LaurelImp^.pa protects access to the DMS directory on Indigo (where Laurel's sources are kept) and the Laurel release directory on Ivy.

The group ExpressMail^.ms controls which lists will be given slower processing for message delivery. This is used to avoid overload by things like Junk^.pa. You may occasionally want to add to this list.

This section describes how to make those changes to the system that are performed by the central administrators, namely adding new servers and changing the set of registries in the world or on a particular server. We also keep central control about configuration decisions about where people's mailboxes should be, although we get the local administrators to implement those decisions. They should be reminded that it's a bad idea to move lots of mailboxes at one time (since it can severely overload the servers).

The servers keep copious log files, backed up in 40 files of 120*512 bytes each. Occasionally a local administrator will ask questions about some misuse of the system or of someone's password. Quite often the identity of the offender will be obvious if you look at the appropriate log files. They can also be handy for tracking down the cause of multi-server problems.

0. Create a files only directory named "DMS" on a Leaf server near to the Grapevine server's permanent host. Give it a 5000 page quota. Make all permissions available to anyone in the group IFSAccounts^.ms. (Skip if account already exists for another Grapevine server.)

1. Register "NewServer" in the Pup network directory with the net#host# of its permanent host.

2. Include "NewServer" on the right-hand side for the definition for "GrapevineRServers" in the Pup network directory. (There may be a problem here: the right hand side is limited to 20 names. Omitting this step will make the server slightly harder for clients to find.)

3. Create an individual named NewServer.gv with three inbox sites, the correct password, and a connect site of the net#host# where you will first start up the server.

4. Create an individual named NewServer.ms with three inbox sites, the correct password, and a connect site of the net#host# where you will first start up the server.

5. Create a group named Archive-NewServer.ms with a member "[LeafServer]<DMS>", where "LeafServer" is the IFS used in step 0.

6. Create an individual named Log-NewServer.ms with no password and a connect site set to "[LeafServer]<DMS>Log>".

7. Add NewServer.ms as a member of MailDrop.ms.

7a. Wait a while for most existing Grapevine servers to get all these updates.

8. Add NewServer.gv as a member of all registries that the new server is to contain replicas of. This will include gv, ms, internet, auto, and foreign.

9. Add NewServer.ms as a member of IFSAccounts^.ms.

10. Wait a while for most existing Grapevine servers to get all these updates.

11. Find a vacant Dorado with an Alto partition and use CopyDisk to install the primeval server disk from [Indigo]<Grapevine>PrimevalServer.bfs. Boot this, and install the operationg system to rename the file system to be NewServer. Delete the file heap.segments if it exists. Delete MBX* and SL* too.

12. Start the server running by typing "@server.cm".

13. Type the passwords asked for and proceed from the debugger once (uncaught signal "InitialisingHeap" from HeapRestart) as required.

14. When its finally open for business, wait for all accumulated data base updates to complete, then stop the server and CopyDisk it's disks to disks on the permanent host. Restart the server there and then delete the file heap.segments from your original of the startup disks. Recently, we've done the CopyDisk to the remote site by storing the disk image on Indigo then getting the remote people to suck the disks from there with CopyDisk. This requires less intervention from this end.

15. Restore the Dorado's Alto partition to a sensible state (as described in the "Server Building" section).

Note. If you fail after step 12, you must delete the file heap.segments before retrying.

Perform step 11 of the above recipe. Set the connect sites for NewServer.gv and NewServer.ms to the net#host# of that Dorado. Perform steps 12, 13, 14 and 15 of the above recipe.

You can move an existing server to a new address quite casually. It will automatically notice its new address and update the database. If the server is a dandelion, you'll first need to update the Pup network directory to map the processor ID to the new Pup address. There is a potential race in the newly moved server finding it's local mailbox - you can fix the race by using maintain to set the correct connect site for the mail server in its local version of the MS registry.

1. Create the group NewReg.gv

2. Set its remark field to something informative

3. Add appropriate registration servers as members of the group. Remember ot use full RNames such as Cabernet.gv.

4. Wait until you're sure that each of those servers has received an update giving it the final membership list of NewReg.gv (so they all know who to send updates to).

5. Add appropriate administrators as owners of the group NewReg.gv and tell the administrators that it's all ready.

Don't just delete the group OldReg.gv; this should work, but it apparently crashes each server that knows about the registry. So first remove all members from the group, then wait for those updates to propagate to all the concerned servers, then delete the group.

Easy: just remove the server from being a member of the group OldReg.gv.

Hard. The difficulties arise from the problem of synchronizing the newly added server fetching the registry with people making updates to the registry. Really, we should have implemented the midnight database comparison and repair demon and been less paranoid about the database being temporarily out of step. However, here's what you do. Chat to the server in question, log in and enable. Then use the AddRegistry command. This leads you by the hand through a delicate process. I'm not sure what happens if there's a crash in the middle of it. In case of doubt, look at the procedure DoAddRegistry in the source module Enquiry.mesa. Approximately, the server turns itself off, then adds itself to the database in its local copy only, then gets you to add it in everyone else's copy (using some other server), then when that update has propagated (your judgement) it fetches the registry from some other server. The entire exercise is quite sensitive to network or server failures. Sigh!