[2128] in Kerberos-V5-bugs
Re: krb5b6 with --with-krb4= login will not compile.
daemon@ATHENA.MIT.EDU (Sam Hartman)
Fri Aug 2 21:39:47 1996
To: "Randall S. Winchester" <rsw@Glue.umd.edu>
Cc: Sam Hartman <hartmans@MIT.EDU>, krb5-bugs@MIT.EDU
From: Sam Hartman <hartmans@MIT.EDU>
Date: 02 Aug 1996 21:39:26 -0400
In-Reply-To: "Randall S. Winchester"'s message of Thu, 1 Aug 1996 14:27:32 -0400 (EDT)
>>>>> ""Randall" == "Randall S Winchester" <rsw@Glue.umd.edu> writes:
"Randall> First, thanks for the answer.
"Randall> On 1 Aug 1996, Sam Hartman wrote:
"Randall> : >>>>> ""Randall" == "Randall S Winchester"
"Randall> <rsw@Glue.umd.edu> writes: : : "Randall> On Solaris 2.5
"Randall> with the following configure line: : "Randall>
"Randall> ../src/configure --with-ccopts=-g : "Randall>
"Randall> --with-krb4=/usr/local/athena \ --with-krb5-root=/etc :
"Randall> "Randall> --prefix=/usr/local/krb5 --with-kdb-db=db \ :
"Randall> "Randall> --with-kdb-dbopts="-I/usr/local/db/include :
"Randall> "Randall> -L/usr/local/db/lib" : : I would be very
"Randall> careful of using db for your Kerberos : database.
"Randall> OK, hum I thought there was a tread a while ago about
"Randall> locking and large database size problems. I seem to
"Randall> remember the gnu db or berkeley db's as being
"Randall> recommended. (I have 40k principles under AFS/KRB4)
The locking problems are gdbm, and there are some other
problems with dbm that I haven't run into, but that others claim
exist. Basically, the *db* packages don't have a very good history.
These problems are not unique to Kerberos, although Kerberos tend to
use dbm more heavily than most non-news applications. (In something
like Sendmail, all of the operations are reads or insets of
non-existing entries. In other words, db and dbm work fairly well so
long as you don't change an existing database.)
"Randall> Any pointer as to what the problems are? I did saw the
"Randall> digex.com posting today, and was surprised. We use the
"Randall> berkely db for a number of things here, and I had not
"Randall> noticed a problem.
In general, db tends to have pages of the database that
disappear. I have noticed the problem with a fairly small Kerberos
realm (~40 principals).
"Randall> : : : "Randall> A little looking around and I see
"Randall> libkrb4.a is not being : "Randall> built. Is there a
"Randall> work around/patch to one of the : "Randall>
"Randall> configure/configure.in/Makefile.in files? : : You are
"Randall> probably misunderstanding the purpose of an argument :
"Randall> to --with-krb4 option. It tells krb5 to use an
"Randall> installed version of : libkrb.a instead of building the
"Randall> one in the source tree. What were : you expecting this
"Randall> option to do?
"Randall> I did missunderstanding the option. The following then
"Randall> could be changed to be a little more clear.
"Randall> From ../doc/HOW_TO_BUILD: If you want Kerberos V4
"Randall> backwards compatibility, pass the
"Randall> "--with-krb4=/KRB4_DIRECTORY" option to configure. This
"Randall> requires that the V4 include files be available in
"Randall> /KRB4_DIRECTORY/include, and that the V4 Kerberos
"Randall> library be available in /KRB4_DIRECTORY/lib.
"Randall> After re-reading the doc/install.texi, along with your
"Randall> reply it is clear to me. Adding "It tells krb5 to use an
"Randall> installed version of libkrb.a instead of building the
"Randall> one in the source tree" would probably help others.
That comment in how_to_build is out of date. It predates the
inclusion of libkrb4.a in the krb5 distribution. I think most of
how_to_build is out of date, and we should probably consider removing
it in favor of install.texi. I will certainly either remove it or
update that section.
"Randall> One other note: I want my client binaries to go into
"Randall> /usr/local/krb5, which is a remote filesystem (AFS), but
"Randall> want the server binaries installed locally in
"Randall> /local/krb5. The docs refer to --prefix="foo" as
"Randall> controlling both. It seems to me that this would be a
"Randall> very common case. Is there a way to achieve this, or do
"Randall> I need to recompile twice?.
Hmm, what I would do is compile for your server locations,
install using make DESTDIR=<something> install, and then move the
client binaries into place. Basically, the client binaries don't
really care where they live (other than finding shared libraries,
which you want to be local for security reasons anyway), while the
servers sort of need to know. For example, rcp needs to find rcp on
the remote system, klogind nbeeds to find login.krb5, etc.
You could also have /local/krb5/bin be a symlink into AFS.
"Randall> Actually, It does look like if I copied the server
"Randall> binaries from /usr/local/krb5 to /local/krb5 and edited
"Randall> kdc.conf that this may work, but I have not tested this
"Randall> workaround out yet. Another thought for that upcoming
"Randall> release...
Again, be careful of shared libs, login.krb5, etc.
"Randall> Thanks again, Randall
"Randall> : : "Randall> Thanks, Randall : : : :
