Rename doc subdirectories

We like these names better, and they match the PDF document filenames.

admins -> admin
appldev -> appdev
users -> user

and catch up where the names are used elsewhere.

The relay/ directory has been removed, with its contents moved to the
top level in build_this.rst and a new about.rst.

The section headers for kadmind, krb5kdc, sserver, kpasswd, kswitch,
and sclient are misdetected as conflict markers.
bigredbutton: whitespace

ticket: 7433
tags: pullup

1 files changed, 34 insertions, 0 deletions

diff --git a/doc/admin/backup_host.rst b/doc/admin/backup_host.rst
new file mode 100644
index 0000000000..a0c2a2878e
--- /dev/null
+++ b/doc/admin/backup_host.rst
@@ -0,0 +1,34 @@
+Backups of secure hosts
+=======================
+
+When you back up a secure host, you should exclude the host's keytab
+file from the backup.  If someone obtained a copy of the keytab from a
+backup, that person could make any host masquerade as the host whose
+keytab was compromised.  In many configurations, knowledge of the
+host's keytab also allows root access to the host.  This could be
+particularly dangerous if the compromised keytab was from one of your
+KDCs.  If the machine has a disk crash and the keytab file is lost, it
+is easy to generate another keytab file.  (See :ref:`add_princ_kt`.)
+If you are unable to exclude particular files from backups, you should
+ensure that the backups are kept as secure as the host's root
+password.
+
+
+Backing up the Kerberos database
+--------------------------------
+
+As with any file, it is possible that your Kerberos database could
+become corrupted.  If this happens on one of the slave KDCs, you might
+never notice, since the next automatic propagation of the database
+would install a fresh copy.  However, if it happens to the master KDC,
+the corrupted database would be propagated to all of the slaves during
+the next propagation.  For this reason, MIT recommends that you back
+up your Kerberos database regularly.  Because the master KDC is
+continuously dumping the database to a file in order to propagate it
+to the slave KDCs, it is a simple matter to have a cron job
+periodically copy the dump file to a secure machine elsewhere on your
+network.  (Of course, it is important to make the host where these
+backups are stored as secure as your KDCs, and to encrypt its
+transmission across your network.)  Then if your database becomes
+corrupted, you can load the most recent dump onto the master KDC.
+(See :ref:`restore_from_dump`.)