* install.texinfo (Upgrading existing Master and Slave KDCs to the

 	current release): added section on upgrading to new db format with
 	dump/load [krb5-doc/119]

git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@9297 dc483132-0cff-0310-8789-dd5450dbe970

2 files changed, 89 insertions, 3 deletions

diff --git a/doc/ChangeLog b/doc/ChangeLog
index 69b16f37c1..0c13abdfd8 100644
--- a/doc/ChangeLog
+++ b/doc/ChangeLog
@@ -1,3 +1,9 @@
+Tue Nov  5 16:14:06 1996  Barry Jaspan  <bjaspan@mit.edu>
+
+	* install.texinfo (Upgrading existing Master and Slave KDCs to the
+ 	current release): added section on upgrading to new db format with
+ 	dump/load [krb5-doc/119]
+
 Mon Nov  4 16:50:51 1996  Barry Jaspan  <bjaspan@mit.edu>
 
 	* admin.texinfo (Adding or Modifying Principals): update kadmin
diff --git a/doc/install.texinfo b/doc/install.texinfo
index af41c78314..b97a4a49e6 100644
--- a/doc/install.texinfo
+++ b/doc/install.texinfo
@@ -374,6 +374,7 @@ procedure is based on that recommendation.
 * Add Kerberos Principals to the Database::  
 * Limit Access to the KDCs::    
 * Switching Master and Slave KDCs::  
+* Upgrading existing Master and Slave KDCs to the current release::
 @end menu
 
 @node Install the Master KDC, Install the Slave KDCs, Installing KDCs, Installing KDCs
@@ -442,8 +443,7 @@ Replace @i{@value{PRIMARYREALM}} with the name of your Kerberos realm.
 @smallexample
 @group
 @b{shell%} @value{ROOTDIR}/sbin/kdb5_util create -r @value{PRIMARYREALM} -s
-@b{kdb5_util: No such file or directory while setting active database to '/krb5/principal'
-Initializing database '@value{ROOTDIR}/lib/krb5kdc/principal' for
+@b{Initializing database '@value{ROOTDIR}/lib/krb5kdc/principal' for
 @result{} realm '@value{PRIMARYREALM}',
 master key name 'K/M@@@value{PRIMARYREALM}'
 You will be prompted for the database Master Password.
@@ -937,7 +937,7 @@ eklogin   stream tcp nowait root @value{ROOTDIR}/sbin/klogind
 @end group
 @end smallexample
 
-@node Switching Master and Slave KDCs,  , Limit Access to the KDCs, Installing KDCs
+@node Switching Master and Slave KDCs,  Upgrading existing Master and Slave KDCs to the current release, Limit Access to the KDCs, Installing KDCs
 @subsection Switching Master and Slave KDCs
 
 You may occasionally want to use one of your slave KDCs as the master.
@@ -983,6 +983,86 @@ this, you'll need to change the @code{krb5.conf} file on every client
 machine in your Kerberos realm.)
 @end enumerate
 
+@node Upgrading existing Master and Slave KDCs to the current release, , Switching Master and Slave KDCs, Installing KDCs
+@subsection Upgrading existing Master and Slave KDCs to the current release
+
+If you already have an existing Kerberos database that you created with
+a prior release of Kerberos 5, you can upgrade it to work with the
+current release with the @code{kdb5_util} command.  As of Kerberos 5
+version 1.0, this upgrade process is only necessary if you are using a
+Kerberos database created with Kerberos 5 beta 6 or earlier; newer
+installations can continue to be used without modification.  The process
+for upgrading a Master KDC involves the following steps (the lines
+beginning with => indicate a continuation of the previous line):
+
+@enumerate
+
+@item Stopping your current KDC and administration
+server processes, if any.
+
+@item Dumping your existing Kerberos database to an ASCII file with 
+@code{kdb5_edit}'s ``dump'' command:
+
+@smallexample
+@group
+@b{shell%} kdb5_edit -r @value{PRIMARYREALM} -R 'dump_db' > 
+@result{} @value{ROOTDIR}/lib/krb5kdc/old-kdb-dump
+@b{shell%}
+@end group
+@end smallexample
+
+@item If you were using OpenV*Secure or AXXiON*Authenticate, dumping your
+policy database to an ASCII file with the @code{ovsec_adm_export}
+command:
+
+@smallexample
+@group
+@b{shell%} ovsec_adm_export -r @value{PRIMARYREALM} > 
+@result{} @value{ROOTDIR}/lib/krb5kdc/old-adb-dump
+@b{shell%}
+@end group
+@end smallexample
+
+@item Creating a new Master KDC installation (@xref{Install the Master
+KDC}).  If you have a stash file for your current database, choose any
+new master password but then copy your existing stash file to the
+location specified by your kdc.conf; if you do not have a stash file for
+your current database, you must choose the same master password.
+
+@item Load your old Kerberos database into the new system with
+@code{kdb5_util}'s ``load'' command:
+
+@smallexample
+@group
+@b{shell%} kdb5_util load @value{ROOTDIR}/lib/krb5kdc/old-kdb-dump
+@b{shell%}
+@end group
+@end smallexample
+
+@item If you were using OpenV*Secure or AXXiON*Authenticate, merging
+your policy database with @code{kdb5_util}'s ``load'' command with the
+``-update'' option:
+
+@smallexample
+@group
+@b{shell%} kdb5_util load -update @value{ROOTDIR}/lib/krb5kdc/old-adb-dump
+@b{shell%}
+@end group
+@end smallexample
+
+@end enumerate
+
+The process for upgrading a Slave KDC is simpler.  All you have to do is
+make sure that the stash file on the Slave KDC is correct, stop the old
+server processes on the Slave KDC, install the new server binaries, and
+re-start the server processes.  The Slave KDC database will be upgraded
+automatically when the next propagation is run.  Note that if you
+changed your master key when creating your new Master KDC database, you
+will have to run a Slave KDC propagation before you can restart the
+server processes on the Slave KDC itself; otherwise, the new stash file
+that you create on the slave will not match the old database that exists
+until the propagation occurs, and the server processes will not start.
+
 @node Installing and Configuring UNIX Client Machines, UNIX Application Servers, Installing KDCs, Installing Kerberos V5
 @section Installing and Configuring UNIX Client Machines