[OpenAFS-devel] tools and additional autoconf options...

[Neulinger, Nathan]

> > perhaps... but what is the consensus? That we would rather 
> not have any
> > other tools built with openafs - i.e. keep them all 
> independent? Or that we
> > should make it as easy as possible for new sites to do it 
> one of the ways
> > that we suggest?
> 
> If they're tools that we're going to end up needing to keep up with
> patches on and will get behind, it's almost certainly smarter to not
> distribute our own version. If AFS support patches can be done in a
> non-intrusive way they should be contributed upstream. If they can't,
> distributing them in anything more than a "this might work for you"
> fashion will probably make people hate us, both the people we give the
> patches to and the people whose software is being patched.

The patches are optional, the tools aren't. The current patch to krb5 adds a
bunch of things that are useful for sites that are installing krb5 w/ afs,
such as:

	* run aklog automatically
	* run aklog after getting tokens for ftpd
	* get a pag on telnetd (I think it does this already in a limited
fashion)
	* fix several krb5 bugs that they are continually ignoring

> > If nothing else, let's at least get it as a module on 
> openafs.org cvs so
> > that we can have a canonical location for the tools and source.
> 
> If it's not openafs-specific, why openafs.org and not central.org?
> Put otherwise, why should people who use IBM AFS need to care 
> about us?

Because openafs.org is the logical place people will look when "doing it
some way other than what IBM says". 

Perhaps central.org would be more appropriate, but most people don't have a
clue that central.org even exists, let alone what it's for, etc. 

I personally don't think openafs.org needs to be JUST for OpenAFS. I think
it is a much more logical repository for people to look to for tools,
especially when they are planning on using those tools with openafs and not
transarc/ibm afs.

Another option would be to have central.org be the grand repository of
pointers to all-that-is-afs-related, but actually keep the tools on
openafs.org.

Anything is an improvement over what we have now.

Since my impression is that we want people to be using krb5 when they deploy
afs, we should make it as easy as possible for them to do so. To me, the
easiest way to do that is to provide the auxilliary tools to be built as
part of openafs. If they can be provided externally (example - binutils
contains gdb, but gbd is also an external product - or maybe it's vice
versa) - that's great too. Distribute the extracted version via central.org.


I'd like to be able to say:

---
If you are going to use openafs with kerberos, build openafs with the
--with-krb5 option (have it find it automatically if it can, otherwise take
provided path), and follow the extra instructions in krb5/README.Kerberos
and krb5/README.MIT or krb5/README.Heimdahl for further details. 
---

Then go ahead and install aklog into bin, asetkey etc into sbin/etc, and go
forward. 

-- Nathan