12.2 CDSLs Revisited

12.2 CDSLs Revisited

We also want to point out that member-specific locations are not only located directly under the cluster/members/member directories of the root(/), /usr, and /var directories.

For example, /etc/rc.config is a link to /.local../etc/rc.config, but /etc/sysconfigtab points to /.local../boot_partition/etc/sysconfigtab. Both files are member-specific.

 # fln /etc/rc.config /etc/sysconfigtab /etc/rc.config -> ../cluster/members/{memb}/etc/rc.config /etc/sysconfigtab -> ../cluster/members/{memb}/boot_partition/etc/sysconfigtab 

Remember that /.local.. is a CDSL that points to /cluster/members/{memb}.

In section 6.3, we showed the CDSLs that exist on a standalone system. Table 12-1 shows the CDSLs that have been added to the system since installing the TruCluster Server software and creating the cluster.

Getting back to our boot partition discussion, if the kernel and osf_boot files are now in /.local../boot_partition, then we have changed where we would normally look for these files, right? Well, yes and no. While the files are technically in a different location, we can still reference them from their previous location in the root directory because there are CDSLs there.

 # fln / | grep boot_partition genvmunix -> cluster/members/{memb}/boot_partition/genvmunix osf_boot -> cluster/members/{memb}/boot_partition/osf_boot vmunix -> cluster/members/{memb}/boot_partition/vmunix 

12.2.1 CDSLs and the mv(1) command

It is because of the output from the last example that we find ourselves compelled to discuss the importance of not using the mv command when replacing a file that is a CDSL. As you can see, the kernel (/vmunix) is now a CDSL. For many years we have all built a new kernel and moved it from its build location to the root directory. In fact, it was taught that way. We must now unlearn what we have learned and use the cp(1) command instead.

Build the kernel as you always have.

 # doconfig -c MOLARI *** KERNEL CONFIGURATION AND BUILD PROCEDURE *** Saving /sys/conf/MOLARI as /sys/conf/MOLARI.bck Do you want to edit the configuration file? (y/n) [n]: *** PERFORMING KERNEL BUILD ***          Working....Mon Dec 17 11:59:58 EST 2001 The new kernel is /sys/MOLARI/vmunix 

Copy the kernel.

 # cp /sys/MOLARI/vmunix / 

Remove the kernel from the build directory, keeping in mind that that kernel is a hard link.

 # cd /sys/MOLARI ; ls -i vmunix* | sort 26247 vmunix.swap 26711 vmunix 26711 vmunix.MOLARI 26711 vmunix.sys 

 # rm vmunix vmunix.MOLARI vmunix.sys 

12.2.2 Repairing a Broken CDSL

If you accidentally (or otherwise) remove a CDSL, you can repair it with the mkcdsl(8)command.

For example, we accidentally move a new kernel to the root directory out of habit.

 # mv /sys/MOLARI/vmunix / 

The kernel is now in the root directory and vmunix is no longer a CDSL.

 # file /vmunix /vmunix:         COFF format alpha executable or object module not stripped - ver sion 3.13-14 

We know that /vmunix is a supposed to be a CDSL, but what if we didn't know that? Well, we can run the cdslinvchk(8) command, and it should tell us that there is a missing link and what it should be. It should also be noted that the clu_check_config(8) also executes cdslinvchk.

 # cdslinvchk Failed CDSL inventory check. See details in /var/adm/cdsl_check_list 

 # cat /var/adm/cdsl_check_list Expected CDSL: ./vmunix -> cluster/members/{memb}/boot_partition/vmunix An administrator or application has replaced this CDSL with: -rwxr-xr-x 1 root system 21009120 Dec 17 12:00 ./vmunix 

Now that we know what the link should be, we can repair it with the mkcdsl command. We will use the "-b" option to create the CDSL, have it point to the boot_partition, and use the "-c" option to copy the file to the location pointed to by the CDSL.

 # mkcdsl –bc /vmunix 

Verify that the procedure was successful.

 # cdslinvchk Successful CDSL inventory check 

For more information on CDSLs, as well as the cdslinvchk and mkcdsl commands, see chapter 6 and/or the cdslinvchk(8) and mkcdsl(8) reference pages.