[OpenAFS] Debian setup problems - remote pioctl failed
Matt Weatherford
mbw@u.washington.edu
Thu, 23 Oct 2003 11:25:57 -0700
Hello,
I apologize for the multiple posting recently, Im still stuck,
and hope someone can give me the missing piece I need to continue
my afs installation efforts on debian.
Ive been searching the archives and whatnot and have not found any
resolution to this pioctl issue. If theres somewhere Ive neglected
to look, please indicate.
Where I am getting hung up, at the moment, is on the aklog command:
dali:/usr/local/etc/openafs# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: root/admin@REALM.CSDE.WASHINGTON.EDU
Valid starting Expires Service principal
10/23/03 11:01:21 10/23/03 21:01:21
krbtgt/REALM.CSDE.WASHINGTON.EDU@REALM.CSDE.WASHINGTON.EDU
renew until 10/23/03 21:02:01
10/23/03 11:01:23 10/23/03 21:01:21
afs/csde.washington.edu@REALM.CSDE.WASHINGTON.EDU
renew until 10/23/03 21:02:01
Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached
/* ** my Kerb tickets look good ** */
dali:/usr/local/etc/openafs# aklog -d
Authenticating to cell csde.washington.edu (server
dali.csde.washington.edu).
We've deduced that we need to authenticate to realm
REALM.CSDE.WASHINGTON.EDU.
Getting tickets: afs/csde.washington.edu@REALM.CSDE.WASHINGTON.EDU
Warning: Remote pioctl to dali.csde.washington.edu has failed
(err=1073786320)...
Warning: Remote pioctl to dali.csde.washington.edu has failed
(err=1073786320)...
Warning: Remote pioctl to dali.csde.washington.edu has failed
(err=1073786320)...
Ive got my kerberos tickets, and Im running the 524 daemon on the
remote KDC....
From running STRACE on the "aklog" command, it looks like the
aklog command is trying to connect to the local machine,
(not the 127.0.0.1 address, but its "real" ip address) on port
7009... the "remote cache manager" service, according to the
/etc/services file....
Is aklog trying to contact some local service that I dont have
running yet? If so, how do I get this service to start up?
I am running all the AFS stuff, here is my ps output:
root 1092 1 0 09:47 ? 00:00:00 [kjournald]
root 1563 1 0 10:48 ? 00:00:00 /usr/sbin/bosserver
root 1569 1563 0 10:48 ? 00:00:00 /usr/lib/openafs/ptserver
root 1571 1563 0 10:48 ? 00:00:00 usr/lib/openafs/vlserver
root 1573 1563 0 10:48 ? 00:00:00 usr/lib/openafs/fileserver
root 1574 1563 0 10:48 ? 00:00:00 /usr/lib/openafs/volserver
root 1575 1573 0 10:48 ? 00:00:00 /usr/lib/openafs/fileserver
root 1576 1575 0 10:48 ? 00:00:00 /usr/lib/openafs/fileserver
root 1577 1575 0 10:48 ? 00:00:00 /usr/lib/openafs/fileserver
root 1578 1575 0 10:48 ? 00:00:00 /usr/lib/openafs/fileserver
root 1579 1575 0 10:48 ? 00:00:00 /usr/lib/openafs/fileserver
root 1580 1575 0 10:48 ? 00:00:00 /usr/lib/openafs/fileserver
root 1581 1575 0 10:48 ? 00:00:00 /usr/lib/openafs/fileserver
root 1582 1575 0 10:48 ? 00:00:00 /usr/lib/openafs/fileserver
root 1583 1575 0 10:48 ? 00:00:00 /usr/lib/openafs/fileserver
root 1584 1575 0 10:48 ? 00:00:00 /usr/lib/openafs/fileserver
root 1585 1575 0 10:48 ? 00:00:00 /usr/lib/openafs/fileserver
root 1586 1575 0 10:48 ? 00:00:00 /usr/lib/openafs/fileserver
root 1587 1575 0 10:48 ? 00:00:00 /usr/lib/openafs/fileserver
root 1588 1575 0 10:48 ? 00:00:00 /usr/lib/openafs/fileserver
root 1589 1575 0 10:48 ? 00:00:00 /usr/lib/openafs/fileserver
root 1590 1575 0 10:48 ? 00:00:00 /usr/lib/openafs/fileserver
root 1591 1575 0 10:48 ? 00:00:00 /usr/lib/openafs/fileserver
root 1592 1575 0 10:48 ? 00:00:00 /usr/lib/openafs/fileserver
root 1608 1 0 10:48 ? 00:00:00 [afs_rxlistener]
root 1609 1 0 10:48 ? 00:00:00 [afs_callback]
root 1610 1 0 10:48 ? 00:00:00 [afs_rxevent]
root 1612 1 0 10:48 ? 00:00:00 [afsd]
root 1616 1 0 10:48 ? 00:00:00 [afs_checkserver]
root 1617 1 0 10:48 ? 00:00:00 [afs_background]
root 1618 1 0 10:48 ? 00:00:00 [afs_background]
root 1620 1 0 10:48 ? 00:00:00 [afs_background]
root 1622 1 0 10:48 ? 00:00:00 [afs_cachetrim]
root 1684 292 0 11:19 pts/0 00:00:00 ps -ef
dali:/usr/local/etc/openafs# apt-show-versions | grep openafs
openafs-fileserver/testing uptodate 1.2.9-2
openafs-dbserver/testing uptodate 1.2.9-2
openafs-client/testing uptodate 1.2.9-2
openafs-krb5/testing uptodate 1.3-10
openafs-modules-source/testing uptodate 1.2.9-2
Marcus Watts wrote:
> Matt Weatherford <mbw@u.washington.edu> writes:
>
>>Message-ID: <3F96EF21.4040806@u.washington.edu>
>>From: Matt Weatherford <mbw@u.washington.edu>
>>User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20030925
>>Cc: openafs-info@openafs.org
>>References: <3F945C2F.9080102@u.washington.edu> <tsl1xt7h5sv.fsf@mit.edu>
>>
>>
>>Folks,
>>
>>Im having lots of trouble getting the setup under debian to work
>>... Im getting bound up in afs-newcell (protection database exists
>>errors) or in afs-rootvol (fs:'/afs': Connection timed out, Failed: 256)
>
> ...
>
> You might want to use "script" to save output from running several
> of these and report this as a bug to the debian folks. They
> can't fix things if they don't know that they're broken.
> My guess is that Sam Hartman will be very interested in your problem.
>
> As a completely separate path, you could also investigate setting
> things up without the handy scripts. It's a bit more work, but
> it does expose you to the various pieces much more closely.
> Here's my notes for
> /afs/umich.edu/user/m/d/mdw/wp/uniq.2y
> this includes debian specific details so might be easy to follow. On
> the other hand, the bits aren't necessarily well explained and might be
> out of date or otherwise quirky, so it may be hard to follow. One of
> the pieces here that may be hardest to follow is running "pt_util" --
> that's a handy trick borrowed from the afs-newcell script. pt_util has
> a really tricky syntax and confusing messages.
>
> Yet another thing to consider -- the afs-rootvol script probably
> requires that it be run on an afs client that has your cell available,
> and may not be smart enough to ensure that this is so on its own.
> You might be trying to run this on a db server where you (quite
> correctly) don't expect to run a cache manager. An easy fix therefore
> would be to bring up the cache manager before running that piece.
> Of course, if you don't have a root volume this may be hard.
> Looks like there's a "prerequisites" notice that says all this.
> One way to work around
> the need to have a running cache manager is to do a vos restore. Of
> course that presents a chicken and the egg problem in that you
> would need a suitable "vos dump" file from which to restore.
>
> A slightly more clever "afs-rootvol" script could either contain
> a suitable generic "root vol" vos dump, or perhaps a perl script or
> C program that generates a suitably customized vos dump.
> This would completely eliminate the need to run a cache manager
> to bring up your cell.
>
> -Marcus
--
Matt Weatherford
Unix Administration
Center for Studies in Demography and Ecology
218H Raitt Hall, Box 353412
University of Washington
Seattle, WA, USA, 98195 206-685-5346
http://www.csde.washington.edu