Install the bos suite of commands locally, as a precaution

If you participate in the global AFS namespace, notify grand.central.org that you are decommissioning a database server machine

Update your cell's central CellServDB source file and the file you make available to foreign cells

Update every client machine's /usr/vice/etc/CellServDB file and kernel memory list of database server machines

Remove the machine from the /usr/afs/etc/CellServDB file on file server machines

Stop the database server processes and remove them from the /usr/afs/local/BosConfig file if desired

Restart the database server processes on the remaining database server machines

You can perform the following instructions on either a server or client machine. Login as an AFS administrator who is listed in the /usr/afs/etc/UserList file on all server machines.

   % kinit admin_user
   Password: admin_password
   % aklog

If you are working on a client machine configured in the conventional manner, the bos command suite resides in the /usr/afsws/bin directory, a symbolic link to an AFS directory. An error during installation can potentially block access to AFS, in which case it is helpful to have a copy of the bos binary on the local disk. This step is not necessary if you are working on a server machine, where the binary resides in the local /usr/afs/bin directory.

   % cp  /usr/afsws/bin/bos   /tmp

If your cell is included in the global CellServDB, send the revised list of your cell's database server machines to grand.central.org

If the administrators in foreign cells do not learn about the change in your cell, they cannot update the CellServDB file on their client machines. Users in foreign cells continue to send database requests to the decommissioned machine, which creates needless network traffic and activity on the machine. Also, the users experience time-out delays while their request is forwarded to a valid database server machine.

Remove the decommissioned machine from your cell's central CellServDB source file, if you use one. The conventional location is /afs/cellname/common/etc/CellServDB.

If you maintain a file that users in foreign cells can access to learn about your cell's database server machines, update it also. The conventional location is /afs/cellname/service/etc/CellServDB.local.

Update every client machine's /usr/vice/etc/CellServDB file and kernel memory list to exclude this machine. Altering the CellServDB file and kernel memory list before stopping the actual database server processes avoids possible time-out delays that result when users send requests to a decommissioned database server machine that is still listed in the file.

There are several ways to update the CellServDB file on client machines, as detailed in the chapter of the OpenAFS Administration Guide about administering client machines. One option is to copy over the central update source (which you updated in Step 5). To update the machine's kernel memory list, you can either reboot after changing the CellServDB file or issue the fs newcell command.

Issue the bos removehost command to remove the decommissioned database server machine from the /usr/afs/etc/CellServDB file on server machines.

Substitute the decommissioned database server machine's fully-qualified hostname for the host name argument. If you run a system control machine, substitute its fully-qualified hostname for the machine�name argument. If you do not run a system control machine, repeat the bos removehost command once for each server machine in your cell (including the decommissioned database server machine itself), by substituting each one's fully-qualified hostname for the machine�name argument in turn.

   % bos removehost <machine name>  <host name>   

If you run a system control machine, wait for the Update Server to distribute the new CellServDB file, which takes up to five minutes by default. If issuing individual bos removehost commands, attempt to issue all of them within five minutes.

(Optional) Issue the bos listhosts command on each server machine to verify that the decommissioned database server machine no longer appears in its CellServDB file.

   % bos listhosts <machine name>

Issue the bos stop command to stop the database server processes on the machine, by substituting its fully-qualified hostname for the machine�name argument. The command changes each process's status in the /usr/afs/local/BosConfig file to NotRun, but does not remove its entry from the file.

   % bos stop <machine name> kaserver buserver ptserver vlserver

(Optional) Issue the bos delete command to remove the entries for database server processes from the BosConfig file. This step is unnecessary if you plan to restart the database server functionality on this machine in future.

   % bos delete <machine name> buserver ptserver vlserver

Issue the bos restart command on every database server machine in the cell, to restart the Backup, Protection, and VL Servers. This forces the election of a Ubik coordinator for each process, ensuring that the remaining database server processes recognize that the machine is no longer a database server.

A cell-wide service outage is possible during the election of a new coordinator for the VL Server, but it normally lasts less than five minutes. Messages tracing the progress of the election appear on the console.

Repeat this command on each of your cell's database server machines in quick succession. Begin with the machine with the lowest IP address.

   %  bos restart <machine name> buserver ptserver vlserver    

If an error occurs, restart all server processes on the database server machines again by using one of the following methods: