CSL Notebook Topic To CSL Date February 15, 1984 From Mark Brown, Karen Kolling Location PARC Subject Administering an Alpine server Organization CSL XEROX Came from /Indigo/Alpine/Doc/Admin/HowToAdministerAlpine.tioga Last edited by Kolling on February 15, 1984 11:56:19 am PST Abstract This memo documents how to administer an Alpine server. It is not user documentation, client documentation, or implementor documentation. It tells how to create a server from scratch, how to create accounts, how to restart after crashes, and so forth. Finding files Currently, all files relating to Alpine and its administration live in subdirectories of /Indigo/Alpine/. Only a few files are released as part of Cedar. All files relating to Alpine and its administration are controlled by DF files. So even if the files move (say are released as part of Cedar), their DF file structure is likely to be preserved. Creating a server To create an Alpine server named "Xxx.alpine", start by creating an individual of this name in the Grapevine registration database. You'll need to be an administrator (in the Grapevine sense) of the "alpine" registry in order to do this. The individuals "Luther.alpine", "Carson.alpine", "Ebbetts.alpine", "Monitor.alpine", "Gentian.alpine", and "Edelweiss.alpine" exist as of this writing. (The password of any new individual you create should be "RPC".) Get a functioning Cedar machine with an erased logical volume named "Xxx.alpine". (This is separate from the system volume, maybe on a separate physical disk.) You may need to use Iago to get into this state. Open a CommandTool and type % Bringover /Indigo/Alpine/Release50/Top/AlpUmbrella.df % Open AlpineServer.cm You are now looking at the text of AlpineServer.cm. You must edit this file to provide the correct parameters for the call to AlpineControl.Start. Use AlpineControl.Start[fileStore: "Xxx.alpine", typeOfRestart: createServer, ... ] The nLogPages parameter represents the number of pages in the online transaction log; this is an upper bound on the amount of file update in a single transaction. For a T-300 server, choose nLogPages: 20000 (10 mByte) or more. You cannot add log space to an existing server. The nOwners parameter represents the maximum number of accounts that can be created on the server; this can be increased later, so just make your best guess now. The individuals who will act as administrators for the server are identified when the server is started. The alpineWheels parameter to AlpineControl.Initialize is an RName, usually a group, that names the administrators. (Luther.alpine uses AlpineWheels^.pa.) Be sure it is set up correctly for your server. Make your edits and save the file. Then type % AlpineServer and wait for the command file to complete. This takes awhile because of log file initialization, but when it completes the server is ready for business. Right now, before you forget, Open AlpineServer.cm again and change the typeOfRestart parameter back to "warmStart" from "createServer", then save the file. Creating and maintaining owners (accounts) The first thing you'll want to do is create some owners, i.e. accounts. An owner is named by a text name, most often an RName. You must be an administrator (member of the alpineWheels group for the server) to create an owner. On the server or on a Cedar workstation, open a CommandTool and type % Bringover -p /Indigo/Alpine/ClientRelease50/Top/AlpUser.df % AlpineUser Then to create an account for "AENewman.pa" with a 10000 page disk limit, type % _ AlpineCmds.CreateOwner[directory: "[Xxx.alpine]", pageLimit: 10000] If AENewman.pa needs more space later, type % _ AlpineCmds.WriteQuota[directory: "[Xxx.alpine]", pageLimit: 15000] And if AENewman.pa wants his friend "Irving.pa" to be able to create files in the AENewman.pa account, type % _ AlpineCmds.SetOwnerModifyAccess[directory: "[Xxx.alpine]", ownerAccessList: LIST["Irving.pa"]] Look in the AlpineCmds interface for other operations, e.g. delete owner. The delete owner command will error unless you have first deleted all of that owner's files (don't forget the directory file). When you add or remove owners, be sure to modify the Grapevine list AlpineUsers^.pa. Restarting a server After a server crash, you boot/rollback and run the AlpineServer command file again. This assumes that you have remembered to change "typeOfRestart: createServer" to "typeOfRestart: warmStart", as mentioned above. Crash recovery normally takes a few minutes; the longer the log file, the longer it may take. We have found it useful to take a checkpoint that does not include the Alpine server, but does include a CommandTool with the command line "% AlpineServer" typed and waiting for a carriage-return. This means that to restart, you rollback and type carriage-return. Performing backup Selected files on Alpine servers are backed up to /Ivy/AlpineBackup/ each day that they change. Typically Walnut logs and non-Walnut databases are backed up. This was once done by a Dolphin-based server, and is now done by a program that Ron Weaver runs manually each day. To run backup, bringover public from [Indigo]Backup>5.0>5.0HackedAlpineBackup.df. Then type @AlpineBackup.cm to the Commander. A viewer called AlpineBackup.log will be created to tell you what's happening. Chat viewers will come up from time to time. If the process is running okay, it needs no attention. It currently it takes about an hour to run. Occasionally it may report an "Alpine error" on a particular file (it tries twice before it gives up), possibly because of a lock conflict. If it is erroring on a lot of the files, check the Alpine server for a problem. If it reports an IFS error, Ivy may be down, or the quota may have been exceeded. The file [Indigo]Backup>AlpineFilesToBackup.txt tells the backup process which files to backup. "=" in front of a filename means backup even if create date has not changed (segments don't update their create dates). So far we have not been forced to restore a file from backup, but there is always a first time. Dealing with restart failure If restart fails with an uncaught signal, restart again. If this fails in the same way, you are in trouble. You'll either have to debug the problem or cold-start the server: throw away the contents of the log. Files may be in an inconsistent state after a cold-start, and users may want to restore them from backup. To cold-start, set "typeOfRestart: coldStart" and restart. Then be sure to set it back to "typeOfRestart: warmStart" for subsequent restarts. Dealing with other problems The owner database can fill up; you'll get a signal from AlpineCmds.CreateOwner in this case. Use AlpineCmds.ReorganizeOwnerDB to expand the owner database. In principle, the Alpine volume can become fragmented. We do not have enough experience with Cedar 5 to know if this will happen in practice. If it does, clients will get errors (with names that mention volume fragmentation) when trying to create or extend files. You should dump all Alpine files to IFS, create the server from scratch, and reload the files from IFS. Running Alpine as a workstation file system You can run Alpine on any Cedar 5 workstation, sharing the system volume with FS files. To do this, use the special name "Local.alpine" for "Xxx.alpine" in the procdures above, and eliminate the call "AlpineControl.ExportInterfaces[]" from AlpineServer.cm. We have little experience with the use of this configuration. It should work, but don't be surprised if there are some problems. There is no scavenger for the Alpine file system, and no way to reclaim the space used by the Alpine log short of erasing the system volume. Ê»– "Cedar" style˜Icenter•MarkcenterHeaderšÐbl˜ImemoHeadšÏsœžœžœ˜"Lšžœžœ˜,Lšžœžœ˜7Ilogošœ˜Iabstractšž Ït5œžŸžœŸ%˜zšžŸþ˜†head˜ Iblockšœ(Ÿœc˜šPšœŸœ–˜Â—˜P˜Ê˜ïIindentšœ7˜7Q˜—˜˜Q˜O—P˜·P˜¶˜-Q˜—P˜™Pšœœ˜œ—˜*P˜ã˜DQšœ<˜