Faheem Mitha <[EMAIL PROTECTED]> writes:
> Package: openafs
> Severity: normal
> Hi,
> This reports follows the config session described in
> /usr/share/doc/openafs-*/configuration-transcript.txt.gz
I'll send a more detailed response later today or tomorrow, but I've now
read through this in detail and wanted to give you first impressions.
You've found what looks like one serious bug, which I'll fix, related to
setting up the server CellServDB. That fix will be in the next release; I
think I understand what the problem was.
Most of the rest of the comments are, I think, because there isn't an
overview and guide to accompany the transcript. I've spent some time this
morning writing one, and while it's not completely finished yet, here's
the first draft of the part on setting up a new cell. I think this would
have answered a lot of your questions. This too will be in the next
release.
Creating a New Cell
For documentation on adding a server to an existing cell, see below.
These instructions assume that you are using MIT Kerberos and the
openafs-krb5 package. If you are using Heimdal instead, some of the
steps will be slightly different (Heimdal can write the AFS KeyFile
directly, for example, so you don't have to use asetkey). The
afs-newcell and afs-rootvol scripts are the same, however.
/usr/share/doc/openafs-dbserver/configuration-transcript.txt.gz has a
transcript of the results of these directions, which you may want to
follow along with as you do this.
1. If you do not already have a Kerberos KDC configured, do so. You
can run the KDC on the same system as your OpenAFS db server,
although if you plan on using Kerberos for other things, you may
eventually want to use separate systems. If you do not have a
Kerberos realm set up already, you can do so in Debian with:
apt-get install krb5-admin-server
krb5_newrealm
This will install a KDC and kadmind server (the server that handles
password changes and account creations) on the local system. Please
be aware that the security of everything that uses Kerberos for
authentication, including AFS, depends on the security of the KDC.
The name of your Kerberos realm should, for various reasons, be in
all uppercase and be a domain name that you control, although
neither is technically required.
2. It is traditional (and recommended) in AFS (and for Kerberos) to
give administrators two separate Kerberos principals, one regular
principal to use for regular purposes and a separate admin principal
to use for privileged actions. This is similar to the distinction
between a regular user and the root user in Unix, except that
everyone can have their own separate root identity. Kerberos
recommends username/admin as the admin principal for username, and
this will work for AFS as well.
If you have not already created such an admin principal for yourself
in your Kerberos realm, do so now (using kadmin.local on your KDC,
unless you have a local method that you prefer). Also create a
regular (non-admin) principal for yourself if you have not already;
this is the identity that you'll use for regular operations, like
storing files or reading mail.
If the KDC is not on the same system that the OpenAFS db server will
be on, you will also need to give your admin principal the rights to
download the afs keytab in /etc/krb5kdc/kadm5.acl by adding a lines
like:
username/[EMAIL PROTECTED] *
where REALM is your Kerberos realm and username/admin is the admin
principal that you created. That line gives you full admin access
to the Kerberos v5 realm. You can be more restrictive if you want;
see the kadmind man page for the syntax.
3. Install the OpenAFS db server package on an appropriate system with:
apt-get install openafs-dbserver openafs-krb5
The openafs-krb5 package will be used to create the AFS KeyFile. As
part of this installation, you will need to configure openafs-client
with the cell you are creating as the local cell name and the server
on which you're working as the db server. This name is technically
arbitrary but should, for various reasons, be a valid domain name
that you control; unlike Kerberos realms, it should be in all
lowercase. Don't start the client; that will happen below. For
right now, say that you don't want it to start at boot. You can
change that later with dpkg-reconfigure openafs-client.
In order to complete the AFS installation, you will also need a
working AFS client installed on that system, which means that you
need to install an OpenAFS kernel module. Please see:
/usr/share/doc/openafs-client/README.modules
for information on how to do that.
4. Create an AFS principal in Kerberos. This is the AFS service
principal, used by clients to authenticate to AFS and for AFS
servers to authenticate to each other. It *must* be a DES key; AFS
does not support any other encryption type. Run kadmin.local on
your KDC and then, at the prompt, run:
addprinc -randkey -e des-cbc-crc:v4 afs
If your Kerberos realm name does not match your AFS cell name (if,
for instance, you have one Kerberos realm with multiple AFS cells),
use "afs/cell.name" as the name of the principal above instead of
just "afs", where cell.name is the name of your new AFS cell.
5. On the db server, download this key into a keytab. If this is the
same system as the KDC, you can use kadmin.local again. If not, you
should use kadmin (make sure that krb5-user is installed), and you
may need to pass -p username/admin to kadmin to tell it what
principal to authenticate as. Whichever way you get into kadmin,
run:
ktadd -k /tmp/afs.keytab afs
(or afs/cell.name if you used that instead). In the message that
results, note the kvno number reported, since you'll need it later.
6. Create the AFS KeyFile with:
asetkey add <kvno> /tmp/afs.keytab afs
(or afs/cell.name if you used that instead). <kvno> should be
replaced by the kvno number reported by kadmin. This tells AFS the
Kerberos key that it should use, making it match the key in the
Kerberos KDC.
7. If the name of your Kerberos realm does not match the name of your
AFS cell, tell AFS what Kerberos realm to use with:
echo REALM > /etc/openafs/server/krb.conf
where REALM is the name of your Kerberos realm. If your AFS cell
and Kerberos realm have the same name, this is unnecessary.
7. Create some space to use for AFS volumes. You can set up a separate
AFS file server on a different system from the Kerberos KDC and AFS
db server, and for a larger cell you will want to do so, but when
getting started you can make the db server a file server as well.
For a production cell, you will want to create a separate partition
devoted to AFS and mount it as /vicepa (and may want to make
multiple partitions mounted as /vicepb, /vicepc, etc.), but for
testing purposes, you can use the commands below to create a
zero-filled file, create a file system in it, and then mount it:
dd if=/dev/zero of=/var/lib/openafs/vicepa bs=1024k count=32
mke2fs /var/lib/openafs/vicepa
mkdir /vicepa
mount -oloop /var/lib/openafs/vicepa /vicepa
mke2fs will ask you if you're sure you want to create a file system
on a non-block device; say yes.
8. Run afs-newcell. This will prompt you to be sure that the above
steps have been complete and will ask you for the Kerberos principal
to use for AFS administrative access. You should use the
username/admin principal discussed above.
At the completion of this step, you should see bosserver and several
other AFS server processes running, and you should be able to see
the status of those procesess with:
bos status localhost -local
Now, you should be able to run:
kinit username/[EMAIL PROTECTED]
aklog cell.name -k REALM
where username/admin is the admin principal discussed above, REALM
is the name of your Kerberos realm, and cell.name is the name of
your AFS cell. This will obtain Kerberos tickets and AFS tokens in
your Kerberos realm and new AFS cell. You should be able to see
your AFS tokens by running:
tokens
Finally, you should be able to see the status of the AFS server
processes with:
bos status <hostname>
where <hostname> is the hostname of the local system, once you've
done the above. This tests authenticated bos access as your admin
principal (rather than using the local KeyFile to authenticate).
9. Run afs-rootvol. This creates the basic AFS volume structure for
your new cell. It will prompt you to be sure that the above steps
are complete and then will ask you what file server and partition to
create the volume on. If you were following the above instructions,
use the local hostname and "a" as the partition (without the
quotes), which will use /vicepa.
After this command completes, you should be able to /bin/ls /afs and
see your local cell (and, if you aren't using dynroot, mount points
for several other cells). Note that if you're not using dynroot,
run /bin/ls rather than just ls to be sure that ls isn't aliased to
ls -F, ls --color, or some other option that would stat each file in
/afs, since this would require contacting lots of foreign cells and
could take a very long time.
You should now be able to cd to /afs/cell.name where cell.name is
the AFS cell name that you used. Currently, there isn't anything in
your cell. To make modifications, cd to /afs/.cell.name (note the
leading period) and make changes there. To make those changes show
up at /afs/cell.name, run vos release root.cell. For more details
on what you can do now, see the AFS Administrator's Reference.
Congratulations! You now have an AFS cell. If any of the above steps
failed, please check the steps carefully and make sure that you've done
them all in order. If that doesn't reveal the cause of the problem,
please feel free to submit a bug report with reportbug. Include as many
details as possible on exactly what you typed and exactly what you saw
as a result, particularly any error messages.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
