With current OpenAFS releases, there exist a number of mechanisms for providing access to foreign cells. You may add mount points in your AFS filespace for each foreign cell you wish users to access, or you can enable a 'synthetic' AFS root, which contains mountpoints for either all AFS cells defined in the client machine's local /usr/vice/etc/CellServDB, or for all cells providing location information in the DNS.
When a synthetic root is enabled, the client cache machine creates its own root.afs volume, rather than using the one provided with your cell. This allows clients to access all cells in the CellServDB file and, optionally, all cells registered in the DNS, without requiring system administrator action to enable this access. Using a synthetic root has the additional advantage that it allows a client to start its AFS service without a network available, as it is no longer necessary to contact a fileserver to obtain the root volume.
OpenAFS supports two complimentary mechanisms for creating the synthetic root. Starting the cache manager with the -dynroot option adds all cells listed in /usr/vice/etc/CellServDB to the client's AFS root. Adding the -afsdb option in addition to this enables DNS lookups for any cells that are not found in the client's CellServDB file. Both of these options are added to the AFS initialisation script, or options file, as detailed in Configuring the Cache Manager.
In this section you create a mount point in your AFS filespace for the root.cell volume of each foreign cell that you want to enable your users to access. For users working on a client machine to access the cell, there must in addition be an entry for it in the client machine's local /usr/vice/etc/CellServDB file. (The instructions in Creating the Client CellServDB File suggest that you use the CellServDB.sample file included in the AFS distribution as the basis for your cell's client CellServDB file. The sample file lists all of the cells that had agreed to participate in the AFS global namespace at the time your AFS CD-ROM was created. As mentioned in that section, the AFS Product Support group also maintains a copy of the file, updating it as necessary.)
The chapter in the OpenAFS Administration Guide about cell administration and configuration issues discusses the implications of participating in the global AFS namespace. The chapter about administering client machines explains how to maintain knowledge of foreign cells on client machines, and includes suggestions for maintaining a central version of the file in AFS.
Issue the fs mkmount command to mount each foreign cell's root.cell volume on a directory called /afs/
foreign_cell. Because the root.afs
volume is replicated, you must create a temporary mount point for its read/write version in a directory to which you have
write access (such as your cell's /afs/.
Create the mount points, issue the vos release command to release new replicas to the
read-only sites for the root.afs volume, and issue the fs
checkvolumes command to force the local Cache Manager to access the new replica.
You need to issue the fs mkmount command only once for each foreign cell's root.cell volume. You do not need to repeat the command on each client machine.
Substitute your cell's name for
# cd /afs/.
cellname# /usr/afs/bin/fs mkmount temp root.afs
Repeat the fs mkmount command for each foreign cell you wish to mount at this time.
# /usr/afs/bin/fs mkmount temp/
Issue the following commands only once.
# /usr/afs/bin/fs rmmount temp # /usr/afs/bin/vos release root.afs # /usr/afs/bin/fs checkvolumes
If this machine is going to remain an AFS client after you complete the installation, verify that the local /usr/vice/etc/CellServDB file includes an entry for each foreign cell.
For each cell that does not already have an entry, complete the following instructions:
Create an entry in the CellServDB file. Be sure to comply with the formatting instructions in Creating the Client CellServDB File.
Issue the fs newcell command to add an entry for the cell directly to the list that the Cache Manager maintains in kernel memory. Provide each database server machine's fully qualified hostname.
# /usr/afs/bin/fs newcell <
If you plan to maintain a central version of the CellServDB file (the
conventional location is /afs/
cellname/common/etc/CellServDB), create it now as a copy of the local /usr/vice/etc/CellServDB file. Verify that it includes an entry for each foreign cell you
want your users to be able to access.
# mkdir common # mkdir common/etc # cp /usr/vice/etc/CellServDB common/etc # /usr/afs/bin/vos release root.cell
Issue the ls command to verify that the new cell's mount point is visible in your filespace. The output lists the directories at the top level of the new cell's AFS filespace.
# ls /afs/
If you wish to participate in the global AFS namespace, and only intend running one database server, please register your cell with grand.central.org at this time. To do so, email the CellServDB fragment describing your cell, together with a contact name and email address for any queries, to firstname.lastname@example.org. If you intend on deploying multiple database servers, please wait until you have installed all of them before registering your cell.
If you wish to allow your cell to be located through DNS lookups, at this time you should also add the necessary configuration to your DNS.
AFS database servers may be located by creating AFSDB records in the DNS for the domain name corresponding to the name of your cell. It's outside the scope of this guide to give an indepth description of managing, or configuring, your site's DNS. You should consult the documentation for your DNS server for further details on AFSDB records.