SCF Reference Manual for G-Series RVUs (G06.27+)

Using SCF to Configure and Manage NonStop
S-Series Servers
SCF Reference Manual for G-Series RVUs—520413-005
1-14
File Security
subvolume can serve as a hardware versioning tool. That is, you can add software
product revisions (SPRs) for software changes without having to create a new
CONFIG file.
You can use the CONFxxyy file-naming convention to track major and minor hardware
configuration changes. A major change, like the addition of another enclosure, can
increment the xx value. A minor change, like the addition of a tape drive, can
increment the yy value.
Managing multiple versions of the operating system in this way results in fewer SYSnn
subvolumes. This in turn reduces the disk space requirements on the $SYSTEM disk,
because it is now necessary to create a new SYSnn subvolume only when you load a
new version of the operating system.
Storing multiple hardware configurations on the ZSYSCONF subvolume, independent
of the SYSnn subvolume, also means that you need to configure the system fewer
times. For example:
•
You can switch RVUs by loading the system from a different SYSnn subvolume,
yet continue to use the same hardware CONFIG file.
•
You can switch between hardware configurations by loading the system from
different system configuration files.
File Security
SCF has sensitive commands that are available only to super-group users (255,n),
such as ADD, ALTER, DELETE, START, and STOP. (Any user can use the
nonsensitive commands, such as INFO and SETPROMPT.) See page 5-15 for the
lists of sensitive and nonsensitive SCF commands.
Standard file-system security restricts access to a saved system configuration file
based on its file security attributes.
The owner of a generic process can also issue sensitive commands to it. Generic
processes are described in the SCF Reference Manual for the Kernel Subsystem.
Performing Online Configuration Changes on a Remote System
To install a new RVU or make a major system configuration change on another system
in the network, you create an SCF command file on the local system for the new
remote configuration. Doing this has no impact on the performance of the current
running system. If you want, you can test the new configuration on a stand-alone test
system. Then you implement the new configuration by moving the command file to the
remote system, loading that system, and running SCF with the command file as input.
Caution. Do not change the security of the current CONFIG file. $ZCNF has exclusive access
to this file.