1.1 updates

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

3 files changed, 39 insertions, 90 deletions

diff --git a/doc/ChangeLog b/doc/ChangeLog
index f11f0024be..8b4c0c5092 100644
--- a/doc/ChangeLog
+++ b/doc/ChangeLog
@@ -1,3 +1,9 @@
+1999-09-17  Tom Yu  <tlyu@mit.edu>
+
+	* copyright.texinfo: Update copyright notice somewhat.
+
+	* install.texinfo: Update info on upgrading a KDC for 1.1.
+
 1999-09-08  Ken Raeburn  <raeburn@mit.edu>
 
 	* install.texinfo (Mac OS X Configuration): Revised text from
diff --git a/doc/copyright.texinfo b/doc/copyright.texinfo
index 04601e2034..084cdbba0b 100644
--- a/doc/copyright.texinfo
+++ b/doc/copyright.texinfo
@@ -1,4 +1,4 @@
-Copyright @copyright{} 1990, 1991, 1992, 1993, 1994, 1995, 1996 by the Massachusetts Institute of Technology. 
+Copyright @copyright{} 1985-1999 by the Massachusetts Institute of Technology. 
 
 @quotation  
 Export of software employing encryption from the United States of
@@ -7,15 +7,20 @@ Government.  It is the responsibility of any person or organization
 contemplating export to obtain such a license before exporting.
 @end quotation
 
-WITHIN THAT CONSTRAINT, permission to use, copy, modify, and distribute
-this software and its documentation for any purpose and without fee is
-hereby granted, provided that the above copyright notice appear in all
-copies and that both that copyright notice and this permission notice
-appear in supporting documentation, and that the name of M.I.T. not be
-used in advertising or publicity pertaining to distribution of the
-software without specific, written prior permission.  M.I.T. makes no
-representations about the suitability of this software for any purpose.
-It is provided ``as is'' without express or implied warranty.
+If you make modifications to this software and distribute the modified
+software you MUST LABEL IT AS BEING A MODIFIED VERSION AND NOT ORIGINAL
+MIT KERBEROS CODE.
+
+WITHIN THESE CONSTRAINTS, permission to use, copy, modify, and
+distribute this software and its documentation for any purpose and
+without fee is hereby granted, provided that the above copyright notice
+appear in all copies and that both that copyright notice and this
+permission notice appear in supporting documentation, and that the name
+of M.I.T. not be used in advertising or publicity pertaining to
+distribution of the software without specific, written prior permission.
+M.I.T. makes no representations about the suitability of this software
+for any purpose.  It is provided ``as is'' without express or implied
+warranty.
 
 @iftex
 @vskip 12pt
diff --git a/doc/install.texinfo b/doc/install.texinfo
index a3216ba2b8..8744b0f004 100644
--- a/doc/install.texinfo
+++ b/doc/install.texinfo
@@ -1096,7 +1096,7 @@ to switch the port number for @code{kerberos} to 750 and create a
 V4 KDC(s) will continue to work properly.
 
 @menu
-* Mac OS X Configuration::
+* Mac OS X Configuration::      
 @end menu
 
 @node Mac OS X Configuration,  , Client Machine Configuration Files, Client Machine Configuration Files
@@ -1274,15 +1274,15 @@ telnet  stream  tcp  nowait  root  @value{ROOTDIR}/sbin/telnetd
 @subsection The Keytab File
 
 All Kerberos server machines need a @dfn{keytab} file, called
-@code{/etc/krb5.keytab} (@xref{Upgrading the application servers}), to
-authenticate to the KDC.  The keytab file is an encrypted, local,
-on-disk copy of the host's key.  The keytab file, like the stash file
-(@ref{Create the Database}) is a potential point-of-entry for a
-break-in, and if compromised, would allow unrestricted access to its
-host.  The keytab file should be readable only by root, and should exist
-only on the machine's local disk.  The file should not be part of any
-backup of the machine, unless access to the backup data is secured as
-tightly as access to the machine's root password itself.
+@code{/etc/krb5.keytab}, to authenticate to the KDC.  The keytab file is
+an encrypted, local, on-disk copy of the host's key.  The keytab file,
+like the stash file (@ref{Create the Database}) is a potential
+point-of-entry for a break-in, and if compromised, would allow
+unrestricted access to its host.  The keytab file should be readable
+only by root, and should exist only on the machine's local disk.  The
+file should not be part of any backup of the machine, unless access to
+the backup data is secured as tightly as access to the machine's root
+password itself.
 
 In order to generate a keytab for a host, the host must have a principal
 in the Kerberos database.  The procedure for adding hosts to the
@@ -1355,22 +1355,11 @@ should be readable only by root.
 @node Upgrading Existing Kerberos V5 Installations, Bug Reports for Kerberos V5, Installing Kerberos V5, Top
 @chapter Upgrading Existing @value{PRODUCT} Installations
 
-@menu
-* Upgrading existing Master and Slave KDCs to the current release::  
-* Upgrading the application servers::  
-@end menu
-
-@node Upgrading existing Master and Slave KDCs to the current release, Upgrading the application servers, Upgrading Existing Kerberos V5 Installations, Upgrading Existing Kerberos V5 Installations
-@section 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):
+current release with the @code{kdb5_util} command.  The process for
+upgrading a Master KDC involves the following steps (the lines beginning
+with => indicate a continuation of the previous line):
 
 @enumerate
 
@@ -1378,28 +1367,16 @@ beginning with => indicate a continuation of the previous line):
 server processes, if any.
 
 @item Dumping your existing Kerberos database to an ASCII file with 
-@code{kdb5_edit}'s ``dump'' command:
+@code{kdb5_util}'s ``dump'' command:
 
 @smallexample
 @group
-@b{shell%} kdb5_edit -r @value{PRIMARYREALM} -R 'dump_db' > 
+@b{shell%} kdb5_util -r @value{PRIMARYREALM} dump
 @result{} @value{ROOTDIR}/var/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}/var/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
@@ -1416,50 +1393,11 @@ your current database, you must choose the same master password.
 @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}/var/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 Upgrading the application servers,  , Upgrading existing Master and Slave KDCs to the current release, Upgrading Existing Kerberos V5 Installations
-@section Upgrading the application servers
-
-The default keytab name has changed from @code{/etc/v5srvtab} to
-@code{/etc/krb5.keytab}.  You should rename the old keytab files on all
-of your application servers when you update their server binaries.
-Alternatively, you may add a relation to the library configuration file
-to override the new name, for example:
-
-@smallexample
-@group
-[libdefaults]
-    default_keytab_name = /etc/v5srvtab
-@end group
-@end smallexample
-
-The keytab name defaulted to /etc/v5srvtab in prior releases of Kerberos
-V5.  It was called a @dfn{srvtab} in Kerberos V4.  The @code{v5srvtab}
-file has been renamed to @code{krb5.keytab} to reflect the change in
-terminology.
+To update a Slave KDC, you must stop the old server processes on the
+Slave KDC, install the new server binaries, reload the most recent slave
+dump file, and re-start the server processes.
 
 @node Bug Reports for Kerberos V5, Files, Upgrading Existing Kerberos V5 Installations, Top
 @chapter Bug Reports for @value{PRODUCT}