TAR=tar -chvf
GZIP=gzip -9
MANPS=./man2ps
-all:: admin-guide-full install-guide-full user-guide-full tgz
+all::
+ echo "Can't make all guides at once--nodes in include files will be wrong."
admin-guide-full:: admin-guide admin-guide-info admin-guide-html
@c M-x texinfo-every-node-update will take care of calculating the
@c node's forward and back pointers.
@c
+@c ---------------------------------------------------------------------
@menu
* Introduction::
* How Kerberos Works::
* Administrating Kerberos Database Entries::
* Application Servers::
-* Updates::
* Backups of Secure Hosts::
-* Support::
* Bug Reporting::
* Appendix::
@end menu
-@c ---------------------------------------------------------------------
-
@node Introduction, How Kerberos Works, Top, Top
@chapter Introduction
-@ifset CYGNUS
-Congratulations on your purchase of @value{PRODUCT}. @value{COMPANY}
-believes @value{PRODUCT} provides the best network security available.
-Please let us know if we can be of assistance in getting your
-installation of @value{PRODUCT} set up and running.
-@end ifset
-
@menu
* Why Should I use Kerberos?::
* @value{PRODUCT} Documentation::
* Restoring a Kerberos Database from a Dump File::
* Creating a Stash File::
* Creating and Destroying a Kerberos Database::
-* The KDC Logs::
@end menu
@node Kadmin Options, Date Format, Administrating Kerberos Database Entries, Administrating Kerberos Database Entries
@smallexample
@group
-1 month ago
-2 hours ago
-400000 seconds ago
-last year
-this Monday
-next Monday
+"15 minutes"
+"7 days"
+"1 month"
+"2 hours"
+"400000 seconds"
+"next year"
+"this Monday"
+"next Monday"
yesterday
tomorrow
now
-second Monday
-a fortnight ago
-3/31/92 10:00:07 PST
-January 23, 1987 10:05pm
-22:00 GMT
+"second Monday"
+fortnight
+"3/31/92 10:00:07 PST"
+"January 23, 1987 10:05pm"
+"22:00 GMT"
@end group
@end smallexample
-All of these are case-insensitive. The following is a list of all of
+Note that if the date specification contains spaces, you must enclose it
+in double quotes. Note also that you cannot use a number without a
+unit. (I.e., ``"60 seconds"'' is correct, but ``60'' is incorrect.)
+All keywords are case-insensitive. The following is a list of all of
the allowable keywords.
@table @b
am, pm
@end table
-@menu
-* Principals::
-* Policies::
-* The KDC Logs::
-@end menu
-
@node Principals, Policies, Date Format, Administrating Kerberos Database Entries
@section Principals
@group
@b{shell%} kadmin
@b{kadmin:} getprinc @value{RANDOMUSER1}/root
-@b{Principal: @value{RANDOMUSER1}/admin@@@value{PRIMARYREALM}
+@b{Principal: @value{RANDOMUSER1}/root@@@value{PRIMARYREALM}
Key version: 3
Maximum life: 1 day 00:00:00
Maximum renewable life: 7 days 00:00:00
@b{kadmin:} getprinc -terse systest
@b{systest@@@value{PRIMARYREALM} 3 86400 604800 1
785926535 753241234 785900000
-@value{RANDOMUSER1}/admin@@@value{PRIMARYREALM} 786100034 0
+@value{ADMINUSER}/admin@@@value{PRIMARYREALM} 786100034 0
0
kadmin:}
@end group
@smallexample
@group
-@b{kadmin:} renprinc tlyutest test0
+@b{kadmin:} renprinc test test0
@b{Are you sure you want to rename the principal
"test@@@value{PRIMARYREALM}" to
-"test2@@@value{PRIMARYREALM}"? (yes/no):} yes
+"test0@@@value{PRIMARYREALM}"? (yes/no):} yes
@b{Principal "test@@@value{PRIMARYREALM}" renamed to
-"test2@@@value{PRIMARYREALM}".
+"test0@@@value{PRIMARYREALM}".
Make sure that you have removed "test@@@value{PRIMARYREALM}" from
all ACLs before reusing.
kadmin:}
If you do not specify a stash file, @code{kdb5_util} will stash the key
in the file specified in your @code{kdc.conf} file.
-@node Creating and Destroying a Kerberos Database, The KDC Logs, Creating a Stash File, Administrating Kerberos Database Entries
+@node Creating and Destroying a Kerberos Database, , Creating a Stash File, Administrating Kerberos Database Entries
@section Creating and Destroying a Kerberos Database
If you need to create a new Kerberos database, use the @code{kdb5_util}
@end smallexample
@ignore
-@node The KDC Logs, , Creating and Destroying a Kerberos Database, Administrating Kerberos Database Entries
-@section The KDC Logs
+@c @node The KDC Logs, , Creating and Destroying a Kerberos Database, Administrating Kerberos Database Entries
+@c @section The KDC Logs
This will have to wait until the next release. *sigh*
@end ignore
-@node Application Servers, Updates, Administrating Kerberos Database Entries, Top
+@node Application Servers, Backups of Secure Hosts, Administrating Kerberos Database Entries, Top
@chapter Application Servers
If you need to install the @value{PRODUCT} programs on an application
* Clock Skew::
* Getting DNS Information Correct::
* Configuring Your Firewall to Work With @value{PRODUCT}::
-* Enabling Users to Connect from Off-Site::
@end menu
@node Keytabs, Clock Skew, Application Servers, Application Servers
and then @code{klist}, the host's service principal should be
@i{host/fully-qualified-hostname@@REALM_NAME}.
-@node Configuring Your Firewall to Work With @value{PRODUCT}, Enabling Users to Connect from Off-Site, Getting DNS Information Correct, Application Servers
+@node Configuring Your Firewall to Work With @value{PRODUCT}, , Getting DNS Information Correct, Application Servers
@section Configuring Your Firewall to Work With @value{PRODUCT}
If you need off-site users to be able to get Kerberos tickets in your
Security}, by David Curry, is also a good starting point.
@ignore
-@node Enabling Users to Connect from Off-Site, , Configuring Your Firewall to Work With @value{PRODUCT}, Application Servers
-@section Enabling Users to Connect from Off-Site
+@c @node Enabling Users to Connect from Off-Site, , Configuring Your Firewall to Work With @value{PRODUCT}, Application Servers
+@c @section Enabling Users to Connect from Off-Site
This will have to wait until the next release. *sigh*
@end ignore
-@ifset CYGNUS
-@node Updates, Backups of Secure Hosts, Application Servers, Top
-@chapter Updates
-
-Because the directory into which @value{PRODUCT} installs itself
-contains the release name, it is easy to install a new release of
-@value{PRODUCT}, and to de-install an old one. If you have a problem
-with a new release, it is equally easy to revert to the earlier release.
-These procedures will also work if you are updating from any other
-version of Kerberos V5.
-
-@menu
-* Updating KDCs::
-* Updating Application Servers::
-@end menu
-
-@node Updating KDCs, Updating Application Servers, Updates, Updates
-@section Updating KDCs
-
-To update a KDC from an earlier version of @value{PRODUCT} or of
-Kerberos V5, you need to do the following:
-
-@enumerate
-@item
-Install the new software.
-@item
-Copy your @code{kdc.conf} file and stash file from the old installation
-to the new one. For example, if you were upgrading from @value{PRODUCT}
-version @value{PREVRELEASE} to version @value{RELEASE}, you would have
-to copy these files from the directory @value{PREVINSTALLDIR} to the
-directory @value{INSTALLDIR}. Be sure the new copy of the stash file
-has the correct name. (The default is @code{.k5stash}, unless you have
-specified something different in your @code{kdc.conf} file.)
-@item
-Create a dump of the old database, using whichever old command you used
-with that release (@i{e.g.,} the @code{kdb5_dump} command).
-@item
-Load the dumpfile into the new database in the new location, using the
-@code{kdb5_util} @code{load} command. Be sure to give @code{load}
-the argument for the correct dump format.
-@item
-Change any symbolic links you have (@i{e.g.},
-@code{/usr/@value{LCPRODUCT}}) so that they point to the new
-installation.
-@end enumerate
-@c Reference to upgrading from Kerberos V4 document, once it's written.
-
-@node Updating Application Servers, , Updating KDCs, Updates
-@section Updating Clients and Application Servers
-
-To update a client or application server, you need only to install the
-new release and change any symbolic links to point to the new programs.
-Other than any functionality changes in the programs, the upgrade should
-be completely user-transparent.
-@c Reference to upgrading from Kerberos V4 document, once it's written.
-@end ifset
-
-@node Backups of Secure Hosts, Support, Updates, Top
+@node Backups of Secure Hosts, Bug Reporting, Application Servers, Top
@chapter Backups of Secure Hosts
When you back up a secure host, you should exclude the host's keytab
most recent dump onto the master KDC. (@xref{Restoring a Kerberos
Database from a Dump File}.)
-@ifset CYGNUS
-@node Support, Bug Reporting, Backups of Secure Hosts, Top
-@chapter Support
-
-@menu
-* Supported Functionalities::
-* Using sendpr::
-@end menu
-
-@node Supported Functionalities, Using sendpr, Support, Support
-@section Supported Functionalities
-
-@node Using sendpr, , Supported Functionalities, Support
-@section Using sendpr
-
-@include send-pr.texinfo
-@end ifset
-
-@ifset MIT
-@node Bug Reporting, Appendix, Support, Top
+@node Bug Reporting, Appendix, Backups of Secure Hosts, Top
@chapter Bug Reporting
In any complex software, there will be bugs. Please send bug reports or
welcome. If you do include fixes, please send them using either context
diffs or unified diffs (using @samp{diff -c} or @samp{diff -u},
respectively).
-@end ifset
@node Appendix, , Bug Reporting, Top
@appendix Appendix
-@value{PRODUCT} is supplied in source form for a number of reasons:
-@itemize @bullet
-@item
-You can examine the source yourself, and verify the behavior of the
-system to your satisfaction. This is especially important with security
-software.
-@item
-You can make your own changes. (Of course, we recommend having us make
-the changes, so that we can include them in future releases.)
-@end itemize
+Starting with the Beta 4 distribution, we are using a new configuration
+system, which was built using the Free Software Foundation's
+@samp{autoconf} program. This system will hopefully make Kerberos V5
+much simpler to build and reduce the amount of effort required in
+porting Kerberos V5 to a new platform.
+
+@menu
+* Build Requirements:: How much disk space, etc. you need to
+ build Kerberos.
+* Unpacking the Sources:: Preparing the source tree.
+* Doing the Build:: Compiling Kerberos.
+* Testing the Build:: Making sure Kerberos built correctly.
+* Options to Configure::
+* osconf.h::
+* Shared Library Support::
+* OS Incompatibilities:: Special cases to watch for.
+* Using Autoconf:: Modifying Kerberos V5's
+ configuration scripts.
+@end menu
+
+@node Build Requirements, Unpacking the Sources, , Building Kerberos V5
+@section Build Requirements
+
+In order to build Kerberos V5, you will need approximately 60-70
+megabytes of disk space. The exact amount will vary depending on the
+platform and whether the distribution is compiled with debugging symbol
+tables or not.
+
+If you wish to keep a separate @dfn{build tree}, which contains the compiled
+@file{*.o} file and executables, separate from your source tree, you
+will need a @samp{make} program which supports @samp{VPATH}, or
+you will need to use a tool such as @samp{lndir} to produce a symbolic
+link tree for your build tree.
+
+@node Unpacking the Sources, Doing the Build, Build Requirements, Building Kerberos V5
+@section Unpacking the Sources
+
+The first step in each of these build procedures is to unpack the source
+distribution. The Kerberos V5 distribution comes in two compressed tar
+files. The first file, which is generally named @file{krb5.src.tar.gz},
+contains the sources for all of Kerberos except for the crypto library,
+which is found in the file @file{krb5.crypto.tar.gz}.
+
+Both files should be unpacked in the same directory, such as
+@file{/u1/krb5}. (In the rest of this document, we will assume that you
+have chosen to unpack the Kerberos V5 source distribution in this
+directory.)
+
+
+@node Doing the Build, Testing the Build, Unpacking the Sources, Building Kerberos V5
+@section Doing the Build
-@value{PRODUCT} is a large package. In order to efficiently manage
-sources across a large number of platforms, we've used certain tools
-that you may be unfamilar with, and we explain them here.
+You have a number of different options in how to build Kerberos. If you
+only need to build Kerberos for one platform, using a single directory
+tree which contains both the source files and the object files is the
+simplest. However, if you need to maintain Kerberos for a large number
+of platforms, you will probably want to use separate build trees for
+each platform. We recommend that you look at see @ref{OS
+Incompatibilities} for notes that we have on particular operating
+systems.
@menu
-* Requirements:: Requirements
-* Setup:: Setting Up the files
-* Testing:: Testing the release
-* Constructing an Install Kit:: Constructing a tar file or package
+* Building Within a Single Tree::
+* Building with Separate Build Directories::
+* Building using lndir::
@end menu
-@node Requirements, Setup, Compiling @value{PRODUCT}, Compiling @value{PRODUCT}
-@section Requirements
-
-At the very minimum, you need a Unix-like operating system with a C
-compiler. (The MacOS and Windows ports are not discussed here.) While
-an ANSI C compiler is preferred, mostly because it is likely to be a
-more recent compiler, the build process checks for particular features
-and works around them in most cases. We
-@ifset CYGNUS
-of course
-@end ifset
-recommend gcc, but we
-test the compilation with both gcc and the "native" or OS-vendor
-supplied compiler whenever possible.
-
-You also need a version of @code{make}. We recommend GNU make, but
-again, we test with the vendor-supplied one as well. Most native
-implementations of make are sufficient to build @value{PRODUCT} directly
-in the source tree. Having a seperate build tree is far more
-convenient, and is what we recommend; this usually needs GNU make
-because of the variation in support of @samp{VPATH}.
-
-If you're only going to compile the unchanged source, or are only going
-to change C files, you should be set. If you're going to change some
-part of the build process (any of the @file{Makefile}s---more
-specifically, any of the @file{configure.in} or @file{Makefile.in} files
-that generate them) you're going to need a recent version of GNU m4.
-
-@node Setup, Testing, Requirements, Compiling @value{PRODUCT}
-@section Setup
-
-We recommend a directory structure as follows:
-@table @file
-@item krb5
-is the source tree itself.
-@item src
-is a symlink farm pointing into the source tree.
-@item @var{platform}
-is a directory for a particular build platform. It may be more
-convenient for you to name these by hostname, but if you're keeping the
-trees around for any length of time it is better to label them by vendor
-and version.
-@end table
+@node Building Within a Single Tree, Building with Separate Build Directories, Doing the Build, Doing the Build
+@subsection Building Within a Single Tree
-Given the above structure, unpack the tar file of sources.
+If you don't want separate build trees for each architecture, then
+use the following abbreviated procedure.
-If you don't have GNU m4, or are not planning to change anything, simply
-@example
- mv krb5 src
-@end example
+@enumerate
+@item
+ @code{cd /u1/krb5/src}
+@item
+ @code{./configure}
+@item
+ @code{make}
+@end enumerate
-If you are likely to be changing build-related information, then the
-procedure
-@example
- % mkdir src
- % cd src
- % ../krb5/util/lndir ../krb5
-@end example
-@noindent will produce the symlink farm, then
-@example
- % rm Makefile
- % cd util/autoconf
- % ./configure
- % make
- % cd ../..
- % util/reconf
- % cd ..
-@end example
-The reconf step will take a while, as it regenerates the build scripts.
-If you change @file{aclocal.m4}, @file{Makefile.in}, or
-@file{configure.in}, you can rerun @file{util/reconf} (causing it to
-rebuild only those things that need to.) If you're just making changes
-to a @file{Makefile.in} or @file{configure.in} in one directory, the
-make rules will take care of rerunning @file{autoconf} to rebuild them
-directly.
-
-In order to build a particular platform, simply
-@example
- % mkdir platform
- % cd platform
- % ../src/configure --@var{configure options}
- % make all @{@var{MAKE OPTIONS}@}
- % make check
- % make install
-@end example
+That's it!
+
+@node Building with Separate Build Directories, Building using lndir, Building Within a Single Tree, Doing the Build
+@subsection Building with Separate Build Directories
+
+If you wish to keep separate build directories for each platform, you
+can do so using the following procedure. (Note, this requires that your
+@samp{make} program support @samp{VPATH}. GNU's make will provide this
+functionality, for example.) If your @samp{make} program does not
+support this, see the next section.
+
+For example, if you wish to create a build directory for @code{pmax} binaries
+you might use the following procedure:
+
+@enumerate
+@item
+@code{mkdir /u1/krb5/pmax}
+@item
+ @code{cd /u1/krb5/pmax}
+@item
+ @code{../src/configure}
+@item
+ @code{make}
+@end enumerate
+
+@node Building using lndir, , Building with Separate Build Directories, Doing the Build
+@subsection Building Using @samp{lndir}
+
+If you wish to keep separate build directories for each platform, and
+you do not have access to a @samp{make} program which supports @samp{VPATH},
+all is not lost. You can use the @samp{lndir} program to create
+symbolic link trees in your build directory.
+
+For example, if you wish to create a build directory for solaris binaries
+you might use the following procedure:
+
+@enumerate
+@item
+ @code{mkdir /u1/krb5/solaris}
+@item
+ @code{cd /u1/krb5/solaris}
+@item
+ @code{/u1/krb5/src/util/lndir `pwd`/../src}
+@item
+ @code{./configure}
+@item
+ @code{make}
+@end enumerate
+
+You must give an absolute pathname to @samp{lndir} because it has a bug that
+makes it fail for relative pathnames. Note that this version differs
+from the latest version as distributed and installed by the XConsortium
+with X11R6. Either version should be acceptable.
+
+@node Testing the Build, Options to Configure, Doing the Build, Building Kerberos V5
+@section Testing the Build
+
+The Kerberos V5 distribution comes with built-in regression tests. To
+run them, simply type the following command while in the top-level build
+directory (i.e., the directory where you sent typed @samp{make} to start
+building Kerberos; see @ref{Doing the Build}.):
-If @samp{cc} isn't a working compiler (stock Solaris, for example) you
-should also do a
@example
- setenv CC gcc
+% make check
@end example
-before running configure.
@menu
-* Make Options::
-* Configure Options::
+* The DejaGnu Tests::
@end menu
-@node Make Options, Configure Options, Setup, Setup
-@subsection Make Options
+@node The DejaGnu Tests, , Testing the Build, Testing the Build
+@subsection The DejaGnu Tests
+
+Some of the built-in regression tests are setup to use the DejaGnu
+framework for running tests. These tests tend to be more comprehensive
+than the normal built-in tests as they setup test servers and test
+client/server activities.
+
+DejaGnu may be found wherever GNU software is archived.
+
+Most of the tests are setup to run as a non-privledged user. There are
+two series of tests (@samp{rlogind} and @samp{telnetd}) which require
+the ability to @samp{rlogin} as root to the local machine. Admittedly,
+this does require the use of a @file{.rhosts} file or some other
+authenticated means. @footnote{If you are fortunate enough to have a
+previous version of Kerberos V5 or V4 installed, and the Kerberos rlogin
+is first in your path, you can setup @file{.k5login} or @file{.klogin}
+respectively to allow you access.}
+
+If you cannot obtain root access to your machine, all the other tests
+will still run. Note however, with DejaGnu 1.2, the "untested testcases"
+will cause the testsuite to exit with a non-zero exit status which
+@samp{make} will consider a failure of the testing process. Do not worry
+about this, as these tests are the last run when @samp{make check} is
+executed from the top level of the build tree.
+
-@var{MAKE OPTIONS} include
-@itemize @bullet
-@item @code{CC=@var{compiler}}
-@item @code{CCOPTS=@var{compiler flags}}
-@end itemize
-which get automatically propagated to all subdirectories.
+@node Options to Configure, osconf.h, Testing the Build, Building Kerberos V5
+@section Options to Configure
-@node Configure Options, , Make Options, Setup
-@subsection Configure Options
+There are a number of options to @samp{configure} which you can use to
+control how the Kerberos distribution is built. The following table
+lists the most commonly used options to Kerberos V5's @samp{configure}
+program.
-@var{configure options} include
@table @code
-@item --prefix @var{pathname}
-Specify that the installed tree be rooted at @var{pathname}. The MIT
-default is to use @file{/krb5} but
-@item --without-krb4
-Don't include any Kerberos V4 backwards compatibility support in
-applications, and don't build the V4 libraries either.
-@item --with-krb4
-@value{PRODUCT} V4 libraries (enhanced for compatibility use) are
-included as part of the @value{PRODUCT} V5 source tree. By default, or
-with this option, these are built and installed in @file{libkrb4.a} and
-are used in various utilities.
-@item --with-krb4=@var{KRB4DIR}
-Enable V4 backwards compatibility support, but use existing Kerberos
-libraries as preinstalled in @var{KRB4DIR}. Generally not used now that
-the V4 libraries are included.
-@item --with-cc=@var{COMPILER}
-Select compiler to use, and write it into the constructed
-@code{Makefile}s as the default value of @code{CC}.
-@item --with-linker=@var{LINKER}
-Select linker to use, and write it into the constructed @code{Makefile}s
-as the default value of @code{LD}. Useful for building with Purify.
-@item --with-ccopts=@var{CCOPTS}
-Select compiler command line options, and write it into the constructed
-@code{Makefile}s as the default value of @code{CCOPTS}. Useful for
-building with debugging or optimization.
-@item --with-cppopts=@var{CPPOPTS}
-Select compiler preprocessor command line options, and write it into the
-constructed @code{Makefile}s as the default value of @code{CPPOPTS}.
-Useful for setting flags.
-@item --with-netlib=@var{libs}
-Use user defined resolve library. Normally the resolver is part of the
-C library, but on SunOS systems using NIS, you may need to specify
-@code{-lresolv} in order to get a proper domain name resolver.
+
+@item --help
+
+Provides help to configure. This will list the set of commonly used
+options for building Kerberos.
+
+@item --prefix=DIR
+
+By default, Kerberos will install the package's files rooted at
+`/usr/local' as in `/usr/local/bin', `/usr/local/sbin', etc. If you
+desire a different location use this option.
+
+@item --exec-prefix=DIR
+
+This option allows one to separate the architecture independent programs
+from the configuration files and manual pages.
+
+@item --with-cc=COMPILER
+
+Use @code{COMPILER} as the C compiler.
+
+@item --with-ccopts=FLAGS
+
+Use @code{FLAGS} as the default set of C compiler flags.
+
+Note that if you use the native Ultrix compiler on a
+DECstation you are likely to lose if you pass no flags to cc; md4.c
+takes an estimated 3,469 billion years to compile if you provide neither
+the @samp{-g} flag nor the @samp{-O} flag to @samp{cc}.
+
+@item --with-cppopts=CPPOPTS
+
+Use @code{CPPOPTS} as the default set of C preprocessor flags. The most
+common use of this option is to select certain @code{#define}'s for use
+with the operating system's include files.
+
+@item --with-linker=LINKER
+
+Use @code{LINKER} as the default loader if it should be different from C
+compiler as specified above.
+
+@item --with-ldopts=LDOPTS
+
+This option allows one to specify optional arguments to be passed to the
+linker. This might be used to specify optional library paths.
+
+@item --with-krb4
+
+This option enables Kerberos V4 backwards compatibility using the
+builtin Kerberos V4 library.
+
+@item --with-krb4=KRB4DIR
+
+This option enables Kerberos V4 backwards compatibility. The directory
+specified by @code{KRB4DIR} specifies where the V4 header files should
+be found (@file{/KRB4DIR/include}) as well as where the V4 Kerberos
+library should be found (@file{/KRB4DIR/lib}).
+
+@item --without-krb4
+
+Disables Kerberos V4 backwards compatibility. This prevents Kerberos V4
+clients from using the V5 services including the KDC. This would be
+useful if you know you will never install or need to interact with V4
+clients.
+
+@item --with-netlib[=libs]
+
+Allows for suppression of or replacement of network libraries. By
+default, Kerberos V5 configuration will look for @code{-lnsl} and
+@code{-lsocket}. If your operating system has a broken resolver library
+(see @ref{Solaris versions 2.0 through 2.3}) or fails to pass the tests in
+@file{src/tests/resolv} you will need to use this option.
+
@item --enable-shared
-Construct @value{PRODUCT} V5 shared libraries. Not supported on all
-systems.
-@item --with-shared
-Use constructed shared (default) libraries.
-@item --without-shared
-Don't use any shared libraries when building @value{PRODUCT}.
-@ifset CYGNUS
-@item --without-afs
-The default, indicating that you don't have afs libraries to build with
-and therefore can't build @code{asetkey}, @code{aklog}, and
-@code{kascvt}.
-@item --with-afs=@var{AFSDIR}
-Use preinstalled AFS library tree located under @var{AFSDIR} to build
-the TransArc AFS support and conversion tools. These require V4
-compatibility to operate, and work in conjunction with @code{krb524d}.
-@item --enable-telnet-encryption
-Use non-standard encryption in telnet. The telnet implementation
-provides for the use of DES in a stream mode to encrypt the connection,
-but there are some user interface issues that may make it less safe.
-Always verify using @kbd{^[ enc status RET} that it was successful,
-rather than trusting the message which may have been inserted by an
-attacker. For this and other reasons, the encryption mode is not an
-Internet Standard as of October 1995, but work is expected in the coming
-year to change that.
-@item --disable-telnet-encryption
-Don't enable the non-standard telnet encryption mode described above.
-@end ifset
+
+This option will turn on the building and use of shared library objects
+in the Kerberos build. This option is only supported on certain
+platforms.
+
+@item --with-vague-errors
+
+If enabled, gives vague and unhelpful error messages to the client... er,
+attacker. (Needed to meet silly government regulations; most other
+sites will want to keep this undefined.)
+
+@item --with-kdc-kdb-update
+
+Set this option if you want to allow the KDC to modify the Kerberos
+database; this allows the last request information to be updated, as
+well as the failure count information. Note that this doesn't work if
+you're using slave servers!!! It also causes the database to be
+modified (and thus needing to be locked) frequently. Please note that
+the implementors do not regularly test this feature.
+
+@item --with-kdb-db=database
+
+The configuration process will try to determine a working set of
+libraries required to implement the Kerberos database. Configure will
+look for interfaces that use or emulate a @samp{ndbm} or @samp{dbm}
+library. Failing that, a build in copy of the Berkeley DB code will be
+used. You may decide to compile a different interface than the default
+by specifying one of "ndbm", "dbm", or "db".
+
+An important note on platforms where the @samp{ndbm} implementation is
+based on @sc{GDBM} (such as the Linux Slackware distribution). @sc{GDBM}
+has its own built in file locking which prevents simultaneous access to
+the database from two separate processes in which one wants to modify
+the database while the otherone only wants to read. (i.e. the KDC and
+administrative servers). In this case, you will need to specify the use
+of the Berkeley DB.
+
@end table
-@node Testing, Constructing an Install Kit, Setup, Compiling @value{PRODUCT}
-@section Testing
+For example, in order to configure Kerberos on a Solaris machine using
+the @samp{suncc} with the optimizer turned on, run the configure
+script with the following options:
+
+@example
+% ./configure --with-cc=suncc --with-ccopts=-O
+@end example
+
+@node osconf.h, Shared Library Support, Options to Configure, Building Kerberos V5
+@section @file{osconf.h}
+
+There is one configuration file which you may wish to edit to control
+various compile-time parameters in the Kerberos distribution:
+@file{include/krb5/stock/osconf.h}. The list that follows is by no means
+complete, just some of the more interesting variables.
+
+Please note: The former configuration file @file{config.h} no longer
+exists as its functionality has been merged into the auto-configuration
+process. @xref{Options to Configure}.
+
+
+@table @code
+
+@item DEFAULT_PROFILE_PATH
+
+The pathname to the file which contains the profiles for the known
+realms, their KDCs, etc.
+
+The profile file format is no longer the same format as Kerberos V4's
+@file{krb.conf} file.
+
+@item DEFAULT_LNAME_FILENAME
+
+The pathname to the database that maps authentication names to local
+account names. See kdb5_anadd(8).
+
+@item DEFAULT_KEYTAB_NAME
+
+The type and pathname to the default server keytab file (the equivalent
+of Kerberos V4's @file{/etc/srvtab}).
+
+@item DEFAULT_KDC_ENCTYPE
+
+The default encryption type for the KDC.
+
+@item KDCRCACHE
+
+The name of the replay cache used by the KDC.
+
+@item RCTMPDIR
+
+The directory which stores replay caches.
+
+@item DEFAULT_KDB_FILE
+
+The location of the default database
+
+@end table
+
+@node Shared Library Support, OS Incompatibilities, osconf.h, Building Kerberos V5
+@section Shared Library Support
+
+Shared library support is provided for a few operating systems. There
+are restrictions as to which compiler to use when using shared
+libraries. In all cases, executables linked with the shared libraries in
+this build process will have built in the location of the libraries,
+therefore obliterating the need for special LD_LIBRARY_PATH, et al environment
+variables when using the programs. Except where noted, multiple versions
+of the libraries may be installed on the same system and continue to
+work.
+
+Currently the supported platforms are: NetBSD 1.0A, AIX 3.2.5, AIX 4.1,
+Solaris 5.3, Alpha OSF/1 >= 2.1, HP-UX >= 9.X.
+
+To enable shared libraries on the above platforms, run the configure
+script with the option @samp{--enable-shared}.
+
+One special note is that if the Kerberos V4 compatibility is compiled
+in, you @b{must not} specify an alternate Kerberos V4 library from the
+one in the tree or you will be missing references.
+
+@menu
+* Shared Library Theory::
+* NetBSD Shared Library Support::
+* AIX Shared Library Support::
+* Solaris 5.3 Shared Library Support::
+* Alpha OSF/1 Shared Library Support::
+@end menu
+
+@node Shared Library Theory, NetBSD Shared Library Support, Shared Library Support, Shared Library Support
+@subsection Theory of How Shared Libraries are Used
+
+An explanation of how shared libraries are implemented on a given
+platform is too broad a topic for this manual. Instead this will touch
+on some of the issues that the Kerberos V5 tree uses to support version
+numbering and alternate install locations.
+
+Normally when one builds a shared library and then links with it, the
+name of the shared library is stored in the object
+(i.e. libfoo.so). Most operating systems allows one to change name that
+is referenced and we have done so, placing the version number into the
+shared library (i.e. libfoo.so.0.1). At link time, one would reference
+libfoo.so, but when one executes the program, the shared library loader
+would then look for the shared library with the alternate name. Hence
+multiple versions of shared libraries may be supported relatively
+easily. @footnote{Under AIX for the RISC/6000, multiple versions of
+shared libraries are supported by combining two or more versions of the
+shared library into one file. The Kerberos build procedure produces
+shared libraries with version numbers in the internal module names, so
+that the shared libraries are compatible with this scheme.
+Unfortunately, combining two shared libraries requires internal
+knowledge of the AIX shared library system beyond the scope of this
+document. Practicallyspeaking, only one version of AIX shared libraries
+can be supported on a system, unless the multi-version library is
+constructed by a programmer familiar with the AIX internals.}
+
+All operating systems (that we have seen) provide a means for programs
+to specify the location of shared libraries. On different operating
+systems, this is either specified when creating the shared library, and
+link time, or both.@footnote{Both are necessary sometimes as the shared
+libraries are dependent on other shared libraries} The build process
+will hardwire a path to the installed destination.
+
+
+@node NetBSD Shared Library Support, AIX Shared Library Support, Shared Library Theory, Shared Library Support
+@subsection NetBSD Shared Library Support
+
+Shared library support has been tested under NetBSD 1.0A using
+GCC 2.4.5. Due to the vagaries of the loader in the operating system,
+the library load path needs to be specified in building libraries and in
+linking with them. Unless the library is placed in a standard location
+to search for libraries, this may make it difficult for developers to
+work with the shared libraries.
+
+@node AIX Shared Library Support, Solaris 5.3 Shared Library Support, NetBSD Shared Library Support, Shared Library Support
+@subsection AIX Shared Library Support
+
+ AIX specifies shared library versions by combining multiple
+versions into a single file. Because of the complexity of this process,
+no automatic procedure for building multi-versioned shared libraries is
+provided. Therefore, supporting multiple versions of the Kerberos shared
+libraries under AIX will require significant work on the part of a
+programmer famiiliar with AIX internals.
+
+ AIX allows a single library to be used both as a static library
+and as a shared library. For this reason, the @samp{--enable-shared}
+switch to configure builds only shared libraries. On other operating
+systems, both shared and static libraries are built when this switch is
+specified. As with all other operating systems, only non-shared static
+libraries are built when @samp{--enable-shared} is not specified.
+
+ The AIX 3.2.5 linker dumps core trying to build a shared
+@samp{libkrb5.a} produced with the GNU C compiler. The native AIX
+compiler works fine. In addition, the AIX 4.1 linker is able to build a
+shared @samp{libkrb5.a} when GNU C is used.
+
+
+@node Solaris 5.3 Shared Library Support, Alpha OSF/1 Shared Library Support, AIX Shared Library Support, Shared Library Support
+@subsection Solaris 5.3 Shared Library Support
+
+Shared library support only works when using the Sunsoft C compiler. We
+are currently using version 3.0.1.
+
+The path to the shared library must be specified at link time as well as
+when creating libraries.
+
+@node Alpha OSF/1 Shared Library Support, , Solaris 5.3 Shared Library Support, Shared Library Support
+@subsection Alpha OSF/1 Shared Library Support
+
+Shared library support has been tested with V2.1 and higher of the
+operating system. Shared libraries may be compiled both with GCC and the
+native compiler.
+
+One of the nice features on this platform is that the paths to the
+shared libraries is specified in the library itself without requiring
+that one specify the same at link time.
+
+We are using the @samp{-rpath} option to @samp{ld} to place the library
+load path into the executables. The one disadvantage of this is during
+testing where we want to make sure that we are using the build tree
+instead of a possibly installed library. The loader uses the contents of
+@samp{-rpath} before LD_LIBRARY_PATH so we must specify a dummy _RLD_ROOT
+and complete LD_LIBRARY_PATH in our tests.
+
+The one disadvantage with the
+method we are using
+
+@node OS Incompatibilities, Using Autoconf, Shared Library Support, Building Kerberos V5
+@section Operating System Incompatibilities
+
+This section details operating system incompatibilities with Kerberos V5
+which have been reported to the developers at MIT. If you find additional
+incompatibilities, and/or discover work arounds to such problems, please
+send a report to @b{krb5-bugs@@mit.edu}. Thanks!
+
+@menu
+* Ultrix 4.2/3::
+* Alpha OSF/1 V1.3::
+* Alpha OSF/1 V2.0++::
+* BSDI::
+* Solaris versions 2.0 through 2.3::
+* Solaris 2.X::
+* SGI Irix 5.X::
+@end menu
+
+@node Ultrix 4.2/3, Alpha OSF/1 V1.3, OS Incompatibilities, OS Incompatibilities
+@subsection Ultrix 4.2/3
+
+On the DEC MIPS platform, using the native compiler, @file{md4.c} and
+@file{md5.c} can not be compiled with the optimizer set at level 1.
+That is, you must specify either @samp{--with-ccopts=-O} and
+@samp{--with-ccopts=-g} to configure. If you don't specify either, the
+compile will never complete.
+
+The optimizer isn't hung; it just takes an exponentially long time.
+Compiling 6 out of the 48 algorithmic steps takes 3 seconds; compiling 7
+steps takes 9 seconds; compiling 8 steps takes 27 seconds, and so on.
+Calculations estimate it will finish in approximately 3,469 billion
+years....
+
+Using GCC instead of the native compiler will also work fine, both with
+or without optimization.
+
+@node Alpha OSF/1 V1.3, Alpha OSF/1 V2.0++, Ultrix 4.2/3, OS Incompatibilities
+@subsection Alpha OSF/1 V1.3
+
+Using the native compiler, compiling with the @samp{-O} compiler flag
+causes the @code{asn.1} library to be compiled incorrectly.
+
+Using GCC version 2.6.3 or later instead of the native compiler will also work
+fine, both with or without optimization.
+
+@node Alpha OSF/1 V2.0++, BSDI, Alpha OSF/1 V1.3, OS Incompatibilities
+@subsection Alpha OSF/1 V2.0++
+
+There used to be a bug when using the native compiler in compiling
+@file{md4.c} when compiled without either the @samp{-O} or @samp{-g}
+compiler options. We have changed the code and there is no problem
+under V2.1, but we do not have access to V2.0 to test and see if the
+problem would exist there. (We welcome feedback on this issue). There
+was never a problem in using GCC version 2.6.3.
+
+In version 3.2 and beyond of the operating system, we have not seen any
+problems with the native compiler.
+
+@node BSDI, Solaris versions 2.0 through 2.3, Alpha OSF/1 V2.0++, OS Incompatibilities
+@subsection BSDI
+
+BSDI versions 1.0 and 1.1 reportedly has a bad @samp{sed} which causes
+it to go into an infinite loop during the build. The work around is
+to use a @samp{sed} from somewhere else, such as GNU. (This may be
+true for some versions of other systems derived from BSD 4.4, such as
+NetBSD and FreeBSD.)
+
+@node Solaris versions 2.0 through 2.3, Solaris 2.X, BSDI, OS Incompatibilities
+@subsection Solaris versions 2.0 through 2.3
+
+The @code{gethostbyname()} routine is broken; it does not return a fully
+qualified domain name, even if you are using the Domain Name Service
+routines. Since Kerberos V5 uses the fully qualified domain name as the
+second component of a service principal (i.e,
+@samp{host/tsx-11.mit.edu@@ATHENA.MIT.EDU}), this causes problems for servers
+who try to figure out their own fully qualified domain name.
+
+Workarounds:
+
+@enumerate
-After running @code{make all} successfully, you should run the
-collection of built in test cases. Running @code{make check} will run a
-number of built in tests of
-@itemize @bullet
@item
-raw database code
+ Supply your own resolver library. (such as bind-4.9.3pl1 availavle
+from ftp.vix.com)
+
@item
-raw encryption code
+ Upgrade to Solaris 2.4
+
@item
-various Kerberos V5 interfaces including @code{kdb5}
-@end itemize
-
-If you have @code{runtest} from the DejaGnu package
-@footnote{@code{prep.ai.mit.edu:/pub/gnu/dejagnu-1.3.tar.gz} as of this
-writing} installed, this will also run a set of live application tests,
-creating a test realm, starting a Kerberos server, @code{kadmind}, and
-clients, and testing their features the way a human would use them. The
-end summary should list no unexpected failures.
-
-If you do find problems, you can get more specific detail by changing to
-the @file{tests/dejagnu} directory and running @code{runtest} with the
-@samp{-d} option, and examining the @file{dbg.log} file produced. (This
-will not be necessary with any platform supported by @value{COMPANY}.)
-
-@node Constructing an Install Kit, , Testing, Compiling @value{PRODUCT}
-@section Constructing an Install Kit
-
-You can construct an install kit by creating an install directory and
-running @code{make install DESTDIR=@var{install directory}}, and then
-using @samp{tar cf} to produce a tar file. In the future, there may be
-direct make targets to support construction of @code{tar} files and
-@sc{svr4} packages.
+ Make sure your /etc/nsswitch.conf has `files' before `dns' like:
+
+@example
+hosts: files dns
+@end example
+
+and then in /etc/hosts, make sure there is a line with your
+workstation's IP address and hostname, with the fully qualified domain
+name first. Example:
+
+@example
+18.172.1.4 dcl.mit.edu dcl
+@end example
+
+Note that making this change may cause other programs in your
+environment to break or behave differently.
+
+@end enumerate
+
+@node Solaris 2.X, SGI Irix 5.X, Solaris versions 2.0 through 2.3, OS Incompatibilities
+@subsection Solaris 2.X
+
+You @b{must} compile Kerberos V5 without the UCB compatibility
+libraries. This means that @file{/usr/ucblib} must not be in the
+LD_LIBRARY_PATH environment variable when you compile it. Alternatively
+you can use the @code{-i} option to @samp{cc}, by using the specifying
+@code{--with-ccopts=-i} option to @samp{configure}.
+
+@node SGI Irix 5.X, , Solaris 2.X, OS Incompatibilities
+@subsection SGI Irix 5.X
+
+If you are building in a tree separate from the source tree, the vendors
+version of make does not work properly with regards to
+@samp{VPATH}. It also has problems with standard inference rules in 5.2
+(not tested yet in 5.3) so one needs to use GNU's make.
+
+Under 5.2, there is a bug in the optional System V @code{-lsocket}
+library in which the routine @code{gethostbyname()} is broken. The
+system supplied version in @code{-lc} appears to work though so one may
+simply specify @code{--with-netlib} option to @samp{configure}.
+
+In 5.3, @code{gethostbyname()} is no longer present in @code{-lsocket} and
+is no longer an issue.
+
+@node Using Autoconf, , OS Incompatibilities, Building Kerberos V5
+@section Using @samp{Autoconf}
+
+(If you are not a developer, you can skip this section.)
+
+In most of the Kerberos V5 source directories, there is a
+@file{configure} script which automatically determines the compilation
+environment and creates the proper Makefiles for a particular platform.
+These @file{configure} files are generated using @samp{autoconf} version
+2.4, which can be found in the @file{src/util/autoconf} directory in the
+distribution.
+
+Normal users will not need to worry about running @samp{autoconf}; the
+distribution comes with the @file{configure} files already prebuilt.
+Developers who wish to modify the @file{configure.in} files should see
+@ref{Top, , Overview, autoconf, The Autoconf Manual}.
+
+Note that in order to run @samp{autoconf}, you must have GNU @samp{m4}
+in your path. Before you use the @samp{autoconf} in the Kerberos V5
+source tree, you may also need to run @samp{configure}, and then run
+@samp{make} in the @file{src/util/autoconf} directory in order to
+properly set up @samp{autoconf}.
+
+One tool which is provided for the convenience of developers can be
+found in @file{src/util/reconf}. This program should be run while the
+current directory is the top source directory. It will automatically
+rebuild any @file{configure} files which need rebuilding. If you know
+that you have made a change that will require that all the
+@file{configure} files need to be rebuilt from scratch, specify the
+@code{--force} option:
+
+@example
+% cd /u1/krb5/src
+% ./util/reconf --force
+@end example
+
+The developmental sources are a raw source tree (before it's been packaged
+for public release), without the pre-built @file{configure} files.
+In order to build from such a source tree, you must do:
+
+@example
+% cd krb5/util/autoconf
+% ./configure
+% make
+% cd ../..
+% util/reconf
+@end example
+
+Then follow the instructions for building packaged source trees (above).
+To install the binaries into a binary tree, do:
+
+@example
+% cd /u1/krb5/src
+% make all
+% make install DESTDIR=somewhere-else
+@end example
+@ifset CYGNUS
Copyright @copyright{} 1993, 1994, 1995, 1996 @value{COMPANY}.
@iftex
@vskip 12pt
@value{PRODUCT} includes documentation and software developed at the
Massachusetts Institute of Technology, which includes this copyright
information:
+@end ifset
Copyright @copyright{} 1995 by the Massachusetts Institute of Technology.
\input texinfo @c -*-texinfo-*-
@c
-@c NOTE: add /bin/login and xdm to client machine section
-@c
@c Note: the above texinfo file must include the "doubleleftarrow"
@c definitions added by jcb.
@c %**start of header
@page
@vskip 0pt plus 1filll
+@iftex
@include copyright.texinfo
+@end iftex
@end titlepage
@node Top, Introduction, (dir), (dir)
@value{PRODUCT}.
@include copyright.texinfo
+
@end ifinfo
@c The master menu is updated using emacs19's M-x texinfo-all-menus-update
@c node's forward and back pointers.
@c
@c ---------------------------------------------------------------------
+
@menu
* Introduction::
* Realm Configuration Decisions::
-* Compiling @value{PRODUCT}::
-* Installing @value{PRODUCT}::
-* Support::
-* Bug Reporting::
+* Building Kerberos V5::
+* Installing Kerberos V5::
+* Bug Reports for Kerberos V5::
* Files::
@end menu
@node Introduction, Realm Configuration Decisions, Top, Top
@chapter Introduction
-@ifset CYGNUS
-Congratulations on your purchase of @value{PRODUCT}. @value{COMPANY}
-believes @value{PRODUCT} provides the best network security available.
-Please let us know if we can be of assistance in getting your
-installation of @value{PRODUCT} set up and running.
-@end ifset
-
@menu
* What is Kerberos and How Does it Work?::
* Why Should I use Kerberos?::
-* @value{PRODUCT} Documentation::
* Please Read the Documentation::
* Overview of This Guide::
@end menu
additional tickets, which give permission for specific services. The
requesting and granting of these additional tickets is user-transparent.
-@node Why Should I use Kerberos?, @value{PRODUCT} Documentation, What is Kerberos and How Does it Work?, Introduction
+@node Why Should I use Kerberos?, Please Read the Documentation, What is Kerberos and How Does it Work?, Introduction
@section Why Should I use Kerberos?
Since Kerberos negotiates authenticated, and optionally encrypted,
@value{PRODUCT} from @value{COMPANY} will play a vital role in the
security of your network.
-@node @value{PRODUCT} Documentation, Please Read the Documentation, Why Should I use Kerberos?, Introduction
-@section @value{PRODUCT} Documentation
-
-This document is one piece of the document set for @value{PRODUCT}. The
-documents, and their intended audiences, are:
-
@include document-list.texinfo
-@node Please Read the Documentation, Overview of This Guide, @value{PRODUCT} Documentation, Introduction
+@node Please Read the Documentation, Overview of This Guide, Why Should I use Kerberos?, Introduction
@section Please Read the Documentation
As with any software package that uses a centrallized database, the
The appendices give sample configuration files.
-@node Realm Configuration Decisions, Compiling @value{PRODUCT}, Introduction, Top
+@node Realm Configuration Decisions, Building Kerberos V5, Introduction, Top
@chapter Realm Configuration Decisions
Before installing @value{PRODUCT}, it is necessary to consider the
set of slaves, and then have each of these slaves propagate the database
to additional slaves.
-@ifclear CYGNUS
-
-@node Compiling @value{PRODUCT}, Installing @value{PRODUCT}, Realm Configuration Decisions, Top
-@chapter Compiling @value{PRODUCT}
+@node Building Kerberos V5, Installing Kerberos V5, Realm Configuration Decisions, Top
+@chapter Building @value{PRODUCT}
@include build.texinfo
-@end ifclear
-
-@node Installing @value{PRODUCT}, Support, Compiling @value{PRODUCT}, Top
+@node Installing Kerberos V5, Bug Reports for Kerberos V5, Building Kerberos V5, Top
@chapter Installing @value{PRODUCT}
The sections of this chapter describe procedures for installing
@menu
* Installing KDCs::
* Installing and Configuring UNIX Client Machines::
-* Installing and Configuring Windows Client Machines::
-* Installing and Configuring Macintosh Client Machines::
* UNIX Application Servers::
@end menu
-@node Installing KDCs, Installing and Configuring UNIX Client Machines, Installing @value{PRODUCT}, Installing @value{PRODUCT}
+@node Installing KDCs, Installing and Configuring UNIX Client Machines, Installing Kerberos V5, Installing Kerberos V5
@section Installing KDCs
The Key Distribution Centers (KDCs) issue Kerberos tickets. Each KDC
first few steps must be done on the master KDC.
@menu
-* Unpack the tar file::
* Edit the Configuration Files::
* Create the Database::
* Add Administrators to the Acl File::
* Start the Kerberos Daemons::
@end menu
-@ifset CYGNUS
-@node Unpack the tar file, Edit the Configuration Files, Install the Master KDC, Install the Master KDC
-@subsubsection Unpack the tar file
-
-Unpack the tar file on each KDC. Because of some specifications that
-are compiled into the software, you must install @value{PRODUCT} in the
-directory @code{@value{INSTALLDIR}}. If you extract the tar file from
-the top-level directory (@code{/}), the files will end up in this
-directory. Installation into other locations is not supported in this
-release, but is planned for future releases.
-
-@value{COMPANY} recommends that you choose a persistent directory name,
-and make it a symbolic link to @code{@value{INSTALLDIR}}, so
-you can install updates later without requiring users to change their
-paths. This document will refer to @code{@value{ROOTDIR}} as the
-persistent directory name.
-@end ifset
-
-@node Edit the Configuration Files, Create the Database, Unpack the tar file, Install the Master KDC
+@node Edit the Configuration Files, Create the Database, Install the Master KDC, Install the Master KDC
@subsubsection Edit the Configuration Files
Modify the configuration files, @code{/etc/krb5.conf}
especially a famous person (or cartoon character), your username in any
form (@i{e.g.}, forward, backward, repeated twice, @i{etc.}), and any of
the sample keys that appear in this manual. One example of a key which
-would be good if it did not appear in this manual is ``CSiys4K5!'',
+would be good if it did not appear in this manual is ``MITiys4K5!'',
which represents the sentence ``@value{COMPANY} is your source for
Kerberos 5!'' (It's the first letter of each word, substituting the
numeral ``4'' for the word ``for'', and includes the punctuation mark at
KDC as well as the slave KDCs, unless these instructions specify
otherwise.
+
@menu
-* Copy the Software onto the Slave KDCs::
* Create Host Keys for the Slave KDCs::
* Extract Host Keytabs for the KDCs::
* Set Up the Slave KDCs for Database Propagation::
@end menu
-@ifset CYGNUS
-@node Copy the Software onto the Slave KDCs, Create Host Keys for the Slave KDCs, Install the Slave KDCs, Install the Slave KDCs
-@subsubsection Copy the Software onto the Slave KDCs
-
-Unpack the tar file on each slave KDC as you did on the master. Once
-again, note that you must install @value{PRODUCT} in the directory
-@code{@value{INSTALLDIR}}. If you extract the tar file from the
-top-level directory (@code{/}), the files will end up in this directory.
-As with the master KDC, make the symbolic link to
-@code{@value{INSTALLDIR}} with the persistent name you chose earlier.
-Once you have unpacked the tar file, replace the configuration files,
-@code{krb5.conf} (@pxref{krb5.conf}) and @code{kdc.conf}
-(@pxref{kdc.conf}) with those you edited on the master KDC.
-@end ifset
-
-@node Create Host Keys for the Slave KDCs, Extract Host Keytabs for the KDCs, Copy the Software onto the Slave KDCs, Install the Slave KDCs
+@node Create Host Keys for the Slave KDCs, Extract Host Keytabs for the KDCs, Install the Slave KDCs, Install the Slave KDCs
@subsubsection Create Host Keys for the Slave KDCs
Each KDC needs a host principal in the Kerberos database. You can enter
machine in your Kerberos realm.)
@end enumerate
-@node Installing and Configuring UNIX Client Machines, Installing and Configuring Windows Client Machines, Installing KDCs, Installing @value{PRODUCT}
+@node Installing and Configuring UNIX Client Machines, UNIX Application Servers, Installing KDCs, Installing Kerberos V5
@section Installing and Configuring UNIX Client Machines
Client machine installation is much more straightforward than
installation of the KDCs.
@menu
-* Unpack the tar File::
* Client Programs::
* Client Machine Configuration Files::
@end menu
-@ifset CYGNUS
-@node Unpack the tar File, Client Programs, Installing and Configuring UNIX Client Machines, Installing and Configuring UNIX Client Machines
-@subsection Unpack the tar File
-
-Install @value{PRODUCT} in @code{@value{ROOTDIR}}. If you extract the
-tar file from the top level directory (@code{/}), the files will end up
-in this directory.
-@end ifset
-
-@node Client Programs, Client Machine Configuration Files, Unpack the tar File, Installing and Configuring UNIX Client Machines
+@node Client Programs, Client Machine Configuration Files, Installing and Configuring UNIX Client Machines, Installing and Configuring UNIX Client Machines
@subsection Client Programs
The Kerberized client programs are @code{login.krb5}, @code{rlogin},
-@code{telnet}, @code{ftp}, @code{rcp}, @code{rsh}, @code{xdm},
-@code{kinit}, @code{klist}, @code{kdestroy}, @code{kpasswd}, @code{ksu},
+@code{telnet}, @code{ftp}, @code{rcp}, @code{rsh}, @code{kinit},
+@code{klist}, @code{kdestroy}, @code{kpasswd}, @code{ksu},
@c @code{krb524init},
and @code{krdist}. All of these programs are in the directory
-@code{@value{ROOTDIR}/bin}, except for @code{login.krb5} and @code{xdm},
-which are in @code{@value{ROOTDIR}/sbin}.
+@code{@value{ROOTDIR}/bin}, except for @code{login.krb5} which is in
+@code{@value{ROOTDIR}/sbin}.
You will probably want to have your users put @code{@value{ROOTDIR}/bin}
ahead of @code{/bin} and @code{/usr/bin} in their paths, so they will by
default get the @value{PRODUCT} versions of @code{rlogin},
@code{telnet}, @code{ftp}, @code{rcp}, and @code{rsh}.
-@value{COMPANY} recommends that you use @code{login.krb5}, and
-@value{PRODUCT} @code{xdm} in place of @code{/bin/login} and ordinary
-@code{xdm}, to give your users a single-sign-on system. You will need
-to make sure your users know to use their Kerberos passwords when they
-log in.
+@value{COMPANY} recommends that you use @code{login.krb5} in place of
+@code{/bin/login} to give your users a single-sign-on system. You will
+need to make sure your users know to use their Kerberos passwords when
+they log in.
You will also need to educate your users to use the ticket management
programs @code{kinit},
@c @code{from}
@code{su}, @code{passwd}, and @code{rdist}.
-@menu
-* Configuring the X Display Manager (Xdm)::
-* Additional Xdm Configuration for AIX Machines::
-@end menu
-
-@node Configuring the X Display Manager (Xdm), Additional Xdm Configuration for AIX Machines, Client Programs, Client Programs
-@subsubsection Configuring the X Display Manager (Xdm)
-
-You will need to edit the @code{xdm} configuration files slightly, based
-on your installation. The files are in the directory
-@code{@value{ROOTDIR}/lib/X11/xdm}. You will need to add a line of the
-following form to the file @code{Xservers} in that directory:
-
-@smallexample
-:0 local /usr/bin/X11/X :0
-@end smallexample
-
-@noindent
-Replace @code{/usr/bin/X11/X} with the path to your X server, and
-@samp{:0} with the actual display name, if different.
-
-If you will be having @code{xdm} manage multiple displays, you will need
-to add lines to the @code{xdm-config} file for those displays. The
-following lines are shipped in the file, for display @samp{:0}:
-
-@smallexample
-@group
-DisplayManager._0.authorize: true
-DisplayManager._0.setup: @value{ROOTDIR}/lib/X11/xdm/Xsetup_0
-DisplayManager._0.startup: @value{ROOTDIR}/lib/X11/xdm/GiveConsole
-DisplayManager._0.reset: @value{ROOTDIR}/lib/X11/xdm/TakeConsole
-@end group
-@end smallexample
-
-The @samp{_0} in these lines translates to display @samp{:0}. Add
-equivalent lines for other displays. Replace the @samp{_0} with the
-other display names, substituting underscores (@samp{_}) for the
-@samp{:} and @samp{.} characters.
-
-@node Additional Xdm Configuration for AIX Machines, , Configuring the X Display Manager (Xdm), Client Programs
-@subsubsection Additional Xdm Configuration for AIX Machines
-
-If you have machines running AIX, you will need to do some additional
-configuration. Also note that under AIX, multiple non-network logins
-(on the console or via a serial port) will all use the same ticket file.
-
-For AIX, the line in the @code{Xservers} file described above needs the
-@code{-force} option, as in the following example:
-
-@smallexample
-:0 local /usr/lpp/X11/bin/X -force :0
-@end smallexample
-
-@noindent
-Again, replace @code{/usr/lpp/X11/bin/X} with the correct path for your
-X server, and @samp{:0} with the actual display name, if different.
-
-Also, you need to make the following changes to files in the directory
-@code{/etc/security}.
-
-In the file @code{login.cfg}, you need to add the following lines under
-the ``Authentication methods'' section
-
-@smallexample
-@group
-@value{CPRODUCT}:
- program = @value{ROOTDIR}/sbin/login-auth
-@end group
-@end smallexample
-
-In the file @code{/etc/security/user}, add the following lines, under
-the @samp{default:} heading:
-
-@smallexample
-@group
-auth1 = @value{CPRODUCT}
-auth2 = none
-SYSTEM = NONE
-@end group
-@end smallexample
-
-@noindent
-You can comment out any previous values for @code{auth1}, @code{auth2},
-and @code{SYSTEM} using the @samp{*} character.
-
-Additionally, assuming you want to allow root to log in to the machine
-locally (instead of using Kerberos), you also need to add the following
-lines to the @samp{root:} section of @code{/etc/security/user}:
-
-@smallexample
-@group
-auth1 = SYSTEM
-SYSTEM = "compat"
-@end group
-@end smallexample
-
-@noindent
-You will also need to do the same for any other user who needs to log in
-locally.
-
-Note that if Kerberos authentication succeeds, but the native login
-program is unable to log the user in (@i{e.g.}, if it can't find the
-user's shell), the ticket file may not be destroyed.
-
-You may also want to edit the @code{/etc/environment} and/or
-@code{/etc/TIMEZONE} files to get any desired variables into the user's
-environment.
-
-Finally, because the AIX login program does not destroy tickets
-automatically upon completion, users need to put the @code{kdestroy}
-command in their @code{.logout} files.
-
@node Client Machine Configuration Files, , Client Programs, Installing and Configuring UNIX Client Machines
@subsection Client Machine Configuration Files
@code{kerberos-sec} service (tcp and udp) on port 88, so the Kerberos
V4 KDC(s) will continue to work properly.
-@node Installing and Configuring Windows Client Machines, Installing and Configuring Macintosh Client Machines, Installing and Configuring UNIX Client Machines, Installing @value{PRODUCT}
-@section Installing and Configuring Windows Client Machines
-
-@value{PRODUCT} for Windows includes a GUI ticket management program
-(called @code{@value{CPRODUCT}}), a GUI telnet program, and a
-command-line telnet program that runs from within the @samp{Command
-Prompt}. The command-line program is included because encryption and
-ticket forwarding are not available for the GUI program in this release.
-The GUI programs are available for Windows 3.1, Windows95, and Windows
-NT. The command-line program is available only for Windows95 and
-Windows NT.
-
-@menu
-* Install the Executables::
-* Install the @code{krb5.conf} file::
-* Install an @code{\etc\passwd} file::
-* Check the Clock and Time Zone::
-* Create the Directory @code{\tmp}::
-* Set the Ticket File Location::
-@end menu
-
-@node Install the Executables, Install the @code{krb5.conf} file, Installing and Configuring Windows Client Machines, Installing and Configuring Windows Client Machines
-@subsection Install the Executables
-
-To install the ticket management program and the GUI telnet program,
-simply run the @code{setup} program and answer the questions. To
-install the command-line telnet program, copy the @code{telnet.exe} and
-@code{cygwin.dll} programs into the directory of your choice.
-
-@node Install the @code{krb5.conf} file, Install an @code{\etc\passwd} file, Install the Executables, Installing and Configuring Windows Client Machines
-@subsection Install the @code{krb5.conf} file
-
-Install the same @code{krb5.conf} file (@xref{krb5.conf}) you use on
-your UNIX client machines. The GUI programs will accept any path and
-filename for the configuration file; however, the command-line telnet
-program requires that the file be @code{\etc\krb5.conf}. Once you have
-installed the file, run the @code{@value{CPRODUCT}} program and enter
-the path and filename into the @samp{Configuration File} box under the
-@samp{Options} menu (under @samp{File}).
-
-@node Install an @code{\etc\passwd} file, Check the Clock and Time Zone, Install the @code{krb5.conf} file, Installing and Configuring Windows Client Machines
-@subsection Install an @code{\etc\passwd} file
-
-@need 1100
-For the command-line telnet program, you need to install an
-@code{\etc\passwd} file containing the usernames of the users who will
-be running the program. Each username must on its own line, with a
-colon at the end, as in the following example:
-
-@smallexample
-@group
-@value{RANDOMUSER1}:
-@value{RANDOMUSER2}:
-cbrown:
-@end group
-@end smallexample
-
-@node Check the Clock and Time Zone, Create the Directory @code{\tmp}, Install an @code{\etc\passwd} file, Installing and Configuring Windows Client Machines
-@subsection Check the Clock and Time Zone
-
-Make sure the clock and time zone are set correctly, and that the time
-is within the maximum clock skew of the KDC. The default maximum clock
-skew is five minutes.
-
-@node Create the Directory @code{\tmp}, Set the Ticket File Location, Check the Clock and Time Zone, Installing and Configuring Windows Client Machines
-@subsection Create the Directory @code{\tmp}
-
-If you are using the command-line telnet program, make sure the
-directory @code{\tmp} exists, since this is where it needs the default
-ticket files need to be stored.
-
-@node Set the Ticket File Location, , Create the Directory @code{\tmp}, Installing and Configuring Windows Client Machines
-@subsection Set the Ticket File Location
-
-From the @code{@value{CPRODUCT}} program, enter the path and filename
-for the ticket file location into the @samp{Credentials Cache Location}
-box under the @samp{Options} menu. Again, the GUI programs will accept
-any path and filename; however, the command-line telnet program requires
-that this be @code{\tmp\krb5cc_0}.
-
-@node Installing and Configuring Macintosh Client Machines, UNIX Application Servers, Installing and Configuring Windows Client Machines, Installing @value{PRODUCT}
-@section Installing and Configuring Macintosh Client Machines
-
-@value{PRODUCT} for the Macintosh includes a GUI ticket management program
-(called @code{@value{CPRODUCT} config}) and a GUI telnet program.
-
-@menu
-* Unpack the Executables::
-* Set Up your Configuration::
-* Set the Clock and Time Zone::
-@end menu
-
-@node Unpack the Executables, Set Up your Configuration, Installing and Configuring Macintosh Client Machines, Installing and Configuring Macintosh Client Machines
-@subsection Unpack the Executables
-
-To install the @code{@value{CPRODUCT} config} program and the
-@code{telnet} program, simply unpack the archive and answer the
-questions. Then move the programs into the folder of your choice.
-
-@node Set Up your Configuration, Set the Clock and Time Zone, Unpack the Executables, Installing and Configuring Macintosh Client Machines
-@subsection Set Up your Configuration
-
-To set up your configuration, run the @code{@value{CPRODUCT} config}
-program and enter the information from your site's @code{krb5.conf}
-file. Enter the hostname or IP address and realm for each KDC under the
-Server section. If the KDC is an admin server, check the ``Admin
-server'' box. Enter any domain/realm mappings in the Domain/Hostname
-section.
-
-@node Set the Clock and Time Zone, , Set Up your Configuration, Installing and Configuring Macintosh Client Machines
-@subsection Set the Clock and Time Zone
-
-Make sure the clock and time zone are set correctly, and that the time
-is within the maximum clock skew of the KDC. The default maximum clock
-skew is five minutes.
-
-@node UNIX Application Servers, , Installing and Configuring Macintosh Client Machines, Installing @value{PRODUCT}
+@node UNIX Application Servers, , Installing and Configuring UNIX Client Machines, Installing Kerberos V5
@section UNIX Application Servers
An application server is a host that provides one or more services over
@value{PRODUCT} binaries, should be kept on local disk. The keytab file
should be readable only by root.
-@ifset CYGNUS
-@node Support, Bug Reporting, Installing @value{PRODUCT}, Top
-@chapter Support
-
-If you have problems installing @value{PRODUCT}, please use the
-@code{send-pr} program to fill out a Problem Report.
-
-@include send-pr.texinfo
-@end ifset
-
-@ifset MIT
-@node Bug Reporting, Files, Support, Top
-@chapter Bug Reporting
-
-In any complex software, there will be bugs. Please send bug reports or
-other problems you may uncover to the e-mail address
-@b{krb5-bugs@@mit.edu}. Please mention which version of the Kerberos V5
-distribution you are using, and whether you have made any private
-changes. Bug reports that include proposed fixes are especially
-welcome. If you do include fixes, please send them using either context
-diffs or unified diffs (using @samp{diff -c} or @samp{diff -u},
-respectively).
-@end ifset
+@node Bug Reports for Kerberos V5, Files, Installing Kerberos V5, Top
+@chapter Bug Reports for @value{PRODUCT}
+@include bug-report.texinfo
-@node Files, , Bug Reporting, Top
+@node Files, , Bug Reports for Kerberos V5, Top
@appendix Files
@menu
@c Set the "MIT" flag for the MIT edition; set the "CYGNUS" flag for
@c the Cygnus edition.
-@set MIT
@clear CYGNUS
+@set MIT
@set ADMINUSER joeadmin
@set COMPANY MIT
@set KDCSERVER kerberos
@set INSTALLDIR /usr/@value{LCPRODUCT}
@set PREVINSTALLDIR @value{INSTALLDIR}
@set ROOTDIR /usr/@value{LCPRODUCT}
-@set BINDIR @value{ROOTDIR}/bin
+@set BINDIR /usr/@value{LCPRODUCT}/bin
@set SECONDDOMAIN fubar.org
@set SECONDREALM FUBAR.ORG
@set UPDATED @today
+This document is one piece of the document set for @value{PRODUCT}. The
+documents, and their intended audiences, are:
+
@itemize @bullet
@item
@b{@value{PRODUCT} Installation Guide}: a concise guide for installing
+If you have problems installing @value{PRODUCT}, please use the
+@code{send-pr} program to fill out a Problem Report.
+
The @code{send-pr} program is installed in the directory
@code{@value{ROOTDIR}/bin}.
\input texinfo @c -*-texinfo-*-
@c %**start of header
@c guide
-@setfilename kerberos-user.info
+@setfilename krb5-user.info
@settitle Kerberos V5 UNIX User's Guide
@setchapternewpage odd @c chapter begins on next odd page
@c @setchapternewpage on @c chapter begins on next page
@menu
* Introduction::
-* @value{PRODUCT} Tutorial::
-* @value{PRODUCT} Reference::
+* Kerberos V5 Tutorial::
+* Kerberos V5 Reference::
* Kerberos Glossary::
@end menu
-@node Introduction, @value{PRODUCT} Tutorial, Top, Top
+@node Introduction, Kerberos V5 Tutorial, Top, Top
@chapter Introduction
@value{PRODUCT} is based on the Kerberos V5 authentication system
the realm @code{@value{PRIMARYREALM}}.
@end itemize
-@node @value{PRODUCT} Tutorial, @value{PRODUCT} Reference, Introduction, Top
+@node Kerberos V5 Tutorial, Kerberos V5 Reference, Introduction, Top
@chapter @value{PRODUCT} Tutorial
This tutorial is intended to familiarize you with the @value{PRODUCT}
accordingly.
@menu
-* Setting Up to Use @value{PRODUCT}::
+* Setting Up to Use Kerberos V5::
* Ticket Management::
* Password Management::
-* @value{PRODUCT} Applications::
+* Kerberos V5 Applications::
@end menu
-@node Setting Up to Use @value{PRODUCT}, Ticket Management, @value{PRODUCT} Tutorial, @value{PRODUCT} Tutorial
+@node Setting Up to Use Kerberos V5, Ticket Management, Kerberos V5 Tutorial, Kerberos V5 Tutorial
@section Setting Up to Use @value{PRODUCT}
Your system administrator will have installed the @value{PRODUCT}
@value{PRODUCT} network programs, rather than the standard UNIX
versions, when you type their command names.
-@node Ticket Management, Password Management, Setting Up to Use @value{PRODUCT}, @value{PRODUCT} Tutorial
+@node Ticket Management, Password Management, Setting Up to Use Kerberos V5, Kerberos V5 Tutorial
@section Ticket Management
On many systems, Kerberos is built into the login program, and you get
@vfil
@end iftex
@need 2000
-@node Password Management, @value{PRODUCT} Applications, Ticket Management, @value{PRODUCT} Tutorial
+@node Password Management, Kerberos V5 Applications, Ticket Management, Kerberos V5 Tutorial
@section Password Management
Your password is the only way Kerberos has of verifying your identity.
@end iftex
@need 2000
-@node @value{PRODUCT} Applications, , Password Management, @value{PRODUCT} Tutorial
+@node Kerberos V5 Applications, , Password Management, Kerberos V5 Tutorial
@section @value{PRODUCT} Applications
@value{PRODUCT} is a @dfn{single-sign-on} system. This means that you
* ksu::
@end menu
-@node Overview of Additional Features, telnet, @value{PRODUCT} Applications, @value{PRODUCT} Applications
+@node Overview of Additional Features, telnet, Kerberos V5 Applications, Kerberos V5 Applications
@subsection Overview of Additional Features
The @value{PRODUCT} @dfn{network programs} are those programs that
@vfil
@end iftex
@need 2000
-@node telnet, rlogin, Overview of Additional Features, @value{PRODUCT} Applications
+@node telnet, rlogin, Overview of Additional Features, Kerberos V5 Applications
@subsection telnet
The @value{PRODUCT} @code{telnet} command works exactly like the
@vfil
@end iftex
@need 2000
-@node rlogin, FTP, telnet, @value{PRODUCT} Applications
+@node rlogin, FTP, telnet, Kerberos V5 Applications
@subsection rlogin
@need 1000
@vfil
@end iftex
@need 2000
-@node FTP, rsh, rlogin, @value{PRODUCT} Applications
+@node FTP, rsh, rlogin, Kerberos V5 Applications
@subsection FTP
@need 1000
@vfil
@end iftex
@need 2000
-@node rsh, rcp, FTP, @value{PRODUCT} Applications
+@node rsh, rcp, FTP, Kerberos V5 Applications
@subsection rsh
@need 1000
@vfil
@end iftex
@need 2000
-@node rcp, ksu, rsh, @value{PRODUCT} Applications
+@node rcp, ksu, rsh, Kerberos V5 Applications
@subsection rcp
@need 1000
@vfil
@end iftex
@need 2000
-@node ksu, , rcp, @value{PRODUCT} Applications
+@node ksu, , rcp, Kerberos V5 Applications
@subsection ksu
The @value{PRODUCT} @code{ksu} program replaces the standard UNIX su
The full set of options to @value{PRODUCT} @code{ksu} are discussed
in the Reference section of this manual. (@pxref{ksu Reference})
-@node @value{PRODUCT} Reference, Kerberos Glossary, @value{PRODUCT} Tutorial, Top
+@node Kerberos V5 Reference, Kerberos Glossary, Kerberos V5 Tutorial, Top
@chapter @value{PRODUCT} Reference
This section will include copies of the manual pages for the
* krdist Reference::
@end menu
-@node kinit Reference, klist Reference, @value{PRODUCT} Reference, @value{PRODUCT} Reference
+@node kinit Reference, klist Reference, Kerberos V5 Reference, Kerberos V5 Reference
@section kinit Reference
@iftex
Type @kbd{M-x manual-entry kinit} to read this manual page.
@end ifinfo
-@node klist Reference, kdestroy Reference, kinit Reference, @value{PRODUCT} Reference
+@node klist Reference, kdestroy Reference, kinit Reference, Kerberos V5 Reference
@section klist Reference
@iftex
Type @kbd{M-x manual-entry klist} to read this manual page.
@end ifinfo
-@node kdestroy Reference, kpasswd Reference, klist Reference, @value{PRODUCT} Reference
+@node kdestroy Reference, kpasswd Reference, klist Reference, Kerberos V5 Reference
@section kdestroy Reference
@iftex
Type @kbd{M-x manual-entry kdestroy} to read this manual page.
@end ifinfo
-@node kpasswd Reference, telnet Reference, kdestroy Reference, @value{PRODUCT} Reference
+@node kpasswd Reference, telnet Reference, kdestroy Reference, Kerberos V5 Reference
@section kpasswd Reference
@iftex
Type @kbd{M-x manual-entry kpasswd} to read this manual page.
@end ifinfo
-@node telnet Reference, rlogin Reference, kpasswd Reference, @value{PRODUCT} Reference
+@node telnet Reference, rlogin Reference, kpasswd Reference, Kerberos V5 Reference
@section telnet Reference
@iftex
Type @kbd{M-x manual-entry telnet} to read this manual page.
@end ifinfo
-@node rlogin Reference, FTP Reference, telnet Reference, @value{PRODUCT} Reference
+@node rlogin Reference, FTP Reference, telnet Reference, Kerberos V5 Reference
@section rlogin Reference
@iftex
Type @kbd{M-x manual-entry rlogin} to read this manual page.
@end ifinfo
-@node FTP Reference, rsh Reference, rlogin Reference, @value{PRODUCT} Reference
+@node FTP Reference, rsh Reference, rlogin Reference, Kerberos V5 Reference
@section FTP Reference
@iftex
Type @kbd{M-x manual-entry FTP} to read this manual page.
@end ifinfo
-@node rsh Reference, rcp Reference, FTP Reference, @value{PRODUCT} Reference
+@node rsh Reference, rcp Reference, FTP Reference, Kerberos V5 Reference
@section rsh Reference
@iftex
Type @kbd{M-x manual-entry rsh} to read this manual page.
@end ifinfo
-@node rcp Reference, ksu Reference, rsh Reference, @value{PRODUCT} Reference
+@node rcp Reference, ksu Reference, rsh Reference, Kerberos V5 Reference
@section rcp Reference
@iftex
Type @kbd{M-x manual-entry rcp} to read this manual page.
@end ifinfo
-@node ksu Reference, krdist Reference, rcp Reference, @value{PRODUCT} Reference
+@node ksu Reference, krdist Reference, rcp Reference, Kerberos V5 Reference
@section ksu Reference
@iftex
Type @kbd{M-x manual-entry ksu} to read this manual page.
@end ifinfo
-@node krdist Reference, , ksu Reference, @value{PRODUCT} Reference
+@node krdist Reference, , ksu Reference, Kerberos V5 Reference
@section krdist Reference
@iftex
Type @kbd{M-x manual-entry krdist} to read this manual page.
@end ifinfo
-@node Kerberos Glossary, , @value{PRODUCT} Reference, Top
+@node Kerberos Glossary, , Kerberos V5 Reference, Top
@appendix Kerberos Glossary
@include glossary.texinfo
projects / krb5.git / commitdiff