View figure.
A file collection is a set of files and directories that are duplicated on multiple machines in a network and managed by tools that simplify their control and maintenance. Included with the administrative software is a program called supper. The supper perl program (/var/sysman/supper) uses the Software Update Protocol (SUP) to manage the SP file collections and transfer them across the system.
The following terms are used when defining file collections:
File collections have unique features:
File collections can be either primary or secondary. A primary file collection can be a stand-alone collection or it can contain a secondary collection. Having a secondary collection allows you to keep a group of files available on a particular machine to serve to other systems without having those files installed.
For example, if you want to have one .profile on all nodes and another .profile on the control workstation, consider using the power_system collection delivered with the IBM Parallel System Support Programs for AIX. This is a primary collection that contains node.root as a secondary collection.
Looking at the file collections delivered with the SP system can help you to understand file collection concepts. You should become familiar with the delivered file collections before you begin to update or add to them.
The SP system provides four predefined file collections:
You can display information about each collection on a particular machine using the supper status command. This reports whether or not the file collection is resident on that machine. To do this, log in as root or issue the command remotely. Enter:
/var/sysman/supper status
You can see a list of the files in a file collection by looking at the scan file. See Verifying file collections using the scan file for instructions on how to do this. The scan file contains an entry for each file in the collection that could be installed on a boot-install server or processor node. Certain files in the collection might not exist on one particular system depending on the contents of the refuse file on that system. You can find more information about the scan and refuse files in Directory and master files.
The following table summarizes where these file collections are
resident or available in the SP default
configuration.
| Control workstation | Boot-install servers | Processor nodes | |||
|---|---|---|---|---|---|
| Resident | Available | Resident | Available | Resident | Available |
|
sup.admin user.admin power_system node.root |
sup.admin user.admin node.root |
sup.admin user.admin power_system node.root |
sup.admin user.admin node.root | ||
The sup.admin file collection is a primary collection that is available from the control workstation, is resident (that is, installed) and available on the boot-install servers, and resident on each processor node.
This file collection is important because it contains the files that define the other file collections. It also contains the file collection programs used to load and manage the collections. Of particular interest in this collection are:
The user.admin file collection is a primary collection that is available from the control workstation, resident and available on the boot-install servers and resident on each processor node. This file collection contains files used for user management:
The collection also includes the password index files which are used for login performance:
The power_system file collection is used for files that are system dependent. It is a primary collection that contains one secondary collection called the node.root collection. The power_system collection contains no files other than those in the node.root collection.
The power_system collection is available from the control workstation and available from the boot-install servers. When the power_system collection is installed on a boot-install server, the node.root file collection is resident in the /share/power/system/3.2 directory and can be served from there.
This is a secondary file collection under the power_system primary collection. The node.root collection is available from the control workstation, resident and available on the boot-install servers and resident on the processor nodes. It contains key files that are node-specific.
The node.root file collection is available on the control workstation and the boot-install servers under the power_system collection so that it can be served to all the nodes. We do not install node.root on the control workstation because the files in this collection might conflict with the control workstation's own root files.
Primary and secondary files are defined in the file.collections file (see Step 5: Update the file.collections file).
When you complete the SP installation and configuration process, the delivered file collections are organized in a hierarchy with the control workstation as the master server for all the collections.
Figure 3. Hierarchy of the default SP file collections
| View figure. |
The commands to update the file collections are set up in a crontabs file to run hourly in a staggered sequence. Figure 3 shows this organization. Files are updated on the control workstation in the master file collections (1). The boot-install servers (2) use supper update to request the changes from the control workstation, and the nodes (3) use supper.update to request the changes from the boot-install servers.
Before you work with the delivered file collections or build a file collection of your own, you need to understand the directories, master files, what they contain, and how they work.
The /var/sysman/sup directory contains master files for all the file collections. Figure 4 shows the structure for this directory.
Figure 4. /var/sysman/sup files and directories
 View figure. |
Following is an explanation of the files and directories.
You list the files to exclude by their fully qualified names, one per line. You can include directories, but you must also list each file in that directory you want excluded. This file is present on the nodes depending upon the actions of the administrator.
Each individual file collection is composed of a directory and several master files. Figure 5 shows the structure for the sup.admin file collection in the /var/sysman/sup/sup.admin directory. It includes a sample of the file contents. This example shows eight master files. Other file collections might have fewer master files.
Figure 5. sup.admin master files
 View figure. |
Following is an explanation of the master files shown in Figure 5.
The supper files command reads the last file to obtain a current list of files in the collection. This file is present on the nodes depending upon the actions of the administrator.
The supper master files play a key role during the install, update, and scan processes.
When you run the supper scan command for a file collection, the search begins at the point in the directory specified in the prefix file and traverses the directory tree to find all the files that meet the criteria defined in the list file. The output of this process is the scan file which lists the files in the collection. The scan file is optional but it documents the file collection contents and eliminates the need for the install and update processes to do the directory search.
The supper install and update commands use the scan file, if it is present, to identify the files to install or update. If a scan file is not present, supper performs the same directory search to identify the files as it performs when it creates the scan file. These commands also check the refuse file in /var/sysman/sup at each location and bypass any files it contains. As a result, these commands create a refuse file in the file collection's directory, listing the files that were bypassed.
During updates, the lock and supperlock files prevent update access by other SUP or supper commands. supper checks the update time in the when file against the actual file time stamps to verify that you are not updating with an old version of the files and, if so, does not update. It uses the last file for additional verification when deleting files that no longer exist in the file collection.
Whether invoked with the scan, update, or install commands, supper performs the search process in the following manner:
The supper update commands are included in the crontabs file with the default set to run an update on each of the file collections hourly. You can modify the crontabs file to run the supper update more or less frequently. Refer to Updating crontabs on the SP nodes for more information.
In order to maintain the delivered file collections you will need to perform some basic tasks such as reporting on file collection information, updating files that belong to an existing file collection, and possibly adding or deleting files within an existing file collection. For example:
You can find basic file collection tasks on pages "Understanding file collections" through "Adding and deleting files in a file collection".
Once you are familiar with file collection technology, you might want to build your own collections to manage other files on your system that you would like duplicated on multiple machines. You might have a group of files such as application data that you want installed on each node or local tools you want installed on each boot-install server.
The task of building and distributing your own collections is more advanced. It includes creating the directory and master files, adding entries to the file.collections and lists files, and possibly creating scan and refuse files. Once you complete these tasks and build your file collection, you can install it on the machines in your system. You can also install a file collection from a server other than its default server.
You can find advanced file collection tasks on pages "Modifying the file collection hierarchy" through "Removing a file collection".