Package: openafs-dbserver
Version: 1.3.81-3sarge1
Severity: normal

doing a fairly standard installation of an openafs server, i got
tripped up on afs-newcell.

here's an example of the run which failed:

korat:~/openafs# afs-newcell 
                            Prerequisites

In order to set up a new AFS cell, you must meet the following:

1) You need a working Kerberos realm with Kerberos4 support.  You
   should install Heimdal with Kth-kerberos compatibility or MIT
   Kerberos5.

2) You need to create the single-DES AFS key and load it into
   /etc/openafs/server/KeyFile.  If your cell's name is the same as
   your Kerberos realm then create a principal called afs.  Otherwise,
   create a principal called afs/cellname in your realm.  The cell
   name should be all lower case, unlike Kerberos realms which are all
   upper case.  You can use asetkey from the openafs-krb5 package, or
   if you used AFS3 salt to create the key, the bos addkey command.

3) This machine should have a filesystem mounted on /vicepa.  If you
   do not have a free partition, then create a large file by using dd
   to extract bytes from /dev/zero.  Create a filesystem on this file
   and mount it using -oloop.  

4) You will need an administrative principal created in a Kerberos
realm.  This principal will be added to susers and
system:administrators and thus will be able to run administrative
commands.  Generally the user is a root instance of some administravie
user.  For example if jruser is an administrator then it would be
reasonable to create jruser/root and specify jruser/root as the user
to be added in this script.

5) The AFS client must not be running on this workstation.  It will be
at the end of this script.

Do you meet these requirements? [y/n] y
If the fileserver is not running, this may hang for 30 seconds.
/etc/init.d/openafs-fileserver stop
Stopping AFS Server: bosserver.
What administrative principal should be used? dkg/admin
echo \>example.org >/etc/openafs/server/CellServDB
/etc/init.d/openafs-fileserver start
Starting AFS Server: bosserver.
bos addhost korat korat -localauth ||true
bos adduser korat dkg.admin -localauth
pt_util: /var/lib/openafs/db/prdb.DB0: Bad UBIK_MAGIC. Is 0 should be 354545
Ubik Version is: 2.0
Error while creating system:administrators: Entry for id already exists
pt_util: Ubik Version number changed during execution.
Old Version = 2.0, new version = 33554432.0
bos create korat ptserver simple /usr/lib/openafs/ptserver -localauth
bos create korat vlserver simple /usr/lib/openafs/vlserver -localauth
bos create korat fs fs -cmd /usr/lib/openafs/fileserver -cmd 
/usr/lib/openafs/volserver -cmd /usr/lib/openafs/salvager -localauth
Waiting for database elections: done.
vos create korat a root.afs -localauth

Could not get an Id for volume root.afs
   u: no quorum elected
u: no quorum elected
Error in vos create command.
u: no quorum elected
Failed: 65280
bos shutdown korat -localauth 
bos delete korat fs -localauth 
bos delete korat vlserver -localauth
bos delete korat ptserver -localauth
rm /var/lib/openafs/db/prdb* 
bos removeuser korat dkg.admin -localauth
korat:~/openafs#


Here's what i found:

/etc/openafs/server/CellServDB looked like this:

korat:~/openafs# cat /etc/openafs/server/CellServDB
>example.org    #Cell name
[192.168.23.7]  #korat.example.org
192.168.23.7    #korat
korat:~/openafs#

i couldn't find any documentation about what the brackets meant, but i
assumed it was bad that the same server was listed twice while trying
to get a quorum.  i had used the FQDN when configuring openafs-client
with debconf, but hostname just had the name of the machine itself,
not fqdn:

[EMAIL PROTECTED] tmp]$ grep -A4 openafs-client/cell-info 
/var/cache/debconf/config.dat
Name: openafs-client/cell-info
Template: openafs-client/cell-info
Value: korat.example.org
Owners: openafs-client
Flags: seen

[EMAIL PROTECTED] tmp]$ hostname
korat
[EMAIL PROTECTED] tmp]$ hostname --fqdn
korat.example.org
[EMAIL PROTECTED] tmp]$ 


i resolved the issue by setting the hostname to explicitly include the
fqdn and then re-running afs-newcell:

korat:~/openafs# hostname korat.example.org
korat:~/openafs# hostname
korat.example.org
korat:~/openafs# hostname --fqdn
korat.example.org
korat:~/openafs# afs-newcell 
                            Prerequisites

In order to set up a new AFS cell, you must meet the following:

1) You need a working Kerberos realm with Kerberos4 support.  You
   should install Heimdal with Kth-kerberos compatibility or MIT
   Kerberos5.

2) You need to create the single-DES AFS key and load it into
   /etc/openafs/server/KeyFile.  If your cell's name is the same as
   your Kerberos realm then create a principal called afs.  Otherwise,
   create a principal called afs/cellname in your realm.  The cell
   name should be all lower case, unlike Kerberos realms which are all
   upper case.  You can use asetkey from the openafs-krb5 package, or
   if you used AFS3 salt to create the key, the bos addkey command.

3) This machine should have a filesystem mounted on /vicepa.  If you
   do not have a free partition, then create a large file by using dd
   to extract bytes from /dev/zero.  Create a filesystem on this file
   and mount it using -oloop.  

4) You will need an administrative principal created in a Kerberos
realm.  This principal will be added to susers and
system:administrators and thus will be able to run administrative
commands.  Generally the user is a root instance of some administravie
user.  For example if jruser is an administrator then it would be
reasonable to create jruser/root and specify jruser/root as the user
to be added in this script.

5) The AFS client must not be running on this workstation.  It will be
at the end of this script.

Do you meet these requirements? [y/n] y
If the fileserver is not running, this may hang for 30 seconds.
/etc/init.d/openafs-fileserver stop
Stopping AFS Server: bosserver.
What administrative principal should be used? dkg/admin
echo \>example.org >/etc/openafs/server/CellServDB
/etc/init.d/openafs-fileserver start
Starting AFS Server: bosserver.
bos addhost korat.example.org korat.example.org -localauth ||true
bos adduser korat.example.org dkg.admin -localauth
pt_util: /var/lib/openafs/db/prdb.DB0: Bad UBIK_MAGIC. Is 0 should be 354545
Ubik Version is: 2.0
Error while creating system:administrators: Entry for id already exists
pt_util: Ubik Version number changed during execution.
Old Version = 2.0, new version = 33554432.0
bos create korat.example.org ptserver simple /usr/lib/openafs/ptserver 
-localauth
bos create korat.example.org vlserver simple /usr/lib/openafs/vlserver 
-localauth
bos create korat.example.org fs fs -cmd /usr/lib/openafs/fileserver -cmd 
/usr/lib/openafs/volserver -cmd /usr/lib/openafs/salvager -localauth
Waiting for database elections: done.
vos create korat.example.org a root.afs -localauth
Volume 536870912 created on partition /vicepa of korat.example.org
echo example.org >/etc/openafs/ThisCell
/etc/init.d/openafs-client force-start
Starting AFS services: afsd: All AFS daemons started.
 afsd.
Now, get tokens as dkg.admin in the example.org cell.  Then, run
afs-rootvol.
korat:~/openafs# 


after doing this, the server's CellServDB looked a lot better:

korat:~/openafs# cat /etc/openafs/server/CellServDB
>example.org    #Cell name
192.168.23.7    #korat.example.org
korat:~/openafs# hostname korat
korat:~/openafs# 


and everything else worked ok without the hostname being explicitly
set like that.

It seems like an attempt to get a quorum between one machine and
itself is going to inherently fail.  But i don't understand OpenAFS
well enough to be sure that this is the case.

Is there any legitimate reason that someone could want two entries in
/etc/openafs/server/ThisCellDB with the *same* IP address?  if not,
why would bos addhost allow such a configuration to be written?

i'd say that afs-newcell should use `hostname --fqdn` instead of
`hostname`, but that might just cause the same problem for other folks
who were expecting everything to be bare hostnames.

i'm not entirely sure what an appropriate solution to this would be,
but i'd like to help make openafs easier to set up for people.


-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages openafs-dbserver depends on:
ii  debconf                   1.4.30.13      Debian configuration management sy
ii  libc6                     2.3.2.ds1-22   GNU C Library: Shared libraries an
ii  openafs-client            1.3.81-3sarge1 The AFS distributed filesystem- cl
ii  openafs-fileserver        1.3.81-3sarge1 The AFS distributed filesystem- fi
ii  perl [perl5]              5.8.4-8        Larry Wall's Practical Extraction 

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to