Thanks to Faheem Mitha for the report. Since I recently posted on a
related issue on openafs-info, it may be useful to point out what
I did differently from Faheem.
* /etc/hosts: no difference, I also have the local host's FQDN first,
the unqualified name second.
* AFSDB: I added a record to my DNS before running afs-newcell. This
may be why I didn't run into the "can't find cell '<default>'" issue.
It would be nice to mention AFSDB records in the setup instructions,
but I don't think they should be an absolute requirement for
afs-newcell to work.
* my new cell name (test.astro.su.se) didn't match my Kerberos realm
name (ASTRO.SU.SE). Apart from the insufficiently documented need to
echo ASTRO.SU.SE > /etc/openafs/server/krb.conf
this doesn't seem to invalidate anything in afs-newcell, which is nice.
There is still a problem with that "bos addhost", though:
# cat /etc/openafs/server/CellServDB
>test.astro.su.se
# bos addhost hephaistos hephaistos -localauth
# cat /etc/openafs/server/CellServDB
>test.astro.su.se #Cell name
[130.237.166.101] #hephaistos.astro.su.se
130.237.166.101 #hephaistos
The brackets around the IP address caused my server to lose the
election, so "vos create" later on in afs-newcell would fail.
Hand-editing /etc/openafs/server/CellServDB solved the problem,
as it did for Faheem.
I wonder if using
server=`hostname -f`
in afs-newcell instead of
server=`hostname`
would help.
About Faheem's question
"Why isn't this faheem/admin? What is the difference?"
it seems to me that point 4) of the requirements list is explicit
enough: the principal will have administrative privileges. At most
one may need to add "in the AFS cell", making it clear that the AFS
administrators need not be Kerberos administrators.
(faheem/admin would have worked just as well; the choice is strictly a
matter of local policy.)
About point 5) of the requirements, I think one should add a reminder to
turn off AFS_DYNROOT in /etc/openafs/afs.conf.client while setting up
the new cell. This should be repeated in the prerequisites for the
afs-rootvol script. Alternatively, maybe one could make afs-newcell
create root.cell as well as root.afs, and in the dynroot case one would
temporarily mount root.afs under root.cell in order to populate it. (I
haven't tested this, but I don't see why it couldn't work.)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
