6.1 Is it Member-Specific or Cluster-Common?
6.1 Is it Member-Specific or Cluster-Common?
Once a system joins or forms a cluster, it becomes a member of the cluster. So if something needs to be uniquely configured, such as a network interface, then its configuration information must be contained in a member-specific file. On the other hand, if something needs to be configured identically for every member in the cluster, such as NIS, then its configuration information must be located in a cluster-common file.
As of Tru64 UNIX version 5.0, the /etc/rc.config file has been split into two files with an optional third file as follows:
-
rc.config
-
rc.config.common
-
rc.config.site (optional)
The rc.config file is member-specific and the rc.config.common file is, you guessed it, cluster-common. The rc.config.site file is for any site-specific configuration information.
# ls /etc/rc.config* /etc/rc.config /etc/rc.config.common
So, what makes /etc/rc.config member-specific? Let's take a closer look at both files.
# file /etc/rc.config* /etc/rc.config: symbolic link to ../cluster/members/{memb}/etc/rc.config /etc/rc.config.common: /bin/sh shell script -- commands text Notice that the rc.config file appears to be in the /etc directory when in actuality it is located in the "../cluster/members/{memb}/etc" directory. The /etc/rc.config file is not a regular file at all, but rather a special type of symbolic link known as a context-dependent symbolic link (CDSL).
6.1.1 Enter the CDSL
So, what is this CDSL thing? A CDSL is a symbolic link with the "{memb}" variable as part of the path. The "{memb}" is the "context", or more appropriately, what is resolved to determine what the context is. Figure 6-1 shows how a CDSL is resolved.
Figure 6-1: CDSL Resolved
Notice that "{memb}" is equal to the word "member" with the member's ID appended. The member's ID is stored in the attribute memberid in the generic subsystem. A standalone system will always have a memberid of zero. Therefore, a CDSL with value of "../cluster/members/{memb}/etc/rc.config" on a standalone system would resolve to the path "../cluster/members/member0/etc/rc.config".
[/etc] # ls -i ../cluster/members/{memb}/etc/rc.config 1817 ../cluster/members/{memb}/etc/rc.config [/etc] # ls -i ../cluster/members/member0/etc/rc.config 1817 ../cluster/members/member0/etc/rc.config
If you examine both files listed in the "ls –i" output, you will see that the files are the exact same file. The "-i" option displays a file's serial number (e.g., an inode in a UFS file system or a tagin an AdvFS file system).
[/etc] # cd /.tags && /sbin/advfs/tag2name 1817 /cluster/members/member0/etc/rc.config
Now that we have shown how you can differentiate a member-specific file from a cluster-common file, it bears mentioning that for every rule there is an exception. In other words, this is not the only way that member-specific files exist. Another method (although much less common) of creating a member-specific file is instead of placing the file in a member-specific directory and creating a CDSL to it, simply rename the file with a unique extension. An example of this second method is provided in Chapter 16 where the Cluster Alias subsystem is described. The Cluster Alias subsystem uses gated.conf files by creating a member-specific gated.conf file and appending "membern" to the file name (e.g. /etc/gated.conf.member1).
6.1.2 Is it in rc.config or rc.config.common?
We mentioned earlier that configuring a network interface was a member-specific task and that configuring NIS was a cluster-wide task, so how is this implemented in our rc.config files? Since NIS is configured cluster-wide, then all the NIS variables should be in /etc/rc.config.common, but not in /etc/rc.config.
# grep NIS /etc/rc.config <nothing is returned>
# grep NIS /etc/rc.config.common NIS_DOMAIN="DAN" export NIS_DOMAIN NIS_CONF="YES" export NIS_CONF NIS_TYPE="CLIENT" export NIS_TYPE NIS_ARGS="-s -S DAN,bacon.dec.com,gravy.dec.com" export NIS_ARGS
The next question you might be asking is, "In what order are these files being called during startup?" In order to avoid unnecessary changes, since many of the init scripts already called rc.config, it was decided that rc.config would call rc.config.common.
# cat /etc/rc.config #!/bin/sh # ... # Read in the cluster attributes before overriding them with the member # specific options. # . /etc/rc.config.common # ...
Note the comment right before rc.config.common is called: "Read in the cluster attributes before overriding them…". Since everything between "#!/bin/sh" and ". /etc/rc.config.common" are comments, the execution of rc.config does not set any variables until after rc.config.common has finished execution.
| Note | If you have any site-specific variables you want to set during system startup, create a file in /etc called rc.config.site, and call it from rc.config.common in the same relative position as rc.config.common is called from rc.config. It is important that site-specific variables are set before the cluster-common variables are set so that nothing in rc.config.site will inadvertently override anything in rc.config.common or rc.config. Note that the name rc.config.site is significant in that the rcmgr command can be used to manipulate your site-specific file (provided it has the correct name). |
When the init daemon is started during system initialization, it uses the /etc/inittab file to tell it what initialization tasks need to be started or stopped at particular run levels.
# grep -E "^s[023]" /etc/inittab s0:0:wait:/sbin/rc0 off < /dev/console > /dev/console 2>&1 s2:23:wait:/sbin/rc2 < /dev/console > /dev/console 2>&1 s3:3:wait:/sbin/rc3 < /dev/console > /dev/console 2>&1
Within /etc/inittab are lines that direct the init daemon to execute three particular scripts (rc0, rc2, and rc3). These scripts in turn execute a series of other scripts in subdirectories under /sbin (see Figure 6-2).
Figure 6-2: Runlevel Initialization
These subdirectories (rc0.d, rc2.d, and rc3.d) contain symbolic links to scripts located in /sbin/init.d. The links are named in such a way as to force the order in which they are executed.
# ls –l /sbin/rc2.d | awk '{ printf ("%15s %3s %s\n",$9,$10,$11) }' K00lpd -> ../init.d/lpd K03lat -> ../init.d/lat K04dhcp -> ../init.d/dhcp ... S25enlogin -> ../init.d/enlogin S35streams -> ../init.d/streams S45atm -> ../init.d/atm Links that begin with a "K" indicate that the scripts associated with those links will be executed when the system is changing to the run level from a higher run level.
Links that begin with an "S" are executed when the system is changing to the run level from a lower run level. These scripts use variables that are set by the /etc/rc.config* scripts.
Figure 6-3 depicts the execution flow for the rc.config files. As you can see from the figure, the init scripts (that are executed from the /sbin/rc? scripts) execute rc.config, which in turn calls rc.config.common before it sets any variables. The rc.config.common file will immediately call rc.config.site (if one exists). Once rc.config.site returns to rc.config.common, then rc.config.common sets the variables in its file and returns to rc.config. Finally, rc.config sets its variables.
Figure 6-3: Runtime Configuration Execution Flow
What happens if a variable is set in more than one file?
-
If a variable is defined in rc.config and rc.config.common, then the value in rc.config is used.
-
If a variable is defined in rc.config.common and rc.config.site, then the value in rc.config.common is used.
6.1.2.1 Using the rcmgr(8) command
The rcmgr command is the recommended method for modifying the rc.config files on Tru64 UNIX. Using rcmgr enables you to set variables as well as retrieve (get) variables. The rcmgr command has four command options that allow you to direct which rc.config file is used. See Table 6-1.
| rcmgr(8) command option | |||
|---|---|---|---|
| Option | Description | Example | Explanation |
| c | use | # rcmgr-c set TCRHB 1 | Set the "TCRHB" variable to the value "1" in rc. config.common. |
| h | use rc.config on the member whose memberid equals the id input after the "-h". | # rcmgr -h 3 get GATED | Get the "GATED" variable from member 3's rc.config file. |
| n | use the rc.config on the member whose memberid equals the id input after "-n". | # rcmgr -n 2 mget | Get all variables set in mmeber2's rc.config file. |
| s | use rc.config.site (if it exists) | # rcmgr -s get TCRHB | Get the variable "TCRHB" from rc.config.site (if it exists). If the site-specific file does not exist the following error is returned: |
Let's see how rcmgr responds by setting and retrieving some variables.
First, let's set the same variable in both rc.config and rc.config.common.
# rcmgr set TCRHB from Member-specific file # grep TCRHB /etc/rc.config* /etc/rc.config:TCRHB="from Member-specific file" /etc/rc.config:export TCRHB
# rcmgr -c set TCRHB from Cluster-common file # grep TCRHB /etc/rc.config* /etc/rc.config:TCRHB="from Member-specific file" /etc/rc.config:export TCRHB /etc/rc.config.common:TCRHB="from Cluster-common file" /etc/rc.config.common:export TCRHB
Now that we have set the variable in both files, let's see what value is returned when using the various command switches.
The "-c" switch:
# rcmgr -c get TCRHB from Cluster-common file
The "-h" switch:
# rcmgr -h 0 get TCRHB from Member-specific file
The "-n" switch:
# rcmgr -n 0 get TCRHB from Member-specific file
No switch:
# rcmgr get TCRHB from Member-specific file
Now let's remove the variable from /etc/rc.config and then repeat the test.
# rcmgr delete TCRHB
Verify that the variable is no longer in /etc/rc.config.
# grep TCRHB /etc/rc.config* /etc/rc.config.common:TCRHB="from Cluster-common file" /etc/rc.config.common:export TCRHB
We will skip the "-c" test since it will return the contents from /etc/rc.config.common,and as you can see from the previous output, the variable is still defined in the common file.
The "-h" switch:
# rcmgr -h 0 get TCRHB from Cluster-common file
The "-n" switch:
# rcmgr -n 0 get TCRHB < no output >
No switch:
# rcmgr get TCRHB from Cluster-common file
Notice that the "-n" switch searches only the member-specific file. The "-h" switch, however, searches the rc.config first and then, if the variable is not there, it will search the rc.config.common file. When no switch is provided, both the "-n" and "-h" search sequences are executed. For additional information regarding the rcmgr command, see the associated reference page.
EAN: 2147483647
Pages: 273