[OpenAFS] Re:OpenAFS for x86 solaris 8 (new issues!)

Marcus Watts mdw@umich.edu
Fri, 05 Jul 2002 02:56:12 -0400


Alan Meadows <alan@sunwave.com> writes:
> Message-Id: <5.0.2.1.2.20020704172754.025d2c60@mail.protgp.com>
> To: Derrick J Brashear <shadow@dementia.org>
> From: Alan Meadows <alan@sunwave.com>
> Cc: openafs-info@openafs.org
> In-Reply-To: <Pine.LNX.3.96L.1020704184024.7183A-100000@scully.trafford.
>  dementia.org>
> Subject: [OpenAFS] Re:OpenAFS for x86 solaris 8 (new issues!)
> Sender: openafs-info-admin@openafs.org
> Errors-To: openafs-info-admin@openafs.org
> Date: Thu, 04 Jul 2002 17:31:07 -0700
> 
> 
> >
> >pts examine admin
> 
> 
> # ./pts examine admin
> libprot: a pioctl failed Could not get afs tokens, running unauthenticated.
> Name: admin, id: 101, owner: system:administrators, creator: anonymous,
>    membership: 0, flags: S----, group quota: 20.
> # cat /etc/passwd | grep admin
> admin:x:101:1::/home/admin:/bin/sh
> 
> also:
> 
> # ./kas examine admin -admin_user admin
> Administrator's (admin) Password:
> kas:examine: getting Authentication token for admin
> 
> User data for admin
>    key (3) cksum is 2798521835, last cpw: Thu Jul  4 01:48:30 2002
>    password will never expire.
>    An unlimited number of unsuccessful authentications is permitted.
>    entry never expires.  Max ticket lifetime 25.00 hours.
>    last mod on Tue Jul  2 12:58:15 2002 by <none>
>    permit password reuse
> 
> 
> >you say:
> > > I have made sure that the AFS "admin" user has the same UID (101) as the
> > > user "admin" in the local password file.  According to the documentation,
> > > AFS is most happy when users exist with the same UIDs in both places.
> >
> >which implies it does exist.
> 
> 
> How do I get AFS to realize that. :-)
> 
> As I said in my previous e-mail, I do not have any client stuff configured 
> on this machine.  Is it possible I need to do some client setup in order to 
> use klog?  (i.e. creating /afs, etc).
> 
> 
> Alan Meadows
> alan@sunwave.com
> 
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
> 

Your error is
        ec KANOENT, "user doesn't exist"
Actually, KANOENT is just another number.  There are 23 places in the
AFS code where it can be returned.  All of the ones I found are for the
same error, -- FindBlock called, and returns 0 for both its result, and
the value of the file postion for the name passed in.  Most of these
are for the 'user', but a few are for the service.  So perhaps the interesting
question is what does a "./kas examine afs" say?  Also, what does "list"
(or "ls"?) list?

I would say, based on this, I don't expect any cache manager stuff,
like creating /afs or running afsd, to make any difference.

The two client side issues that you should need to run klog/kas/pts
are:
	(1) cache manager loaded (but not "running") in kernel.
	(2) valid CellServDB file.
The server side stuff (at least for transarc) looks in
/usr/afs/etc/CellServDB and /usr/afs/etc/ThisCell.
The client side looks in /usr/vice/etc/CellServDB and /usr/vice/etc/ThisCell.
Nothing looks under /usr/afsws/ - I've seen this mentioned on the list, and
I've seen stuff distributed this way in AFS, but I don't know of any
code that *look* for stuff here on the local disk.
kaserver & ptserver are server side, so they look under /usr/afs .
pts and klog are client side, so they're looking in /usr/vice .
If the CellServDB that's here is different, you could get odd results.

I don't know how useful the following will be, but here are some of the
tools I'd use to sort out what's happening:
(1) gdb
	gdb	--attach to existing kaserver process.  (uh, you do
		have one AFS database server right?) (You haven't
		stripped your binaries have you?  If you have, you
		might want to install the non-stripped version that
		will be under obj/kauth/kaserver in your build tree.)
	set a break point on FindBlock in kaserver.
	Run the "klog".  In kaserver, do "where" "continue"
		quickly as many times as needed (you'll want to
		do the continue within 5 seconds to avoid
		breaking rx from klog).  Identify which call
		to FindBlock failed.  Try to run it again,
		and when you get to the same point,
		print out arguments to function & examine
		what they point to.)
	This will probably be the best way to find out what's happening,
	but will require some patience and much expertise.
(2) truss -- try attaching this to existing kaserver, & also try running
	this from scratch on klog.  This will show you system calls,
	file names being opened (such as which files are being used
	to get configuration information...), and give you a vague
	idea about when network traffic is happening.
(3) tcpdump -- is the network traffic from your client going to the
	server machines you expect, or elsewhere?  [but you'd need
	to try klog from a different machine so that you can force the
	traffic onto ethernet where you can sniff it.]  Some versions
	of tcpdump know about rx, but this won't be too useful with
	kaserver since everything is going to be encrypted.

A lower-tech way to do (1) gdb would be to insert some strategic
printf's into kauth, rebuild kaserver, & try running that.  You may
also want to build it with "-g" if it's not built that already, you
know gdb, but don't know how to deal with machine level debugging.

More generally, I don't know why Alan is having all this trouble, or
how common such problems are, but perhaps this means there's room for
improving the install process (?), or perhaps it would be useful to
have some sort of uber sanity program that you'd run on your db servers
and which would look for common install problems and diagnose them.
"Contents of /usr/afs/etc/KeyFile do not match contents of ka
database.  To fix this...".  Some versions of kaserver can be made to
"audit" events.  I don't know that this works for openafs on solaris,
but that might be another avenue to make work and document.  Of
course, I don't know why I'm suggesting any of this, it's not like
I don't have enough interesting things to do already...

				-Marcus Watts
				UM ITCS Umich Systems Group