Kerberos and fmb

Overview

Since fmb uses rsh for remote backups, and does backups of disks that have kerberos related information, there are several ways in which fmb can have interactions with kerberos.

Note: The kinit command below has had a missing -k option added.

Reccomendation

The recommended scheme is to have a script to launch your fmb commands which:

Does a
setup fmb, kerberos
sets KRB5CCNAME to a backup-specific credentials file, (i.e.
KRB5CCNAME=/tmp/fmbkey.$$; export KRB5CCNAME
).
Does a
kinit -k -t /etc/krb5.keytab host/`hostname`@FNAL.GOV
to get the host key
Then runs normal fmb commands.
Then does a
kdestroy
to destroy the tickets in $KRB5CCNAME.

Then you add
host/backupserver.fnal.gov@FNAL.GOV
to the ~root/.k5login on each host you are backing up.

Note: you probably want to add an "encrypt = false" to the rsh stanza of /etc/krb5.confon your backup system (the system where you start fmb), since encrypting the rsh session will severely impact backup performance.

Kerberos keytab and cache files

System keytab files

We further recommend that you exclude raw keytab files from backups of the root filesystem -- using ncpio format, have a -E etc/krb5.ketyab option in your backup options for the root filesystem, or include etc/krb5.keytab in the list of any files you are already excluding.

If you are using dump for backups, or the fmb exclude file stuff is problematic on your system, you can put your krb5.keytab in some partition that you are not backing up, and symlink it to /etc/krb5.keytab.

For disaster recovery, we recommend having a pgp-encrypted copy of the keytab file called, say, /etc/krb5.pgp.keytab which is encrypted to be readable by the sysadmins of the cluster. (i.e. do a
pgp -feast mengel kschu stan rayp < /etc/krb5.keytab > /etc/krb5.pgp.keytab assuming mengel, kschu, stan, and rayp are the administrators of this system).

We also reccomend that you do keep a copy of your /etc/krb5.keytab in any alternate-boot root partitions you build for disaster recovery.

key cache files

Similarly, since kerberos by default puts key cache files in /tmp, you should exclude /tmp from your backups. Most people do this anyway, but it is now a security issue, since someone could snag a key cache file from the network backup stream that they cannot read (due to permissions) through the filesystem.

Mixed clusters

There are several ways to deal with the mixed cluster situation:

rely on the kerberos-rsh failover to non-kerberized rsh to let you backup your non-kerberized machines from a kerberized server.
This is the recommended method for mixed clusters.
If your backup server cannot run kerberized rsh for some reason, you can use tcpwrappers to allow non-kerberos rsh only from the known backup server and continue to use non-kerberized rsh.
This should only be done as a temporary workaround until you can get kerberos software installed on your backup server.