To: Whom it may concern From: Ken Lowe Date: February 25th, 2000 Subj: Kdump Release Materials The following steps should be taken to install the kdump/karc/bdump suite of products supplied here. This is a binary release. Sources are available if desired. In the following examples, you should replace "frodo" with your host's name and "CHEM" with your group name. The special group "USERS" should be treated as a literal. 1) Install the files. The "local" directory here is intended to be overlayed onto the /usr/local directory. Any files you're expected to modify are provided on this release as 'whatever.sample'. #frodo> cp -rp local/. /usr/local/. The /usr/local/lib/karc directory is protected 700 for privacy of the keys. The /usr/local/etc/krest utility is setuid-root to allow user restores. The other utilities are either run as root themselves or do not need root permissions. 2) Configure karc In the /usr/local/lib/karc directory, copy the "conf.sample" file to "conf" to create your karc configuration file. Create karc keys A) If you're the administrator for a group of hosts, you need to create a level 7 key for your group and send the public half of that to the karc administrator. #frodo> cd /usr/local/lib/karc #frodo> lsc_keygen kar7_CHEM_frodo priv_keys pub_keys #frodo> /usr/ucb/mail -s "Here's my group key" ken@cac cd /usr/local/lib/karc #frodo> lsc_keygen kar4_CHEM_frodo priv_keys newfile #frodo> /usr/local/etc/karc -k 7 -newkey newfile B) If you're a member of an existing group you should create a level 4 key (if this host should have access to dump images from other hosts in the group) or a level 2 key (if this host is an individual that will only need to get to its own dumps) and give the public half to your group administrator. #frodo> cd /usr/local/lib/karc #frodo> lsc_keygen kar4_CHEM_frodo priv_keys pub_keys #frodo> /usr/ucb/mail -s "Here's my key" chem_guy@u cd /usr/local/lib/karc #frodo> lsc_keygen kar2_USERS_frodo priv_keys pub_keys #frodo> /usr/ucb/mail -s "Here's my key" ken@cac /usr/local/etc/karc -list List frodo/: No matches Indications that it failed to connect would be a problem. 3) Configure kdump A) Create an encryption key for your private files (optional) You can create an encryption key for kdump to use to prevent files from being sent across the network in plain text. You can use: #frodo> cd /usr/local/lib/karc #frodo> lsc_keygen kar1_USERS_frodo_YYMMDD /dev/null dump_keys where YYMMDD is the current date. If you have multiple systems in a group that you administer, you can use: #frodo> cd /usr/local/lib/karc #frodo> lsc_keygen kar1_CHEM_global_YYMMDD /dev/null dump_keys and then copy that "dump_keys" file to all of your computers with scp or other suitable utility that won't expose its contents to the world. Modify the "Encrypt" line in the "conf" file to list the key that you created and specify "PRIVATE" to have private files encrypted or "PUBLIC" to have all files encrypted: Encrypt Private kar1_CHEM_global_YYMMDD B) Create exception lists (optional) If you've got any large or volitile files that you don't want dumped you can list them in exception lists on the individual filesystems. For example, if you wanted to avoid dumping files from your users' netscape cache directories, you could put lines of the form: */.netscape/cache */.netscape-cache in a file called "e_list" at the top level of the filesystem. The wildcarding in this file is very limited, an asterisk at the end of a word to indicate "all matching prefixes". Lines with asterisks need to come first. The rule is: No line can match a line that appears earlier in the file. Instead of exception lists, entire directory trees can be exluded from the dump images by creating a file called ".nodump" at the top level to not be dumped. Only the .nodump file itself will be dumped, none of its siblings in the tree. Verify that kdump works You can perform a manual dump of your root filesystem with: #frodo> kdump -u / Dumping all files. Data port opened to 198.48.71.50:49360 Feb 25 14:25 1023 files, 14 links, 129.54MB, Complete Index port opened to 198.48.71.50:49368 If it works properly you should see some status messages like the above displayed on stderr with an exit status of zero. 4) Configure bdump In the /usr/local/bdump directory, you can copy the "sched.sample" and "prune.sample" to "sched" and "prune", respectively. These files control how often filesystems are dumped or not dumped and how many old dumps to hang onto and for how long. Running the bdump.sh script in the /usr/local/bdump directory should perform a full dump on all the filesystems that haven't been dumped in the last 12 hours. Subsequent runs of the script will perform incremental dumps or full dumps as needed. The bdump utilities will write their error messages to files in the "/usr/local/bdump/errs" subdirectory. The intended way to use this is to make that a symbolic link to a root-writable NFS mounted directory that is common for all systems in a local cluster of systems. A single cron process running on one of the computers in the cluster can gather all the non-zero length files from that directory on a daily basis and mail them to some sort of administrator address. If the link is not created, bdump.sh will create a local directory and the error messages will overwrite whatever error messages were there from the previous run. Assuming everything works, the bdump.sh script can be invoked from cron on a daily basis. If you have several systems that will all be dumping their filesystems each night, it is requested that you set up a controlling script on one of the systems that will ssh to each of the other systems and run their bdump.sh scripts in sequence rather than having them all potentially running at the same time. If you would like the scripts that I use to sequence my dumps, please ask. Additional information on these utilities is available via: http://staff.washington.edu/krl/projects/kdump http://staff.washington.edu/krl/projects/recover -Ken