From c04c57c6c57d2e0b09ba60b68de738b636c9450b Mon Sep 17 00:00:00 2001 From: Benjamin Kaduk Date: Wed, 22 Oct 2014 12:07:37 -0400 Subject: [PATCH] Remove documentation of 'program' This tool was removed in 2006 in commit b405868ca02880207bda1ec6eb4e21c7b0ac250c. Also remove mention of wsadmin, removed at the same time. Change-Id: I8475b951f576f10ddd2f4b72565354b9fba41d94 Reviewed-on: http://gerrit.openafs.org/11554 Tested-by: BuildBot Reviewed-by: D Brashear --- doc/man-pages/pod1/afs.pod | 3 +- doc/man-pages/pod5/afs.pod | 2 - doc/man-pages/pod5/uss.pod | 9 +- doc/xml/AdminGuide/Makefile.in | 2 +- doc/xml/AdminGuide/NTMakefile | 1 - doc/xml/AdminGuide/auagd000.xml | 2 - doc/xml/AdminGuide/auagd007.xml | 28 +- doc/xml/AdminGuide/auagd015.xml | 46 +- doc/xml/AdminGuide/auagd016.xml | 1876 --------------------------- doc/xml/AdminGuide/auagd017.xml | 24 +- doc/xml/AdminGuide/auagd018.xml | 5 - doc/xml/AdminGuide/auagd023.xml | 6 +- doc/xml/QuickStartUnix/auqbg006.xml | 8 +- 13 files changed, 24 insertions(+), 1988 deletions(-) delete mode 100644 doc/xml/AdminGuide/auagd016.xml diff --git a/doc/man-pages/pod1/afs.pod b/doc/man-pages/pod1/afs.pod index 66fcd5afd..a65cb1c2b 100644 --- a/doc/man-pages/pod1/afs.pod +++ b/doc/man-pages/pod1/afs.pod @@ -68,7 +68,7 @@ name>. The I specifies the group of related commands to which the command belongs, and indicates which command interpreter and server process perform the command. AFS has several command suites, including -B, B, B, B, B, B (deprecated) and B. +B, B, B, B, B (deprecated) and B. Some of these suites have an interactive mode in which the issuer omits the I portion of the command name. @@ -530,7 +530,6 @@ L, L, L, L, -L, L, L, L, diff --git a/doc/man-pages/pod5/afs.pod b/doc/man-pages/pod5/afs.pod index 80fe15930..60f0e8ddc 100644 --- a/doc/man-pages/pod5/afs.pod +++ b/doc/man-pages/pod5/afs.pod @@ -75,8 +75,6 @@ Configuration files: =item L -=item L - =item L =item L diff --git a/doc/man-pages/pod5/uss.pod b/doc/man-pages/pod5/uss.pod index cc10c1c4f..cb277c1fb 100644 --- a/doc/man-pages/pod5/uss.pod +++ b/doc/man-pages/pod5/uss.pod @@ -187,8 +187,7 @@ instruction in the file. Although it is possible to use the C instruction to create a directory on the local disk of the machine where the B command is issued, it is -not recommended. The preferred method for automated creation of -directories on a local disk is the B program. Two complications +not recommended. Two complications arise if the field refers to a local disk directory: =over 4 @@ -301,8 +300,7 @@ character string. Although it is possible to use the C instruction to create a file on the local disk of the machine where the B command is issued, it is -not recommended. The preferred method for automated creation of files on a -local disk is the B program. The main complication is that +not recommended. The main complication is that designating any user other than the issuer as the new file's owner requires logging onto the machine as the local superuser C. For local disk files, only the local superuser C is allowed to issue the @@ -384,8 +382,7 @@ by an C instruction can be any length. Although it is possible to use the C instruction to create a file on the local disk of the machine where the B command is issued, it is -not recommended. The preferred method for automated creation of files on a -local disk is the B program. The main complication is that +not recommended. The main complication is that designating any user other than the issuer as the new file's owner requires logging onto the machine as the local superuser C. For local disk files, only the local superuser C is allowed to issue the diff --git a/doc/xml/AdminGuide/Makefile.in b/doc/xml/AdminGuide/Makefile.in index aa2e25899..f6af41e37 100644 --- a/doc/xml/AdminGuide/Makefile.in +++ b/doc/xml/AdminGuide/Makefile.in @@ -23,7 +23,7 @@ include @TOP_OBJDIR@/src/config/Makefile.version SRCS = $(BOOK).xml auagd005.xml auagd006.xml auagd007.xml auagd008.xml \ auagd009.xml auagd010.xml auagd011.xml auagd012.xml auagd013.xml \ - auagd014.xml auagd015.xml auagd016.xml auagd017.xml auagd018.xml \ + auagd014.xml auagd015.xml auagd017.xml auagd018.xml \ auagd019.xml auagd020.xml auagd021.xml auagd022.xml auagd023.xml \ auagd024.xml auagd025.xml $(VERSION).xml HTML_XSL = @HTML_XSL@ diff --git a/doc/xml/AdminGuide/NTMakefile b/doc/xml/AdminGuide/NTMakefile index 2dde80018..68ef69f1d 100644 --- a/doc/xml/AdminGuide/NTMakefile +++ b/doc/xml/AdminGuide/NTMakefile @@ -62,7 +62,6 @@ XMLSRCS = \ auagd013.xml \ auagd014.xml \ auagd015.xml \ - auagd016.xml \ auagd017.xml \ auagd018.xml \ auagd019.xml \ diff --git a/doc/xml/AdminGuide/auagd000.xml b/doc/xml/AdminGuide/auagd000.xml index 5946bb0c6..6d5690dbe 100644 --- a/doc/xml/AdminGuide/auagd000.xml +++ b/doc/xml/AdminGuide/auagd000.xml @@ -13,7 +13,6 @@ - @@ -88,7 +87,6 @@ Managing Client Machines &chapter10; - &chapter11; diff --git a/doc/xml/AdminGuide/auagd007.xml b/doc/xml/AdminGuide/auagd007.xml index 97308031a..330a03071 100644 --- a/doc/xml/AdminGuide/auagd007.xml +++ b/doc/xml/AdminGuide/auagd007.xml @@ -1486,17 +1486,6 @@ Directories. - - wsadmin - - - This directory contains prototype, configuration and - library files for use with the package program. See Configuring Client Machines with the - package Program. - - @@ -2598,12 +2587,6 @@ functioning normally, users access the copy in the /usr/afsws directory, which is more likely to be current than a local copy. - - You can automate the configuration of client machine local - disks by using the package program, - which updates the contents of the local disk to match a - configuration file. See Configuring Client - Machines with the package Program. @@ -2622,13 +2605,7 @@ role="bold">/usr/vice/etc/CellServDB file. The Cache Manager reads the list into kernel memory at reboot for faster retrieval. You can change the list in kernel memory between reboots - by using the fs newcell command. It - is often practical to store a central version of the CellServDB file in AFS and use the package program periodically to update each - client's version with the source copy. See Maintaining Knowledge of Database Server - Machines. + by using the fs newcell command. Because each client machine maintains its own copy of the CellServDB file, you can in theory @@ -3249,8 +3226,7 @@ role="bold">butc, kas, uss, vos commands), the package program, and others + role="bold">vos commands), and others. diff --git a/doc/xml/AdminGuide/auagd015.xml b/doc/xml/AdminGuide/auagd015.xml index b99a303ad..4ffe0cc4c 100644 --- a/doc/xml/AdminGuide/auagd015.xml +++ b/doc/xml/AdminGuide/auagd015.xml @@ -309,10 +309,6 @@ the local superuser root to issue some commands, whereas others require no privilege. All files mentioned in this chapter must actually reside on the local disk of each AFS client machine (they cannot, for example, be symbolic links to files in AFS). - - AFS's package program can simplify other aspects of client machine configuration, - including those normally set in the machine's AFS initialization file. See Configuring Client Machines - with the package Program. @@ -1843,19 +1839,7 @@ Because a correct entry in the CellServDB file is vital for consistent client performance, you must also update the file on each client machine whenever a cell's list of database server machines changes (for instance, when you follow the instructions in the OpenAFS Quick Beginnings to add or remove a - database server machine). To facilitate the client updates, you can use the package program, - which copies files from a central source in AFS to the local disk of client machines. It is conventional to invoke the - package program in a client machine's AFS initialization file so that it runs as the machine - reboots, but you can also issue the package command at any time. For instructions, see Running the package program. - - If you use the package program, the conventional location for your cell's central - source CellServDB file is /afs/cell_name/common/etc/CellServDB, where cell_name is your cell name. - CellServDB file (client) - - central update source for clients - + database server machine). Creating a symbolic or hard link from /usr/vice/etc/CellServDB to a central source file in AFS is not a viable option. The afsd program reads the file into kernel memory before the @@ -2043,22 +2027,16 @@ changing - - package - - to update client - - CellServDB file (client) - updating with or without package + updating updating - CellServDB file (client) with or without package + CellServDB file (client) @@ -2154,18 +2132,8 @@ of the following three methods. In each case, be sure to obey the formatting requirements described in The Format of the CellServDB file. - If you maintain a central source version of the CellServDB file and use the - package program, first use a text editor to alter the central copy of the file. - Then issue the package command to transfer the contents of the file to the local - machine. For complete instructions, see Running the package program. - - # /etc/package -v -c <name of package file> - - - - - If you maintain a central source CellServDB file but do not use the package program, first use a text editor to alter the central copy of the file. Then use a + If you maintain a central source CellServDB file, + first use a text editor to alter the central copy of the file. Then use a copying command such as the cp command to copy it to the local /usr/vice/etc/CellServDB file. @@ -3631,8 +3599,8 @@ The Cache Manager uses the system name as a substitute for the @sys variable in AFS pathnames. The variable is useful when creating a symbolic link from the local disk to an AFS directory that houses binaries for the client machine's system type. Because the @sys variable automatically steers the Cache Manager to the appropriate directory, you can create the same symbolic - link on client machines of different system types. (You can even automate the creation operation by using the package utility - described in Configuring Client Machines with the package Program.) The link also remains valid + link on client machines of different system types. + The link also remains valid when you upgrade the machine to a new system type. Configuration is simplest if you use the system type names that AFS assigns. For a list, see the OpenAFS Release diff --git a/doc/xml/AdminGuide/auagd016.xml b/doc/xml/AdminGuide/auagd016.xml deleted file mode 100644 index 44cc64af0..000000000 --- a/doc/xml/AdminGuide/auagd016.xml +++ /dev/null @@ -1,1876 +0,0 @@ - - - Configuring Client Machines with the package Program - - The package program automates many aspects of the client configuration process. With the - package program, you can easily configure the local disk of numerous clients by defining global - configuration files. - configuring - - local disk of client with package - - client - - configuring local disk with package - - disk - - local - - local disk - - local disk - - configuring on client, using package - - - - Summary of Instructions - - This chapter explains how to perform the following tasks by using the indicated commands or instructions in a prototype - file: - - - - - - - - - - Configure a client machine's local disk - - package - - - - Define directory - - D [update_code] directory owner group mode_bits - - - - Define file - - F [update_code] file source_file [owner group mode_bits] - - - - Define symbolic link - - L [update_code] link actual_file [owner group mode_bits] - - - - Define block special device - - B device_name major_device_number minor_device_number owner group - mode_bits - - - - Define character special device - - C device_name major_device_number minor_device_number owner group - mode_bits - - - - Define socket - - S socket_name [owner group mode_bits] - - - - - - - - Using the package Program - - - package - - prototype file - - - - prototype files in package - - about - - - The package program uses system-independent prototype files to - define a standard disk configuration; a prototype file indicates which files reside on the local client disk, which files are - links into AFS, etc. The prototype files are then compiled into configuration files for each different - system type. - - Not all client machines have the same configuration. If desired, you can create different prototype files for different - client functions (print server, regular client, etc.). - - The package program compares the contents of a local client disk with the configuration - file. If there are any differences, the package program makes the necessary updates to the - local disk by copying the files from AFS onto the disk. The package program can also be - configured to delete files that are not part of the system configuration or automatically reboot the client when certain files - (such as the dkload file) have been updated. - - The package program does require that you take some time to prepare the prototype files, - but it provides the following benefits: - - You no longer need to configure each machine individually; the prototype configuration file applies to all - machines. - - - - You can change the configuration of machines simply by changing the prototype file and rebooting the clients. - - - - Disk organization is uniform across a set of machines. - - - - The configuration files serve as a record of files on the disk and symbolic links into AFS. - - - - - Using Package on File Server Machines - - While the package program was designed for use on client machines, it can also be used - to configure a file server machine's disk. However, if any of the files referred to in a configuration file reside in volumes - on the file server, the package program cannot access the volumes during reboot (and until - the File Server process and Volume Server process start up again). - - Since the package program aborts when it cannot access a file, you need to eliminate - references to files in AFS that reside in volumes on the file server machine. Because of these constraints, the remainder of - this chapter assumes the package program is being used for client configurations. - - - - - Package Overview - - There are three main steps to follow before running the package program: - - Preparing function-specific prototype files (and any included library - files). - - - - Modifying the package Makefile and compiling - prototype files into system-specific configuration files. - - - - Modifying client machines to run the appropriate package configuration file - automatically. - - - - The following sections summarize these steps. - - - Preparing Prototype Files - - - package - - preparing prototype files - - - - prototype files in package - - preparing - - - Begin by listing the different functions or roles client machines perform and the local disk configurations that support - those functions. Example roles include a standard client that provides AFS access, a print server that drives a printer, and a - backup machine on which you issue commands from the backup suite. Create a different - prototype file for each role. - - A prototype file defines the disk configuration that supports a specific role. Usually, prototype files are - function-specific, but system independent; system-specific values can be defined using variables and library files. Then, when - you modify a variable or library file, the change gets propagated to all appropriate clients when the package program is invoked. - - Methods for building flexible prototype files that are easy to maintain are presented in Example Prototype and Library Files. - - - - Compiling Prototype Files - - - package - - compiling prototype files - - - - package - - configuration files - - - - configuration files - - package program - - - Prototype files are usually system-independent, but can include ifdef statements to - satisfy the needs of different system types. The prototype files are compiled to generate operating-system specific versions. - During compilation, the package program selects the definitions suitable for each system type - and replaces any variables with actual values. These compiled, machine-specific files are called configuration - files. - - Prototype files are compiled using a standard-type Makefile file, as described in The Package Makefile File. - - - - Preparing Clients - - Once system-specific configuration files exist, the package program is ready to run on - the clients. You must first make the package binary available and specify the correct - configuration file. - - Modify the clients as described below: - - Create a .package file in the root ( / ) - directory of each client's local disk that defines the default configuration file. - - - - Make the package binary (/etc/package) available - on the local disk. - - - - Modify the machine's initialization file (/etc/rc or equivalent) to include a - call to the package program. - - - - These steps are discussed more completely in Modifying Client Machines. - - - - - The package Directory Structure - - - package - - directory structure - - - This section assumes that the package-related files have been installed in three - subdirectories of the /afs/cellname/wsadmin directory: - src, lib and etc, as - recommended in the OpenAFS Quick Beginnings. - - These directories contain several sample prototype, library, and configuration files, which can help to clarify how the - package program works. However, they are not necessarily suitable for use in your cell; you - must modify them for your needs. - - - The src directory - - The src directory contains some sample prototype files (used to build the configuration - files), the Makefile file used to build them, and the resulting compiled configuration - files. - - Prototype files have names of the form function.proto. For example, a minimal.proto file defines the minimum set of library files need to run AFS and astaff.dkload.proto file defines a client configuration that uses the a dynamic kernel loading program. - Prototype files can also contain definitions for system administrative files, such as a hosts.equiv file. - - The Makefile file is used to compile the system-independent prototype files into - system-specific configuration files. To learn how to modify this file for use in your cell, see The - Package Makefile File. - - Configuration files are the compiled version of the prototype files and are named function.sysname. Configuration files also appear in the etc subdirectory, - which the package program accesses when configuring disks. - - - - The lib directory - - The lib directory contains many of the example library files referred to in prototype - files. For example, the base.generic file is a system-independent file which includes a - definition of the cell name, system options, and variables; these are used to set the owner, group, and mode_bits fields in - the file and the symbolic link definitions. - - - - The etc directory - - The etc directory contains the system-specific configuration files built from the - prototype files in the src subdirectory. The package program - uses the configuration files in the etc directory to configure disks. - - Some of the example files include minimal and staff - prototype files compiled for different system types. - - - - - Example Prototype and Library Files - - - package - - example prototype files - - - - prototype files in package - - examples - - - A prototype file is a template that defines the configuration of a client's local disk. Prototype files are usually - function-specific (for example, a backup machine, print server, etc.) but system-independent. Prototype files support the use of - ifdef statements and variables, so you can include system-specific definitions. The actual - system-specific configuration file is generated when the prototype file is compiled. - - The components defined in a prototype file can include the directories, files, symbolic links, block special devices, - character special devices and sockets that need to reside on a client's local disk in order for it to perform a specific role, - such as a print server or backup machine. Thus, we recommend that you construct a unique prototype file for each different - client function. - - To make the package program more effective and easy to maintain, create prototype files - that are modular and generic, instead of specific, by using library files and variables: - library files in package - - package - - library files - - - By creating general-purpose library files, you can include the same library file in many prototype files. Thus, you - can make global configuration changes by modifying a single library file; you do not need to modify each prototype - file. - - - - Variables enable you to change definitions simply by changing the variable's value. - - - - - An Example Prototype File - - - examples - - prototype files for package - - - The following is part of an example prototype file that contains the minimum definitions necessary to run AFS. A similar - file called minimal.proto can reside in your src - subdirectory. As recommended, this prototype file references library files and does not include actual definitions. - - - . - . - # Package prototype for a minimal configuration. - # Base components - %include ${wsadmin}/lib/base.generic - # Machine-specific components - %ifdef rs_aix42 - %include ${wsadmin}/lib/rs_aix42.readonly - %include ${wsadmin}/lib/rs_aix42.AFS - %endif rs_aix42 - %ifdef alpha_dux40 - %include ${wsadmin}/lib/alpha_dux40.readonly - %include ${wsadmin}/lib/alpha_dux40.AFS - %endif alpha_dux40 - %ifdef sun4x_56 - %include ${wsadmin}/lib/sun4x_56.readonly - %include ${wsadmin}/lib/sun4x_56.AFS - %endif sun4x_56 - . - . - - - In the previous example, the first uncommented line includes the /lib/base.generic - library file. This library file can contain definitions appropriate for many prototype files; the base.generic library file can also be included in other prototype files, like a staff.proto or backup.proto file. An example library file appears in - the following section. - - Note that system-specific definitions are permitted through the use of ifdef statements - and variables (for example, ${wsadmin} is used to specify pathnames). Thus, the same - prototype file can be used to configure a machine running AIX 4.2 or Solaris 2.6, even though they require different files, - directories, symbolic links and devices. - - In the next uncommented lines of this example, the administrator has constructed different library files for different - system types. Each of these is compiled into unique configuration files. For instance, the following lines in this prototype - file tell the package program to use the library files lib/rs_aix42.readonly and lib/rs_aix42.AFS for the configuration file - when the value rs_aix42 has been declared. (The system-type definition is declared in the Makefile; see The Package Makefile File.) - - - %ifdef rs_aix42 - %include ${wsadmin}/lib/rs_aix42.readonly - %include ${wsadmin}/lib/rs_aix42.AFS - %endif rs_aix42 - - - Similarly, the following lines tell the package program to use the library files - lib/sun4x_56.readonly and lib/sun4x_56.AFS when the value - sun4x_56 has been declared. - - - %ifdef sun4x_56 - %include ${wsadmin}/lib/sun4x_56.readonly - %include ${wsadmin}/lib/sun4x_56.AFS - %endif sun4x_56 - - - - - Example Library File - - - package - - example library files - - - - library files in package - - examples - - - - package - - preparing prototype files - - - - examples - - library files for package - - - The following is part of an example library file for basic configuration definitions. A similar file, called base.generic, can reside in your lib subdirectory. Note that - configurations are defined using standard ifdef statements. - - - . - . - # - # Base package definitions. - # - %ifndef cell - %define cell example.com - %endif cell - %ifndef sys - %include /etc/package.sys - %endif sys - %define ${name} ${name} - %define ${cpu} ${cpu} - %define ${sys} ${sys} - %define ${dept} ${dept} - %define ${hostname} ${hostname} - %ifdef rs_aix42 - % define AIX - % define rootlinks - %ifndef noafsd - % define afsd - %endif noafsd - %endif rs_aix42 - . - . - # - # Some definitions to handle common combinations of owner, group, - # and protection fields. - # - %define rzmode root wheel 600 - %define usermode root wheel 666 - %define systemmode root wheel 644 - %define diskmode root wheel 644 - %define ptymode root wheel 666 - %define ttymode root wheel 666 - . - . - %define aix_rootbin root bin - %define aix_rootprintq root printq - %define aix_rootstaff root staff - %define aix_rootsys root system - %define aix_binbin bin bin - %define aix_binmail bin mail - %define aix_binsys bin system - %define aix_addsys adduser system - %define aix_romode 444 - %define aix_loginmode 544 - %define aix_usermode 666 - %define aix_systemmode 644 - %define aix_textmode 644 - %define aix_rwmode1 660 - %define aix_allrugw 664 - - - The following example library file uses package-specific syntax to define files, - directories, sockets, etc. Each line, called a configuration file instruction, defines a specific - component of disk configuration. The proper syntax for these instructions is briefly described in Package Configuration File Instruction Syntax; see the reference page for the package configuration file in the OpenAFS Administration Reference for detailed - descriptions. - - In this example, the library file contains instructions specific to the configuration of an rs_aix42 machine. You can have similar library files in your lib - subdirectory. - - - . - . - # - # Generic configuration for an AFS rs_aix42 machine. - # - D / ${treemode} - D /afs - FAQ /unix ${machine}/unix.std ${binmode} - LA /unix.std /unix - D /bin ${treemode} - F /bin/as ${machine} ${binmode} - F /bin/ld ${machine} ${binmode} - F /bin/nm ${machine} ${binmode} - FO /bin/login ${afstest} ${suidmode} - . - . - FAQ /usr/vice/etc/ThisCell ${common}/etc/ThisCell ${textmode} - FQ /usr/vice/etc/afsd ${afstest}/root.client ${binmode} - FA /usr/vice/etc/bos ${afstest}/bin/bos ${binmode} - FA /usr/vice/etc/fs ${afstest}/bin/fs ${binmode} - - - - - - Package Configuration File Instruction Syntax - - - package - - configuration file instructions - - - - configuration file - - instructions for package program - - - Within a library file, configuration file instructions are used to define the specific disk configuration. Each - instruction can be used to define a file, directory, socket, or device on the client machine. The syntax for each valid - instruction type is described briefly here; detailed descriptions of the fields appear in the OpenAFS Command - Reference Manual. - - D defines a directory - - - - F defines a file - - - - L defines a link - - - - B defines a block special device - - - - C defines a character special device - - - - S defines a socket - - - - - Each configuration instruction must appear on a single, unbroken line. Instructions sometimes appear here on multiple - lines only for legibility. - - The configuration file must be completely correct. If there are any syntax errors or incorrect values, the package command interpreter exits without executing any instruction. - - - - Local Files versus Symbolic Links - - You can take advantage of the AFS by keeping the number of files on the local client disk to a minimum; instead, create - symbolic links that point into AFS. This can improve machine performance by allowing more space for caching and - swapping. - - Some files, however, must reside on the local disk, as described below. Create these files in the prototype or library - files using the F (file) instruction, not the L (symbolic - link) instruction. - - The following types of files must reside on the local disk of all AFS clients: - - Boot sequence files executed before the afsd program runs. - - Until afsd runs and initializes the Cache Manager, AFS is inaccessible from the - client. Any files that are executed before the afsd program runs must reside on the - local client disk. - - For example, on a machine that uses a disk cache, the /usr/vice/cache directory - must exist when you bring up the Cache Manager, so that there is a location to create cache files. The binary files - /etc/mount and /etc/umount must be available on the - local disk as the machine boots in order to mount the /usr/vice/cache directory. - - In addition, certain UNIX files, such as initialization files (/etc/rc or - equivalent) and file system mapping files (/etc/fstab or equivalent), must reside on - the local disk. - - - - Diagnostic and recovery files - - Certain commands can be used to diagnose and recover from problems caused by a file server outage. It is best to - keep copies of the binaries for these commands on the local disk. For example, store the bos and fs binaries in the /usr/vice/etc directory on the local disk, as well as in the /usr/afsws directory (which in the conventional configuration is a symbolic link into AFS). Then, - set PATH variables so that the /usr/afsws directory appears before the /usr/vice/etc directory. Thus, even if users cannot access AFS (for example, due to a file server - outage) they can still access copies of the bos and fs - binaries in the /usr/vice/etc directory on the local disk. - - - - Files in the /usr/vice directory - - The contents of the /usr/vice directory, including the cache files in the - cache subdirectory and the configuration files in the etc subdirectory, must reside on the local disk. For a description of the files in the directory, - see Configuration and Cache-Related Files on the Local Disk. - - - - - D instruction - - package configuration file - - - - package - - D instruction in configuration file - - - - package - - defining directory in configuration file - - - - directory - - creating with package - - - - - Defining a Directory - - The D instruction defines a directory to be created on the local disk. If a symbolic - link, file, or other element on the local disk has the same name, it is replaced with a directory. If the directory already - exists, its owner, group, and mode bits are changed if necessary to conform with the instruction. - - Use the following instruction to define a directory: - - D[update_code] directory owner group mode_bits - - - The following example defines the /usr directory: - - - D /usr root wheel 755 - - - - F instruction - - package configuration file - - - - package - - F instruction in configuration file - - - - package - - defining file in configuration file - - - - file - - creating with package - - - - - Defining a File - - The F instruction defines a file to be created on the local disk. The source file can - reside in either AFS or the local disk. - - If a file of this name already exists, then it is updated with (overwritten by) the source file, unless the I update code is specified. If a symbolic link or directory of this name exists, the package program replaces it with the source file. - - - Some files must reside on the local disk; they cannot be symbolic links. See Local Files - versus Symbolic Links. - - - Use the following instruction to define a file: - - F[update_code] file source_file [owner group mode_bits] - - - An example which creates/updates the file /bin/grep on the local disk, using /afs/example.com/rs_aix42/bin/grep as the source: - - - F /bin/grep /afs/example.com/rs_aix42 root wheel 755 - - - In the following example, two update codes are used, and the owner, group and - mode_bits slots are left empty, so that the disk file adopts the source file's values for those - slots. - - - FAQ /usr/vice/etc/ThisCell /afs/example.com/common/etc/ThisCell - - - - L instruction - - package configuration file - - - - package - - L instruction in configuration file - - - - package - - defining symbolic link in configuration file - - - - symbolic link - - creating with package - - - - - Defining a Symbolic Link - - The L instruction defines a symbolic link to be created on the local disk. The symbolic - link can point to the AFS file system or the local disk. If the identical symbolic link already exists, the package program does nothing. However, if an element of the same name exists on the disk as a file or - directory, the package program replaces the element with a symbolic link. - - - Some files must reside on the local disk; they cannot be symbolic links. See Local Files - versus Symbolic Links. - - - Use the following instruction to define a symbolic link: - - L[update_code] link actual_file [owner group mode_bits] - - - - Do not create a symbolic link to a file whose name begins with the number sign (#) or - percent sign (%). The Cache Manager interprets such a link as a mount point to a regular or - Read/Write volume, respectively. - - - The following example creates a symbolic link from the /etc/ftpd directory on the local - disk to the /afs/example.com/hp_ux110/etc/ftpd file in AFS. Since the owner, - group and mode_bits fields are empty, the symbolic link adopts values for those - fields from the actual file: - - - L /etc/ftpd /afs/example.com/hp_ux110 - - - This example uses the A update code: - - - LA /etc/printcap /afs/example.com/common/etc/printcap.remote - root wheel 644 - - - - B instruction - - package configuration file - - - - package - - B instruction in configuration file - - - - package - - defining block special device in configuration file - - - - block special device - - creating with package - - - - - Defining a Block Special Device - - The B instruction defines a block special device, which is a device that handles data - in units of multibyte blocks, such as a disk. If a device of the same name already exists, the package program replaces it with the specified block device. - - Use the following instruction to define a block special device (it appears on two lines here only for - legibility): - - B device_name major_device_number minor_device_number \ - owner group mode_bits - - - The following example defines a disk called /dev/hd0a to have major and minor device - numbers 1 and 0: - - - B /dev/hd0a 1 0 root wheel 644 - - - - C instruction - - package configuration file - - - - package - - C instruction in configuration file - - - - package - - defining character special device in configuration file - - - - character special device - - creating with package - - - - - Defining a Character Special Device - - The C instruction defines a character special device, which is device that handles data - in units of a single character at a time, such as a terminal or tty. If a device of the same name already exists, the - package program replaces it with the specified character device. - - Use the following instruction to define a character special device (it appears here on two lines only for - legibility): - - C device_name major_device_number minor_device_number \ - owner group mode_bits - - - The following example defines the tty called /dev/ttyp5 with major and minor device - numbers 6 and 5: - - - C /dev/ttyp5 6 5 root wheel 666 - - - - S instruction - - package configuration file - - - - package - - S instruction in configuration file - - - - package - - defining socket in configuration file - - - - socket - - creating with package - - - - - Defining a Socket - - The S instruction defines a socket, which is communications device for UDP and TCP/IP - connections. If a socket of the same name already exists, the package program replaces - it. - - Use the following instruction to define a socket: - - S socket_name [owner group mode_bits] - - - The following example defines a socket called /dev/printer: - - - S /dev/printer root wheel 777 - - - - - - Constructing Prototype and Library Files - - - package - - constructing prototype and library files - - - - prototype files in package - - constructing - - - - library files in package - - constructing - - - This section describes the general steps required to create package prototype and library - files. Refer to the previous sections for guidelines, and the files in your wsadmin directory - for examples. The construction of prototype and library files is different for each cell. - - - To construct a prototype file and its component library files - - - - Determine where the three package-related subdirectories (src, lib and etc) reside in your - cell's file tree; the following instructions assume they were loaded into the /afs/cellname/wsadmin directory, as described in the OpenAFS Quick - Beginnings. - - - - Decide how many different functions you want client machines in your cell to perform. We recommend that you - construct a separate prototype file for each function. Common functions include: - - Standard workstation: provides users with access to files in AFS - - - - Printer server: drives a printer; can be combined with "staff" functionality - - - - Backup machine: performs backups of AFS volumes to tape by running the AFS Backup System software - - - - - - Determine the minimum functionality needed for all clients (such as AFS setup) and place these generic definitions - in one or more library files. - - - - For each type of client (printer server, backup machine, and so on), place all system-independent definitions in one - file, and all operating-system dependent definitions in another file. - - - - - - - The Package Makefile File - - - package - - Makefile - - - - Makefile for package - - - - files - - package Makefile - - - Once you have created the appropriate prototype and library files, you must compile the prototype for each system type. - The result is a system-specific configuration file. - - The Makefile file defines the prototype and library files used and the order of - compilation. We recommend that you create your Makefile file by modifying the example provided - with the AFS distribution, as described in this section. In the conventional configuration, it is located at /afs/cellname/wsadmin/src/Makefile. - - - Overview - - The following list summarizes the sections in the package Makefile file, identifying each by the header name that begins the section. More detailed descriptions - follow. - - CONFIG= - - - Lists all of the configuration files to be created and defines which prototype files are compiled for which - system types. See The CONFIG Section. - - - - - BASE_LIBS= - - - Lists the pathnames of all operating-system- and function independent library files included in any prototype - files. See The BASE_LIBS Section. - - - - - MACHINE_LIBS= - - - Lists the pathnames of all operating-system-specific library files included in any prototype files. See The MACHINE_LIBS Section. - - - - - LIBS= - - - A one-line instruction that defines LIBS as the combination of BASE_LIBS and MACHINE_LIBS. See The LIBS Section. - - - - - .SUFFIXES - - - Defines all of the suffixes that can appear on a prototype or configuration file. See The .SUFFIXES Section. - - - - - Finally, the Makefile file contains a set of instructions that the package program follows to generate configuration files. It is not generally necessary to alter this - section. See The Makefile Instructions Section. - - - - The CONFIG Section - - As mentioned, a configuration file is a prototype file that has been compiled for a specific operating system type. The - CONFIG section of the Makefile file defines the prototype files to compile for each system - type. The resulting compiled file is a system-specific configuration file. - - Study the following example taken from the sample Makefile file. Configuration files - are defined by specifying the prototype-system combination as prototype_file.sysname. Note - that it is not necessary to generate a configuration file for each prototype-system type combination. - - - #Makefile... - # (C) Copyright IBM Corporation 1999 - # Licensed Materials - Property of IBM - # All Rights Reserved. - # - CONFIG = \ - staff.rs_aix42 \ - staff.alpha_dux40 \ - staff.xdm.alpha_dux40 \ - staff.sun4x_56 \ - staff.hp_ux110 \ - minimal.rs_aix42 \ - minimal.alpha_dux40 \ - minimal.hp_ux110 \ - minimal.sun4x_56 - - - An entry in the CONFIG section has the following format: - - The first part of the entry defines the prototype file and is the same as the prototype file name (without the - .proto extension). The second part of the entry indicates the system type for which the - prototype file is to be compiled. A complete list of these suffixes is in the .SUFFIXES section of the Makefile file, as described in The .SUFFIXES Section. This - prototype_file.sysname definition becomes the name of the compiled configuration - file. - - For example, staff.rs_aix42 indicates that the staff.proto file is compiled for machines running AIX 4.2. The resulting compiled configuration - file is called staff.rs_aix42. - - - - Each configuration file must appear on a separate line. - - - - A backslash must follow the CONFIG= header and every name but the last one. A backslash must also appear on blank - lines. - - - - - - The BASE_LIBS Section - - This section defines the complete pathname of all system- and function-independent library files included in any - prototype file. (System-specific library files are defined in the MACHINE_LIBS section). The pathnames can include the - ${wsadmin} variable, whose value is supplied on the make command line. - - You must include all of the library files referred to in your prototype files; files included but not used are - ignored. - - Study the following example. Note that the all entries (except the last one) must be followed by a backslash. - - - BASE_LIBS = \ - ${wsadmin}/src/admin \ - ${wsadmin}/lib/devel \ - ${wsadmin}/lib/base.generic - - - - - The MACHINE_LIBS Section - - This section lists the complete pathname of all operating-system-specific library files included in prototype files. - (System- and function-independent library files are defined in the BASE_LIBS section.) - - Study the following example. Note that in this example, library files were grouped by operating-system type. Again, all - lines (except the last one) must be followed by a backslash, the ${wsadmin} variable is allowed, and files included but not - used are ignored. - - - MACHINE_LIBS = \ - ${wsadmin}/lib/rs_aix42.generic \ - ${wsadmin}/lib/rs_aix42.generic.dev \ - ${wsadmin}/lib/rs_aix42.readonly \ - ${wsadmin}/lib/rs_aix42.readwrite \ - ${wsadmin}/lib/rt_aix42.generic.printer \ - \ - . - . - ${wsadmin}/lib/alpha_dux40.AFS \ - ${wsadmin}/lib/hp_ux110.AFS \ - ${wsadmin}/lib/sun4x_56.AFS \ - ${wsadmin}/lib/rs_aix42.AFS - - - - - The LIBS Section - - This section contains only one instruction, which indicates that LIBS is defined as the combination of MACHINE_LIBS and - BASE_LIBS. Insert a blank line after the line to separate this section from the next. - - - LIBS = ${MACHINE_LIBS} ${BASE_LIBS} - - - - - The .SUFFIXES Section - - This section lists the valid machine-type suffixes. This list includes system types currently supported for AFS. Unused - suffixes are ignored. - - - .SUFFIXES: .rs_aix42 \ - .alpha_dux40 \ - .proto \ - .sun4x_56 \ - .i386_linux22 \ - .hp_ux110 - - - - - The Makefile Instructions Section - - The remainder of the Makefile file controls how the package program generates configuration files. - - Study the following instructions; it is assumed that you are familiar with programming and Makefile concepts. - - - #The following appear on a single line each in the actual file - .proto.rs_aix42: ; mpp -Dwsadmin=${wsadmin} -Dsys=rs_aix42 - -Dname=$* $*.proto > $@ - .proto.alpha_dux40: ; mpp -Dwsadmin=${wsadmin} -Dsys=alpha_dux40 - -Dname=$* $*.proto > $@ - .proto.sun4x_56: ; mpp -Dwsadmin=${wsadmin} -Dsys=sun4x_56 - -Dname=$* $*.proto > $@ - .proto.hp_ux110: ; mpp -Dwsadmin=${wsadmin} -Dsys=hp_ux110 - -Dname=$* $*.proto > $@ - all: ${CONFIG} - ${CONFIG}: ${LIBS} - system: install - install: ${CONFIG} - cp ${CONFIG} ${wsadmin}/etc - clean: - rm -f ${CONFIG} *.BAK *.CKP - - - - - - Modifying the Makefile - - - package - - modifying the Makefile - - - - Makefile for package - - modifying - - - - modifying - - package Makefile - - - Modify the package Makefile files when you - - Add a new prototype file (function.proto). - - - - Add a new system type. - - - - Add new library files. - - - - The following sections provide brief examples of how to modify the Makefile file for - these reasons. - - - Adding a New Prototype File - - When you create a new prototype file, add the file name and each system type for which it is to be built into the CONFIG - section of the Makefile file. - - For example, to add a function.proto file for alpha_dux40 and hp_ux110, add the following entries to the CONFIG - section: - - - CONFIG = \ - ... - function.alpha_dux40 \ - function.hp_ux110 \ - ... - - - If you have added new library files for this prototype function, add those to the MACHINE_LIBS section. - - - - Adding a New System Type - - For each prototype file that you want to build for the new system type, add an entry to the CONFIG section. Also add any - new libraries to the MACHINE_LIBS section, and the new system type to the .SUFFIXES section. - - The following example shows the modifications appropriate when building the staff and - minimal prototype files for this new system type. - - - CONFIG = \ - ... - staff.sysname \ - minimal.sysname \ - ... - - - If you have created corresponding library files for this new machine type, add them to the MACHINE_LIBS section. - - - MACHINE_LIBS = \ - ... - ${wsadmin}/lib/sysname.generic \ - ${wsadmin}/lib/sysname.generic.dev \ - ${wsadmin}/lib/sysname.readonly \ - ${wsadmin}/lib/sysname.readwrite \ - ... - - - Add the new system type to the SUFFIXES section. - - - .SUFFIXES: ...\ - .sysname \ - ... - - - Add a line to build the configuration files for this system in the section with the rest of the commands to build - configuration files: - - - .proto.sysname: ; mpp -Dwsadmin=${wsadmin} \ - -Dsys=sysname -Dname=$* $*.proto > $ - - - - - Adding New Library Files - - If you added a new library file for each system type, sysname.library_file, add these files to the MACHINE_LIBS section of the Makefile. - - - MACHINE_LIBS = \ - ... - ${wsadmin}/lib/rs_aix42.library_file \ - ... - ${wsadmin}/lib/alpha_dux40.library_file \ - ... - ${wsadmin}/lib/sun4x_56.library_file \ - ... - - - If you added a new library file that is common to all system types, library_file, add this only to the BASE_LIBS - section: - - - BASE_LIBS = \ - ... - ${wsadmin}/lib/library_file \ - ... - - - - - - Compiling Prototype Files - - - compiling - - package prototype file - - - - package - - compiling prototype files - - - The package program generates configuration files and installs them in the etc and src subdirectories of the directory designated as wsadmin= on the make command line. Recompile whenever you modify a - prototype or library file. - - - To compile prototype files - - - These instructions assume that you store your package-related files in the /afs/cellname/wsadmin directory. If you use a different directory, - substitute its name for /afs/cellname/wsadmin. - - - - - Verify that you have all privileges in the /afs/cellname/wsadmin directory and in its src, lib and etc subdirectories. If necessary, issue the fs listacl command. - % fs listacl [dir/file path] - - - - - Change to the /afs/cellname/wsadmin/src - subdirectory. - % cd /afs/cellname/wsadmin/src - - - - - Create a backup copy of the Makefile file included in the AFS distribution. - - % cp Makefile Makefile.example - - - - - Modify the CONFIG, BASE_LIBS and MACHINE_LIBS sections of the Makefile file, as - described in The CONFIG Section, The BASE_LIBS Section, - and The MACHINE_LIBS Section. - - - - Compile the prototype files using the make command. - - Use the wsadmin= argument to specify the package - directory. This becomes the value of the ${wsadmin} variable in the prototype and the library files. - - The package program generates configuration files and installs them in the - etc and src subdirectories of the directory designated - as wsadmin=. - - - % make system wsadmin=/afs/cellname/wsadmin - - - - - - - - Modifying Client Machines - - - package directory - - - - client - - modifying to run package - - - - package - - modifying clients to run - - - - modifying - - clients to run package - - - To prepare a client to run the package program automatically, perform the following - steps. The instructions are generic because they do not refer to system-specific configuration files. If desired, you can invoke - the package program with specific arguments, as described in the OpenAFS - Administration Reference. - - Specify the configuration file to use. - - The .package file in the client machine's root ( /) directory is redirected as an argument to the package command; - the .package file specifies which configuration file the package program uses. - - - - Make the package binary available to the client, either by copying it to the local - disk, or by creating a symbolic link to AFS. - - A symbolic link saves local disk space. However, when the file server machine that houses it is down, the - package binary is inaccessible. - - - - Keeping the package binary on the local disk enables you to run the package program even if file server is down. However, a file server machine outage usually - makes it difficult to run the package program because most configuration file - instructions refer to files in AFS. A local copy of the package binary can be - useful if the files referred to in instructions are in replicated volumes. - - - - - - Modify the client machine's initialization file to invoke the package program at - reboot. The client machine reboots a second time if the package program updates any files - marked with the Q update code. - - - - - To prepare a client machine to run the package program - - Repeat these instructions on every client that runs the package program. - - These instructions assume that the package configuration files (created when the - prototype files were compiled) reside in the /afs/cellname/wsadmin/etc directory. - - Become the local superuser root on the machine, if you are not already, by - issuing the su command. - % su root - Password: <root_password> - - - - - Create the .package file in the root ( /) - directory and specify the name of the prototype file to use. Do not include the system-type suffix (such as .rs_aix42); the package program automatically determines the - correct machine type. - # echo "/afs/cellname/wsadmin/etc/config_file" >> /.package - - - For example, to configure a machine for a member of staff machine (assuming the proper prototype file had been - defined and compiled for the system type), the appropriate command is: - - - # echo "/afs/cellname/wsadmin/etc/staff" >> /.package - - - - - Make the package binary available on the local disk as /etc/package. Issue one of the following commands, depending on whether you want to create a file - or create a symbolic link. - - To store the package binary locally, enter the following command: - - - # cp /afs/cellname/sysname/usr/afsws/etc/package /etc/package - - - To create a symbolic link, enter the following command: - - - # ln -s /afs/cellname/sysname/usr/afsws/etc/package /etc/package - - - - - Add the following lines to the appropriate initialization file, after the afsd - command is invoked. If this is a file server machine, the bosserver command must follow - the package command. - - Using the -v and -c options is recommended. The - -v flag produces a detailed trace, and the -c option - appends the system type to the base name of the configuration file. See the OpenAFS Administration - Reference for a description of other options. - - - Replace the shutdown command with a similar command if it is not appropriate - for rebooting your machine. - - - - if [ -f /etc/package ]; then - if [ -f /.package ]: then - /etc/package -v -c `cat /.package` >/dev/console - else - /etc/package -v >/dev/console - fi - case $? in - 0) - echo "Package completed successfully" >/dev/console 2>&1 - date >/dev/console 2>&1 - ;; - 4) - echo "Rebooting to restart system" >/dev/console 2>&1 - echo >/fastboot - shutdown - ;; - *) - echo "Update failed, continuing anyway" >/dev/console 2>&1 - ;; - esac - fi - - - - - - - - Running the package program - - After you have created and compiled prototype files and modified client machines, you are ready to run the package program. It is probably most convenient to run the package - program automatically at reboot by invoking it in the machine's AFS initialization file, but you can also issue the command at - the command shell prompt. - - The configuration file must be completely correct. If there are any syntax errors or incorrect values, the program exits - without executing any instruction. To check the configuration file, issue the package command - with the -noaction and -debug flags at the command shell - prompt. They display a list of potential problems without actually executing instructions. - - The package program follows these general rules. Complete explanations are in Package Configuration File Instruction Syntax. - - The package program does not delete any files from the disk unless the R update code was specified in the prototype file. If the R update - code is associated with the parent directory, the package program removes anything from - the local disk directory that is not specified in the configuration file. - - - - Local files are updated only if they are out of date. For each F instruction in the - configuration file, the package program compares the time of the local file with the - indicated source file. If the source file is newer than the local, the file is updated. - - - - When the initialization file is modified as recommended in Modifying Client - Machines, the package program reboots the workstation automatically if any files - marked with the Q update code are updated, and if the package program has been invoked from the initialization file. When a file marked with the - Q update code is changed, the package program exits with - status code 4, causing a reboot (as directed in the initialization file). Files that require a reboot before changes are - recognized (such as the operating system kernel and /usr/vice/etc/CellServDB files) must - be marked with a Q update code in the configuration file. - - - - The package program copies the configuration file it has just used to /etc/package.sysname, where sysname reflects this machine's system type. The package command interpreter consults this file if you do not provide a configuration file name. To - be sure that it configures the local disk as you wish, review its contents. - - - - - To invoke the package program by rebooting - - - - Become the local superuser root on the machine, if you are not already, by issuing - the su command. - % su root - Password: <root_password> - - - - - (Recommended) Verify the following: - - The /.package file identifies the desired configuration file - - - - The package binary is available as /etc/package - - - - The initialization file is properly modified to invoke the package program - automatically - - - - - - Reboot the machine, using the appropriate command. - # shutdown - - - - - - commands - - package - - - - package command - - - - - To invoke the package program directly (without rebooting) - - - - Become the local superuser root on the machine, if you are not already, by issuing - the su command. - % su root - Password: <root_password> - - - - - Verify the following: - - The /.package file identifies the desired configuration file - - - - The package binary is available as /etc/package - - - - The initialization file is properly modified to invoke the package program - automatically - - - - - - Issue the package command. - # package [initcmd] [-config <base name of configuration file>] \ - [-fullconfig <full name of configuration file, or stdin for standard input>] \ - [-overwrite] [-noaction] [-verbose] [-silent] [-rebootfiles] - - - where - - -config - - - Specifies the full pathname of the configuration file to use, ending in the file's base name, which omits - the suffix that indicates the machine type. The package program knows how to - determine a machine's type, and automatically selects the appropriate version of the base file name. An example of - the proper value for this argument is staff rather than staff.rs_aix42. You can also have the package program - refer to /.package to learn the configuration file name by providing the - following value: - - `cat /.package` - - Use either this argument or the -fullconfig argument. - - - - - -fullconfig - - - Specifies the full name of the configuration file to use, complete with the machine-type extension. Examples - are staff.rs_aix42 and minimal.hp_ux110 - files. - - Another possibility is the string stdin, which indicates that the issuer is - providing configuration information via the standard input stream, either as a piped file or by typing the - configuration file at the keyboard. Press <Ctrl-d> to conclude the - input. - - Use either this argument or the -config argument. - - - - - -overwrite - - - Overwrite elements on the local disk with the source version indicated in the configuration file, even if - the first (owner) w (write) mode bit is turned - off on the local disk copy of the file. Files protected by the I update code are - not overwritten; see the definition for the F instruction. - - - - - -noaction - - - Displays on the standard output stream a trace of potential problems in running the command, rather than - actually running it. If the -verbose flag is added, the trace also notes the - actions the package program attempts. - - - - - -silent - - - Explicitly invokes the default level of tracing, which includes only a list of problems encountered while - executing the command. - - - - - -verbose - - - Produces a detailed trace of the program's actions on the standard output stream. The trace records on the - transfer and ownership/mode bit setting of each element in the configuration file. - - - - - -rebootfiles - - - Prevents the overwrite of any element marked with the Q update-mode code in - the configuration file. This effectively prevents the machine from rebooting automatically again when the - package program is invoked from an initialization file. - - - - - - - If you think files marked with the Q update code were updated, reboot the machine. - This reboot does not occur automatically. - - - - - \ No newline at end of file diff --git a/doc/xml/AdminGuide/auagd017.xml b/doc/xml/AdminGuide/auagd017.xml index d54f26e3d..fcb635e62 100644 --- a/doc/xml/AdminGuide/auagd017.xml +++ b/doc/xml/AdminGuide/auagd017.xml @@ -539,12 +539,6 @@ Incorporate the one-line file into the common source version of the local password file. It makes sense to store this file in AFS. See the following two example scripts for automating this step. - - - Distribute the common password file to each client machine, perhaps by using the AFS package utility as described in Configuring Client Machines with the - package Program. - As an example, the template file used by the Example Corporation includes the following E @@ -1237,17 +1231,6 @@ still must appear in the D instruction's ACL field. - - The recommended method for configuring a machine's local disk is to use the AFS package - utility instead; see Configuring Client Machines with the package Program. - examples - - uss template file - - uss template file - - examples - @@ -3504,8 +3487,8 @@ Delete the user's entry from the local password file (/etc/passwd or equivalent) of - each client machine. If you use the AFS package utility, it is sufficient to remove the - entry from the common source version of the file. If you intend to reactivate the user's account in the future, it is + each client machine. + If you intend to reactivate the user's account in the future, it is simpler to comment out the entry or place an asterisk (*) in the password field. @@ -4056,8 +4039,7 @@ If you are deleting accounts, delete the user's entry from the local password file (/etc/passwd or equivalent) of each client machine. If you use the AFS package utility, it is sufficient to remove the entry from the common source version of the file. + role="bold">/etc/passwd or equivalent) of each client machine. If you intend to reactivate the user's account in the future, it is simpler to comment out the entry or place an asterisk (*) in the password field. diff --git a/doc/xml/AdminGuide/auagd018.xml b/doc/xml/AdminGuide/auagd018.xml index 73b6677a8..3450a63e9 100644 --- a/doc/xml/AdminGuide/auagd018.xml +++ b/doc/xml/AdminGuide/auagd018.xml @@ -1088,11 +1088,6 @@ role="bold">/etc/passwd or equivalent) of each machine the user can log onto. Remember to make the UNIX UID the same as the AFS UID you learned in Step 11, and to fill the password field appropriately (for instructions, see Specifying Passwords in the Local Password File). - - If you use the package utility to distribute a common version of the password file - to all client machines, then you need to make the change only in the common version. See Configuring Client Machines with the package Program. - diff --git a/doc/xml/AdminGuide/auagd023.xml b/doc/xml/AdminGuide/auagd023.xml index 3ded9338a..2de38732b 100644 --- a/doc/xml/AdminGuide/auagd023.xml +++ b/doc/xml/AdminGuide/auagd023.xml @@ -30,8 +30,8 @@ The command_suite specifies the group of related commands to which the command belongs, and indicates which command interpreter and server process perform the command. AFS has several command suites, including - bos, fs, kas, package, pts, scout, bos, fs, kas, + pts, scout, uss and vos. Some of these suites have an interactive mode in which the issuer omits the command_suite portion of the command name. @@ -454,4 +454,4 @@ - \ No newline at end of file + diff --git a/doc/xml/QuickStartUnix/auqbg006.xml b/doc/xml/QuickStartUnix/auqbg006.xml index b0dc69778..b13fb5ae1 100644 --- a/doc/xml/QuickStartUnix/auqbg006.xml +++ b/doc/xml/QuickStartUnix/auqbg006.xml @@ -3197,8 +3197,8 @@ 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), with or - without using the package program. To update the machine's kernel memory list, you can + 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. @@ -3507,8 +3507,8 @@ 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), with or - without using the package program. To update the machine's kernel memory list, you can + 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. bos commands -- 2.39.5