From c258c8cc5c64ee8bc56271c29aa3a897fd73bc7f Mon Sep 17 00:00:00 2001 From: Ken Raeburn Date: Tue, 21 Sep 1999 23:07:09 +0000 Subject: [PATCH] 1.1 updates git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@11842 dc483132-0cff-0310-8789-dd5450dbe970 --- doc/ChangeLog | 6 +++ doc/copyright.texinfo | 25 ++++++----- doc/install.texinfo | 98 ++++++++----------------------------------- 3 files changed, 39 insertions(+), 90 deletions(-) diff --git a/doc/ChangeLog b/doc/ChangeLog index f11f0024b..8b4c0c509 100644 --- a/doc/ChangeLog +++ b/doc/ChangeLog @@ -1,3 +1,9 @@ +1999-09-17 Tom Yu + + * copyright.texinfo: Update copyright notice somewhat. + + * install.texinfo: Update info on upgrading a KDC for 1.1. + 1999-09-08 Ken Raeburn * install.texinfo (Mac OS X Configuration): Revised text from diff --git a/doc/copyright.texinfo b/doc/copyright.texinfo index 04601e203..084cdbba0 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 a3216ba2b..8744b0f00 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} -- 2.26.2