[OpenAFS] Currently correct info for Debian sarge OpenAFS install?

[Jeffrey Hutzelman]

On Monday, May 02, 2005 07:30:50 PM -0700 Russ Allbery <rra@stanford.edu> 
wrote:

> Eric Bennett <eric@umbralservices.com> writes:
>
>> I've been having a nightmare of a time trying to get openafs installed
>> under debian, I've gotten to the point where you create a volume (I
>> assume) with the command vos create (host) a root.afs -localauth and it
>> just hangs, I've tried stracing the filesserver process as well as the
>> bosserver process, it appears to be hanging on
>
>> [pid  7169] connect(3, {sa_family=AF_INET, sin_port=htons(2040),
>> sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ECONNREFUSED (Connection
>> refused)
>
> Well, this particular problem is because of /etc/hosts, as previously
> mentioned.  (That's the only reason why something would be connecting to
> 127.0.0.1.)

Actually, no.  Port 2040/tcp is the fssync interface, which is the 
communication channel between the fileserver, volserver, and other volume 
utilities running on the same machine.  It listens _only_ on 127.0.0.1, and 
connections via that address are perfectly normal.

The connection is being refused because the fileserver hasn't finished 
initializing yet.  This is also perfectly normal, for a time, but not 
indefinitely.  In this case, the reason the fileserver has not finished 
initializing is called out clearly in the logs -- it can't get a CPS for 
system:anyuser, because that entry doesn't yet exist in the PRDB (error 
267268 is PRNOENT, "User or group doesn't exist").

The reason for the PRNOENT is also called out clearly in the logs.  The 
ptserver was started with _no_ database, and because it is not running in 
noauth mode, it will not construct one from scratch.  This is somewhat 
expected; running the ptserver in noauth mode has significant security 
implications, and so it's desirable to avoid ever doing so.  The Debian 
scripts accomplish this by using pt_util to spin an initial PRDB from 
scratch before starting the ptserver for the first time.  Since these 
scripts were apparently not used in this case, there is no PRDB.


IMHO the simplest solution would be to use the afs-newcell script provided 
with the Debian packages to emit a new PRDB.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA