Skip Menu |

Download (untitled) / with headers
text/plain 8.2KiB
From bjaspan@MIT.EDU Wed Nov 13 15:46:08 1996
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU []) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id PAA04532 for <bugs@RT-11.MIT.EDU>; Wed, 13 Nov 1996 15:46:07 -0500
Received: from BEEBLEBROX.MIT.EDU by MIT.EDU with SMTP
id AA03749; Wed, 13 Nov 96 15:45:23 EST
Received: by beeblebrox.MIT.EDU (940816.SGI.8.6.9/4.7) id UAA28434; Wed, 13 Nov 1996 20:45:22 GMT
Message-Id: <199611132045.UAA28434@beeblebrox.MIT.EDU>
Date: Wed, 13 Nov 1996 20:45:22 GMT
From: bjaspan@MIT.EDU
Reply-To: bjaspan@MIT.EDU
To: krb5-bugs@MIT.EDU, krbdev@MIT.EDU
Subject: krb5.conf, kdc.conf, and --prefix
X-Send-Pr-Version: 3.99

Show quoted text
>Number: 185
>Category: krb5-misc
>Synopsis: krb5.conf, kdc.conf, and --prefix
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: krb5-unassigned
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Wed Nov 13 15:47:00 EST 1996
>Last-Modified: Fri Nov 15 17:19:03 EST 1996
>Originator: Barry Jaspan
Show quoted text
>Release: 1.0-development

System: IRIX beeblebrox 5.3 11091812 IP22 mips

Show quoted text

There is a combination of problems in krb5 involving krb5.conf,
kdc.conf, and the compile-time --prefix setting that needs to fixed.
Although it ought to be done by 1.0, I do not think it will be; I'm
submitting this PR to ensure it gets done soon thereafter. (If
someone thinks this should be done by 1.0, say so. I note that items
1 and 2 go together, but that item 3 is largely separate and perhaps
the most important.)

The first problem is that the structure of kdc.conf is confused. Some
items are specified in the [realms] section that are not realm
specific and therefore should be elsewhere. Many (perhaps all)
relations in this category are for the admin system and are therefore
my fault; I did not understand the nature of kdc.conf at the time
(which is part of why this PR is necessary).

The second problem is that the existence of kdc.conf is itself
confusing to users and inefficient in the code. The krb5.conf syntax
is sufficient to specify all of the kdc.conf information in krb5.conf.
Unless someone points out a good reason why the files need to be
separate, they should be merged. This will have the advantage of
eliminating the "alternative profile" kludge in (several redundant
places in) the code and simplifing the maintainance of KDCs.

The third problem is that the value of --prefix specified during
configure is built into numerous programs in the distribution, making
the results of "make install" absolute-path specific. It forces
admins to know where they are going to install the tree before they
run configure and build and, if they either change their mind or
didn't know they had to make the decision, they have to run a clean
build again from scratch (just re-running configure and make isn't
sufficient because programs with --prefix hard-coded are not
automatically rebuilt).

Here is my proposal:

o kdc.conf is merged into krb5.conf so that only one file exists.

o The path for krb5.conf is hard-coded into the libraries. The
default value is /etc/krb5.conf. It can be overridden by the
configure option --krb5confpath, after which a full rebuild is
necessary. The documentation *strongly* discourages the use of this
option. /etc/krb5.conf is The One True Path.

o There are several programs that need to know where to find krb5 data
files or binaries: KDC and kadmind need the database et al; kpropd
needs the path for kdb5_util; klogind, kshd, and telnetd need the path
for login.krb5 (I think that's all of them). In beta 7, the paths for
these files are determined at compile time by --prefix. Instead,
krb5.conf will now contain an install-prefix relation. Programs will
combine the install-prefix with a default suffix to locate the file;
for example, klogind will look for "<install-prefix>/sbin/login.krb5",
and the KDC/kadmind will look for "<install-prefix>/krb5kdc/principal"
as the database name; of course, the full value can also be completely
overriden for some of these values (ie: dbname, acl_file, admin_keytab
for the kdc/kadmind) if the program happens to allow that. Note that
since install-prefix is specified in krb5.conf, there is no
requirement for these paths to be the same on every machine in the
realm, which is good: clients should look in /usr/local, but the KDC
should probably look in /var/krb5 or somesuch.

o The default value for install-prefix can be anything, /usr/local is
fine, and the configure option --installprefix overrides it. Also,
please suggest a better name than "installprefix".

o make install by default installs into $(buildtop)/install/{bin,...}.
Since the distribution is now path-independent, this installation
directory can be copied to anywhere, and the sysadmin does not need to
recompile from scratch whenever he wants to change the location of the
binaries. The configure option --installpath overrides this value in
case the sysadmin knows for sure where he wants the files to go, but
again, this only affects the path name given to the install program.


Show quoted text

Show quoted text

Show quoted text

From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: bjaspan@MIT.EDU
Cc: krb5-bugs@MIT.EDU, krbdev@MIT.EDU
Subject: Re: krb5-misc/185: krb5.conf, kdc.conf, and --prefix
Date: Fri, 15 Nov 1996 17:17:43 -0500

Date: 13 Nov 1996 19:33:14 -0500
From: Ken Raeburn <>

Some notes on your proposal:

Shared libraries would have to be found either by absolute pathname or
by system-wide or per-user configuration changes. System-wide changes
require root access to switch versions (e.g., for debugging or
comparison purposes). Per-user changes won't work for ksu, and are
probably Right Out for large sites anyways. Environment variable
changes (to find an alternate krb5.conf and things pointed to by it)
will be needed to change versions also.

You propose a number of new configure script options. Have you looked
at how to add them? Do you plan on maintaining a Kerberos-specific
version of autoconf forever?

If the pathname info (install-prefix, location of krb5.conf, whatever)
is coded into a library object file, changing it requires rebuilding
only those libraries, and anything they're linked into; random other
object files, even those using krb5.h, would not be affected.

If you do eliminate all dependencies on $(prefix) in the libraries and
application programs, you can use --prefix for the purposes you intend
--installprefix for, can't you?

Even if not, what's wrong with running "make install prefix=..." if
you really want the install done someplace else? I suspect that the
most commonly desired cases would be:
* installing into the final location
* building a package that can be installed later
And in the latter case, there's probably more work to be done, since
"directory tree" probably isn't usually the most convenient package
format. So a script or makefile target is probably the best solution,
in which case adding extra arguments to "make install" is no big deal.

Show quoted text
> o make install by default installs into $(buildtop)/install/{bin,...}.

I think "make install" should *install* the software (using
$(prefix)), not build a package that can be installed later, which is
what you're describing. A separate Makefile target name for such
packages would be fine. At the same time, we can set up targets for
packages in Debian, RedHat, BSD, setld, svr4 and other formats.

In fact, at Cygnus, we never use "make install" directly, we use a
gzipped-tar-file target (which uses "make install prefix=..."). We've
also worked with some of the other package formats before, so making
them work for v5 shouldn't be hard.

Show quoted text
> since install-prefix is specified in krb5.conf, there is no
> requirement for these paths to be the same on every machine in the
> realm, which is good: clients should look in /usr/local, but the KDC
> should probably look in /var/krb5 or somesuch.

Um. Actually, I think I'd want rlogind (say) always looking in
/usr/local (or whereever), regardless of whether I had set up a KDC on
that particular machine. The KDC, however, would look in /var/krb5,
or /s1/cygnus/kerbnet, or /usr/local/krb5. It may even vary between
machines, so a single krb5.conf wouldn't be correct site-wide. Which
complicates installation and maintenance.
Show quoted text