Using RCS in ROCKS and How ROCKS Uses RCS

ROCKS uses RCS on files that are written or appended with the <file> tag in kickstart xml. This provides some possibilities for debugging, seeing if a file has been altered since the install, etc. It also has some consequences.

For information on RCS, a good place to start is http://www.gnu.org/software/rcs/ or check man rcsinfo.

Kickstart Code Details

The <file> tag can be used within the <post> section(s) of a node xml file. See Kickstart XML By default, the lines in the <file> block are written to a new file with the name you give, you can also append to an existing file. The RCS behavior basically the same for both cases.

This node xml:

<file name="/etc/fstab" mode="append">
/var/swapfile           swap                    swap    defaults        0 0
</file>

produces the following in the kickstart file:

touch /etc/fstab
if [ ! -d /etc/RCS ]; then
   mkdir /etc/RCS
fi
if [ ! -f /etc/RCS/fstab,v ]; then
   echo "initial checkin" | ci /etc/fstab
fi
co -f /etc/fstab
t=TAG_`rpm -qf /etc/fstab | sort | md5sum | tr -cd [:alnum:]`
if ! co -f -p$t /etc/fstab > /dev/null 2>&1; then
   rcs -n$t: /etc/fstab
fi
if ! co -f -pKGEN_INSTALL_1214433502 /etc/fstab > /dev/null 2>&1; then
   rcs -nKGEN_INSTALL_1214433502: /etc/fstab
   co -f -l -r$t /etc/fstab
else
   co -f -l /etc/fstab
fi
cat >> /etc/fstab << 'EOF'
/var/swapfile           swap                    swap    defaults        0 0
EOF
cat /etc/RCS/fstab,v | awk -v date=`date -u +%Y.%m.%d.%H.%M.%S` '/^date/ { printf "date\t%s;\tauthor %s\tstate Exp;", date, $4; next; } { print; }' > /etc/RCS/fstab.bak
cp /etc/RCS/fstab.bak /etc/RCS/fstab,v
rm -f /etc/RCS/fstab.bak
touch /etc/fstab
echo "Kickstart Generator" | ci /etc/fstab
co -f /etc/fstab

Description of above code:

• Touch the file, which creates an empty file if none exists or updates the time stamp. Fails if directory doesn't exist.
• Create RCS directory at same level as file, if it doesn't exist.
• If the RCS data store file "fstab,v" doesn't exist, do an initial checkin of file (which might be empty file from touch).
• Checkout the file. File will now have permissions 444.
• Create a tag based on the hashed output of rpm -qf on the file. For example, the output on /etc/fstab will be "file /etc/fstab is not owned by any package". So by hashing that string you can insure that was the status. More useful is when the file is owned by an rpm, you can test that a certain rpm version owned the file when this was run.
• Try to print file corresponding to that tag. If this fails (tag isn't registered yet) register the tag using rcs command.
• Try to print file corresponding to tag KGEN_INSTALL_999, here the number is the date the kickstart file was generated.
  • If tag doesn't exist, register this tag and checkout file using the TAG_hash from above with lock option. whoops
  • If tag does exist, checkout head with lock option.
• Edit the file. Here an append is done, but overwriting is the default.
• Do the a manual mangling of the fstab,v file. I'm not sure why they do this, and at first look it seems counter-productive. All the time stamps in the file get set to the current time. i don't understand the utility of this.
• Checkin the file the the "Kickstart Generator" log message.
• Checkout the head version without the lock option, note that this is not guaranteed to be the same file that was just checked-in

File Permissions

When you do a regular checkout of file, it is created with permissions 444. This is why multiple files on ROCKS installed systems have this permission. A checkout with lock option creates a file with 644 permissions, ready to be edited. The lock is also recorded in the ,v file.

You can add a perms="NNNN" option to the file block, I'm not sure how this interacts with RCS file locking...

ROCKS Oops

There is an issue with what ROCKS does if the file (more specifically, the RCS dir and ,v file) has been preserved from a previous install. What happens is that the ,v file is never cleared out. ROCKS install with one edit to a file will create v1.1 as the initial checkin and v1.2 as the edited head version. If the ROCKS install runs reusing the ,v file, things get messed up. ROCKS ends up do the checkout of the initial version (assuming output of rpm -qf hasn't changed) at the line with the whoops above; this is version v1.1. The edit is then done. The final checkin (second to last line above) will create a branch since the head version is not out. The branch will be v1.1.1.1 the first time. v1.1.2.1 the second time etc. The final checkout above still pulls the head version out, which is v1.2 from the previous install. Oops.

So, if you are writing to a file that is on a partition that isn't reformatted (/tmp on some of our systems), then this ROCKS RCS mechanism can give an unexpected result.

dkms-install-all-pl-comma-v.txt: Example oops

Practical Consequence?

ROCKS creates a file /tmp/modprobe.conf.rocks using this RCS mechanism, used in the static-ip.xml node. Seems that in our config, nothing is being written to this file (kickstart file shows an append of nothing to the file), and static-ip.xml is rather cryptic with included python code etc. A compute node that has been installed multiple times will have a file /tmp/RCS/modprobe.conf.rocks,v with lots of entries... Anyways, if anything is ever needed to be written and used from this file, it is likely to not work. This is more likely to be a problem if network drivers change.

Examine a File

This RCS setup has the advantage that you can check the change history of a file and see something about what happened during the install and also see if it has been changed since the install. (To bad that more log info isn't recorded during the install, such as the node.xml file that the change is coming from.)

Try rlog filename and rcsdiff filename

-- TomRockwell - 26 Jun 2008