sized types and more krb lib lossage...

[John Hawkinson]

(this is against the arla-0.1 snapshot, incidently).

include/kafs.h needs sized types, so atypes.h should be included,
otherwise fs.c doesn't build on systems that don't get them from
somewhere else (i.e. not find bind, from kth-krb, etc., etc.).  (Patch
not included since I'm not sure if you'd like to include atypes.h as
part of kafs.h or as part of fs.c and vos.c; not clear given the
confusing example in rxkad/).

If not using kth-krb, then fs and vos will not build, as they require
-lkafs (for k_pioctl and k_hasafs). I'm not sure what to say
here...perhaps the answer is that kth-krb4 is required, but this seems
kind of inconvenient. Other choices are to kill those functions
entirely, or produce a seperate libkafs for the non-kth kerberos
distributions.

Thoughts?

Other incidentals:

	1.	arlad should probably use getopt(), but you knew that.
	2.	On the Solaris 2.5.1 machine where I built arlad,
		arlad -t seems to work quite well with ThisCell set to
		stacken.kth.se, or sipb.mit.edu, but fails on athena.mit.edu:

read_conffile: /afs/sipb.mit.edu/project/arla/etc/arla.conf
Arlad booting sequence:
initports
conn_init numconns = 100
cellcache
volcache numvols = 100
rx
credcache numcreds = 100
fcache low_vnodes = 3000, high_vnodes = 4000
low_bytes = 15000000, high_bytes = 20000000
cmcb
 
Getting root...
volcache: VL_GetEntryByName(root.afs) failed: 19270408
Cannot find root-volumegetroot failed: 19

	I suppose this might be a version skew thing (?):

[portnoy!jhawk] /usr/vice/etc> rxdebug hot.stacken.kth.se 7003 -version
Trying 130.237.234.43 (port 7003):
AFS version: Base configuration afs3.4 5.13
[portnoy!jhawk] /usr/vice/etc> rxdebug prill.mit.edu 7003 -version
Trying 18.70.0.6 (port 7003):
AFS version: Base configuration afs3.4 5.28

[portnoy!jhawk] ~afsdev/src> egrep '5.13|5.28' 3.4*/src/CML/state
3.4a.patches.5/src/CML/state:C afs3.4 5.28

	Damned if I know what version 5.13 was, since in our source tree 4.00 was
what we call "3.4a.patches.2" and 5.16 is "3.4a.patches.3". The sipb cell is
still running 3.3a.

	Nope, zone.mit.edu (private testing cell) works fine, also
at 5.28.

With arladeb=-1, debugging output isn't appreciably better:

Getting root...
running cleaner: 0 (3000-4000) files, 0 (15000000-20000000) bytes
cleaner done: 0 (3000-4000) files, 0 (15000000-20000000) bytes
volcache: VL_GetEntryByName(root.afs) failed: 19270408
Cannot find root-volumegetroot failed: 19

Mucking about under gdb:

(gdb) where
#0  VL_GetEntryByName (connection=0x1efc80, volumename=0x59eb8 "root.afs", 
    entry=0xa95d0) at vldb.cs.c:207
#1  0x29c90 in add_entry (volname=0x59eb8 "root.afs", cell=0, ce=0xbd310)
    at /afs/sipb/project/arla/src/arla-0.1/arlad/volcache.c:239

which looks fine.  tcpdump shows:

23:41:51.347812 portnoy.MIT.EDU.4711 > PRILL.MIT.EDU.afs3-vlserver: rx data seq 1 <client-init>,<last-pckt> vldb op#232119202 (48) (DF) (ttl 255, id 26260)
23:41:51.349403 PRILL.MIT.EDU.afs3-vlserver > portnoy.MIT.EDU.4711: rx challenge seq 0 (44) (ttl 60, id 57319)
23:41:51.352933 portnoy.MIT.EDU.4711 > HYDRA.MIT.EDU.afs3-fileserver: rx ack seq 1 (51) (DF) (ttl 255, id 27927)
23:41:51.354643 portnoy.MIT.EDU.4711 > PRILL.MIT.EDU.afs3-vlserver: rx response seq 0 <client-init> (132) (DF) (ttl 255, id 26261)
23:41:51.391042 portnoy.MIT.EDU.4711 > HYDRA.MIT.EDU.afs3-fileserver: rx data seq 1 <last-pckt> (28) (DF) (ttl 255, id 27928)
23:41:51.897203 HYDRA.MIT.EDU.afs3-fileserver > portnoy.MIT.EDU.4711: rx ack seq 0 <client-init> (61) (ttl 59, id 63116)
23:41:52.351991 PRILL.MIT.EDU.afs3-vlserver > portnoy.MIT.EDU.4711: rx abort seq 0 (32) (ttl 60, id 57326)

Whereas on the zone.mit.edu cell:

23:43:10.178256 portnoy.MIT.EDU.4711 > CASIO.MIT.EDU.afs3-vlserver: rx data seq 1 <client-init>,<last-pckt> vldb get-entry-by-name "root.afs" (44) (DF) (ttl 255, id 37992)
23:43:10.186161 CASIO.MIT.EDU.afs3-vlserver > portnoy.MIT.EDU.4711: rx data seq 1 <last-pckt> (412) (DF) (ttl 253, id 38718)

Which certainly looks more right.

I'm not really sure the right way to debug rxdef/vldb.cs.c,
so I'll cop out now and ask for suggestions :-)

thanks.

--jhawk