From: Russ Allbery Date: Thu, 18 Aug 2005 17:36:20 +0000 (+0000) Subject: * Improve the documentation and scripts for setting up new servers or a X-Git-Tag: debian/1.4rc1-1~34 X-Git-Url: https://git.michaelhowe.org/gitweb/?a=commitdiff_plain;h=91e8495eb61411a564cd1f7ced2f1fad37d4cf81;p=packages%2Fo%2Fopenafs.git * Improve the documentation and scripts for setting up new servers or a new cell. afs-rootvol can now be run from a client configured to use dynroot. afs-newcell generates the server CellServDB directly to work around oddities with bos addhost. Thanks to Fahemm Mitha and Sergio Gelato for analysis and patches. (Closes: #322638) --- diff --git a/debian/README.servers b/debian/README.servers index 8bbae5966..bcf9ab5e4 100644 --- a/debian/README.servers +++ b/debian/README.servers @@ -1,47 +1,356 @@ - Setting up a Debian OpenAFS Server + Setting up a Debian OpenAFS Server -These packages include binaries with FHS-compatible path names. Here -is a map from AFS paths to FHS paths: +Introduction -/usr/afs/etc /etc/openafs/server -/usr/afs/local /etc/openafs/server-local -/usr/afs/db /var/lib/openafs/db -/usr/afs/logs /var/log/openafs -/usr/afs/bin /usr/lib/openafs + This document describes how to set up an OpenAFS server using the Debian + packages. If you are not already familiar with the basic concepts of + OpenAFS, you should review the documentation at: + -Scripts are provided to configure a single database/file server. The -afs-newcell script sets up the initial databases and configures -bosserver. After running this script, get tokens in the cell and run -the afs-rootvol script to populate the root volume and root.cell. A -sample transcript of configuring an AFS cell can be found in -/usr/share/doc/openafs-dbserver/configuration-transcript.txt.gz. This -transcript assumes you are using MIT Kerberos and the openafs-krb5 -package. Similar steps could be taken with Heimdal. + particularly the AFS Administrator's Guide. This documentation is + somewhat out of date (it doesn't talk about how to use a Kerberos v5 KDC + instead of the AFS kaserver, for example), but it's a good introduction + to the basic concepts and servers you will need to run. -Another issue is upgrades. It is likely that future versions of this -package will install for example /usr/lib/openafs/fileserver.package -instead of /usr/lib/openafs/fileserver. The postinst script will -create links the actual binaries. Upgrades will not replace the old -binaries, but a script will be provided to roll the links forward to -the new versions. The intent is that people could install the new -package on all their servers and then quickly move the links before -restarting the bosserver. + The Debian OpenAFS packages follow the FHS and therefore use different + paths than the standard AFS documentation or the paths that experienced + AFS administrators may be used to. In the first column below are the + traditional paths, and in the second column, the Debian paths: - Adding Additional Servers + /usr/afs/etc /etc/openafs/server + /usr/afs/local /etc/openafs/server-local + /usr/afs/db /var/lib/openafs/db + /usr/afs/logs /var/log/openafs + /usr/afs/bin /usr/lib/openafs + /usr/vice/etc /etc/openafs -If you decide one server is not enough, here is roughly what needs to -happen: + The AFS kaserver (a Kerberos v4 KDC) is not packaged for Debian. Any + new OpenAFS installation should use Kerberos v5 for authentication in + conjunction with either the tools packaged in the openafs-krb5 package + or the Heimdal KDC. When setting up a new cell, you should therefore + not set up a kaserver as described in the AFS Administrator's Guide, and + you will need to follow a slightly different method of setting the cell + key. -1) Copy securely (using scp , encrypted Kerberized rcp or some other - secure method) /etc/openafs/server to the new server. +Creating a New Cell -2) Start a bosserver. + For documentation on adding a server to an existing cell, see below. -3) If the machine is to be a file server, create an fs instance using - bos create. For file servers this is all you need to do. + 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. -4) For database servers, you also need to do a bos addhost on all - servers (including the new server) to add the new server to - /etc/openafs/server/CellServDB. Then create ptserver and vlserver - instances. + /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 (Key Distribution Center, + the daemon that handles Kerberos authentication) 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/admin@REALM * + + 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. Enter the name of the local system when prompted + for the names of your OpenAFS db servers. 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. + + If you have already installed openafs-client and configured it for + some other cell, you do need to configure it to point to your new + cell for these instructions to work. Stop the AFS client on the + system with /etc/init.d/openafs-client stop and then run: + + dpkg-reconfigure openafs-client + + pointing it to the new cell you're about to create instead. + Remember, your cell name should be in lowercase. If you have had to + do this several times, double-check /etc/openafs/CellServDB when + you're done and make sure that there is only one entry for your new + cell at the top of that file and that it lists the correct IP + address for your new db server. + + 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 kadmin.local 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 -e des-cbc-crc:v4 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 + (it will normally be 3). + + Don't forgoet the -e des-cbc-crc:v4 to force the afs key to be DES. + You can verify this with: + + getprinc afs + + and checking to be sure that the only key listed is a DES key. If + there are multiple keys listed, delprinc the afs principal, delete + the /tmp/afs.keytab file, and then start over with addprinc, making + sure not to forget the -e option. + + 6. Create the AFS KeyFile with: + + asetkey add /tmp/afs.keytab afs + + (or afs/cell.name if you used that instead). 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/admin@REALM + 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 + + where 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. + + 10. While this is optional, you probably want to add AFSDB records to + DNS for your new AFS cell. These special DNS records let AFS + clients find the db servers for your cell without requiring local + configuration. To do this, create a DNS record like: + + . 3600 IN AFSDB 1 . + + where is the name of your AFS cell and is the name + of your db server. Note the trailing periods to prevent the DNS + server from appending the origin. You can, of course, choose what + you prefer for the lifetime. The 1 is not a priority; it's a + special indicator saying that this record is for an AFS database + server. + + If you have multiple db servers (see below for adding new ones), you + should create multiple records of this type, one per db server. + + 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. + +Adding Additional Servers + + If you decide one server is not enough, or if you're adding a server to + an existing cell, here is roughly what you should do: + + 1. Copy securely (using scp, encrypted Kerberos rcp, or some other + secure method) all of /etc/openafs/server to the new server. + + 2. Install the openafs-fileserver package on the new server. + + 3. If the machine is to be a file server, create an fs instance using + bos create: + + bos create fs fs -cmd /usr/lib/openafs/fileserver \ + -cmd /usr/lib/openafs/volserver \ + -cmd /usr/lib/openafs/salvager -localauth + + For a file server, this is all you have to do. + + 4. For database servers, also install openafs-dbserver and then use bos + addhost to add the new server to /etc/openafs/server/CellServDB: + + bos addhost + + for each db server in your cell (including the new one). + Then, create ptserver and vlserver instances on the new server: + + bos create ptserver simple /usr/lib/openafs/ptserver \ + -localauth + bos create vlserver simple /usr/lib/openafs/vlserver \ + -localauth + + The existing servers should then propagate the database to the new + server. Note that you do not need to run a file server on a db + server if you don't want to (and larger sites probably will not want + to), but you always need to have the openafs-fileserver package + installed on db servers. It contains the bosserver binary and some + of the shared infrastructure. + + 5. If you added a new db server, configure your clients to use it. If + you are using AFSDB records in DNS, you can just add a new record + (see point 10 in the instructions for creating a new cell). + Otherwise, clients will need to have the new server IP address added + to their /etc/openafs/CellServDB file (or /usr/vice/etc/CellServDB + for non-Debian clients using the standard AFS paths), and the client + will have to be restarted before it will know about the new db + server. + + The standard rule of thumb is that all of your database servers and file + servers should ideally be running the same version of OpenAFS. However, + in practice OpenAFS is fairly good at backward compatibility and you can + generally mix and match different versions. Be careful, though, to + ensure that all of your database servers are built the same when it + comes to options like --enable-supergroups (enabled in the Debian + packages). + +Upgrades + + Currently, during an upgrade of the openafs-fileserver package, all + services will be stopped and restarted. If openafs-dbserver is upgraded + without upgrading openafs-fileserver, those server binaries will not be + stopped and restarted; that restart will have to be done by hand. + + It is possible that future versions of this package will install for + example /usr/lib/openafs/fileserver.package instead of + /usr/lib/openafs/fileserver and then create links to the actual binaries + in postinst. Upgrades would then not replace the old binaries, but + instead a script will be provided to roll the links forward to the new + versions. The intent is that people could install the new package on + all their servers and then quickly move the links before restarting the + bosserver. This has not yet been implemented. diff --git a/debian/afs-newcell b/debian/afs-newcell index d411dc5a5..d98777561 100644 --- a/debian/afs-newcell +++ b/debian/afs-newcell @@ -1,20 +1,20 @@ #!/usr/bin/perl -w # Copyright (C) 2000 by Sam Hartman -# This file may be copied either under the terms of the GNU GPL or the IBM Public License -# either version 2 or later of the GPL or version 1.0 or later of the IPL. +# This file may be copied either under the terms of the GNU GPL or the IBM +# Public License either version 2 or later of the GPL or version 1.0 or later +# of the IPL. use Term::ReadLine; use strict; use Debian::OpenAFS::ConfigUtils; use Getopt::Long; use Socket qw(inet_ntoa); -use vars qw($admin $server - $requirements_met $shutdown_needed); +use vars qw($admin $server $requirements_met $shutdown_needed); my $rl = new Term::ReadLine('afs-newcell'); =head1 NAME - afs-newcell - Set up initial database server for AFS cell. +afs-newcell - Set up initial database server for AFS cell =head1 SYNOPSIS @@ -22,17 +22,15 @@ B [B<--requirements-met>] [B<--admin> admin_user] =head1 DESCRIPTION - This script sets up the initial AFS database and configures the first database/file server. -The B option specifies that the initial requirements -have been met and that the script can proceed without displaying the -initial banner or asking for confirmation. +The B<--requirements-met> option specifies that the initial requirements have +been met and that the script can proceed without displaying the initial +banner or asking for confirmation. -The B option specifies the name of the administrative user. -This user will be given system:administrators and susers permission in -the cell. +The B<--admin> option specifies the name of the administrative user. This +user will be given system:administrators and susers permission in the cell. =head1 AUTHOR @@ -40,15 +38,14 @@ Sam Hartman =cut -# main script +# Flush all output immediately. +$| = 1; -GetOptions ( - "requirements-met" => \$requirements_met, - "admin=s" => \$admin); +GetOptions ("requirements-met" => \$requirements_met, "admin=s" => \$admin); unless ($requirements_met) { - print <readline("Do you meet these requirements? [y/n] "); - unless (/^y/i ) { - print "Run this script again when you meet the requirements\n"; - exit(1); - } - - if ($> != 0) { -die "This script should almost always be run as root. Use the --requirements-met option to run as non-root.\n"; -} + $_ = $rl->readline("Do you meet these requirements? [y/n] "); + unless (/^y/i ) { + print "Run this script again when you meet the requirements\n"; + exit(1); + } + + if ($> != 0) { + die "This script should almost always be run as root. Use the\n" + . "--requirements-met option to run as non-root.\n"; + } } + +# Make sure the AFS client is not already running. open(MOUNT, "mount |") or die "Failed to run mount: $!\n"; while() { -if(m:^AFS:) { -print "The AFS client is currently running on this workstation.\n"; -print "Please restart this script after running /etc/init.d/openafs-client stop\n"; -exit(1); -} + if (m:^AFS:) { + print "The AFS client is currently running on this workstation.\n"; + print "Please restart this script after running" + . " /etc/init.d/openafs-client stop\n"; + exit(1); + } } close MOUNT; +# Make sure there is a keyfile. unless ( -f "/etc/openafs/server/KeyFile") { - print "You do not have an AFS keyfile. Please create this using asetkey from openafs-krb5 or -the bos addkey command"; - exit(1); + print "You do not have an AFS keyfile. Please create this using asetkey" + . " from openafs-krb5\n"; + print "or the bos addkey command\n"; + exit(1); } +# Stop the file server. print "If the fileserver is not running, this may hang for 30 seconds.\n"; run("/etc/init.d/openafs-fileserver stop"); -$server = `hostname`; + +# Get the local hostname. Use the fully-qualified hostname to be safer. +$server = `hostname -f`; chomp $server; my $ip = gethostbyname $server; -if (inet_ntoa ($ip) eq '127.0.0.1') { +if (inet_ntoa($ip) eq '127.0.0.1') { print "Your hostname $server resolves to 127.0.0.1, which AFS cannot\n"; print "cope with. Make sure your hostname resolves to a non-loopback\n"; print "IP address. (Check /etc/hosts and make sure that your hostname\n"; @@ -121,81 +127,113 @@ if (inet_ntoa ($ip) eq '127.0.0.1') { print "that line will probably solve this problem.)\n"; exit(1); } -$admin = $rl->readline("What administrative principal should be used? ") unless $admin; - die "Please specify an administrative user\n" unless $admin; -$admin =~ s:/:.:g; -if($admin =~ /@/) { -die "The administrative user must be in the same realm as the cell and no realm may be specified.\n"; + +# Determine the admin principal. +$admin = $rl->readline("What administrative principal should be used? ") + unless $admin; +print "\n"; +die "Please specify an administrative user\n" unless $admin; +my $afs_admin = $admin; +$afs_admin =~ s:/:.:g; +if ($afs_admin =~ /@/) { + die "The administrative user must be in the same realm as the cell and\n" + . "no realm may be specified.\n"; } -open(CELL, "/etc/openafs/server/ThisCell") - or die "Cannot open /etc/openafs/server/ThisCell: $!\n"; + +# Determine the local cell. This should be configured via debconf, from the +# openafs-client configuration, when openafs-fileserver is installed. +open(CELL, "/etc/openafs/server/ThisCell") + or die "Cannot open /etc/openafs/server/ThisCell: $!\n"; my $cell = ; chomp $cell; -run( "echo \\>$cell >/etc/openafs/server/CellServDB"); +# Write out a new CellServDB for the local cell containing only this server. +if (-f "/etc/openafs/server/CellServDB") { + print "/etc/openafs/server/CellServDB already exists, renaming to .old\n"; + rename("/etc/openafs/server/CellServDB", + "/etc/openafs/server/CellServDB.old") + or die "Cannot rename /etc/openafs/server/CellServDB: $!\n"; +} +open(CELLSERVDB, "> /etc/openafs/server/CellServDB") + or die "Cannot create /etc/openafs/server/CellServDB: $!\n"; +print CELLSERVDB ">$cell\n"; +print CELLSERVDB inet_ntoa($ip), "\t\t\t#$server\n"; +close CELLSERVDB or die "Cannot write to /etc/openafs/server/CellServDB: $!\n"; + +# Now, we should be able to start bos and add the admin user. run("/etc/init.d/openafs-fileserver start"); $shutdown_needed = 1; -run ("bos addhost $server $server -localauth ||true"); -run("bos adduser $server $admin -localauth"); -unwind("bos removeuser $server $admin -localauth"); -if ( -f "/var/lib/openafs/db/prdb.DB0" ) { - die "Protection database already exists; cell already partially created\n"; - } -open(PRDB, "|pt_util -p /var/lib/openafs/db/prdb.DB0 -w ") -or die "Unable to start pt_util: $!\n"; -print PRDB "$admin 128/20 1 -204 -204\n"; +run("bos adduser $server $afs_admin -localauth"); +unwind("bos removeuser $server $afs_admin -localauth"); + +# Create the initial protection database using pt_util. This is safer than +# the standard mechanism of starting the cell in noauth mode until the first +# user has been created. +if (-f "/var/lib/openafs/db/prdb.DB0") { + die "Protection database already exists; cell already partially created\n"; +} +open(PRDB, "| pt_util -p /var/lib/openafs/db/prdb.DB0 -w") + or die "Unable to start pt_util: $!\n"; +print PRDB "$afs_admin 128/20 1 -204 -204\n"; print PRDB "system:administrators 130/20 -204 -204 -204\n"; -print PRDB" $admin 1\n"; +print PRDB" $afs_admin 1\n"; close PRDB; -unwind( "rm /var/lib/openafs/db/prdb* "); -# Start up ptserver and vlserver +unwind("rm /var/lib/openafs/db/prdb*"); + +# We should now be able to start ptserver and vlserver. run("bos create $server ptserver simple /usr/lib/openafs/ptserver -localauth"); unwind("bos delete $server ptserver -localauth"); - run("bos create $server vlserver simple /usr/lib/openafs/vlserver -localauth"); unwind("bos delete $server vlserver -localauth"); -run( "bos create $server fs fs ". - "-cmd /usr/lib/openafs/fileserver ". - "-cmd /usr/lib/openafs/volserver ". - "-cmd /usr/lib/openafs/salvager -localauth"); -unwind( "bos delete $server fs -localauth "); +# Create a file server as well. +run("bos create $server fs fs" + . " -cmd /usr/lib/openafs/fileserver" + . " -cmd /usr/lib/openafs/volserver" + . " -cmd /usr/lib/openafs/salvager -localauth"); +unwind("bos delete $server fs -localauth"); +# Pause for a while for ubik to catch up. print "Waiting for database elections: "; sleep(30); print "done.\n"; -# Past this point we want to control when bos shutdown happens + +# Past this point we want to control when bos shutdown happens. $shutdown_needed = 0; -unwind( "bos shutdown $server -localauth "); +unwind("bos shutdown $server -localauth"); run("vos create $server a root.afs -localauth"); -# bring up client -run("echo $cell >/etc/openafs/ThisCell"); + +# We should now be able to bring up the client (it may need root.afs to exist +# if not using dynroot). We override whatever default cell was configured for +# the client, just in case it was pointing to some other cell. +open(THIS, "> /etc/openafs/ThisCell") + or die "Cannot create /etc/openafs/ThisCell: $!\n"; +print THIS "$cell\n"; +close THIS or die "Cannot write to /etc/openafs/ThisCell: $!\n"; run("/etc/init.d/openafs-client force-start"); + +# Verify that AFS has managed to start. my $afs_running = 0; open(MOUNT, "mount |") or die "Failed to run mount: $!\n"; while() { -if(m:^AFS:) { - $afs_running = 1; + if (m:^AFS:) { + $afs_running = 1; + } } - } unless ($afs_running) { -print "*** The AFS client failed to start.\n"; -print "Please fix whatever problem kept it from running.\n"; - exit(1); + print "The AFS client failed to start.\n"; + print "Please fix whatever problem kept it from running.\n"; + exit(1); } +print "Now, get tokens as $admin in the $cell cell.\n" +print "Then, run afs-rootvol.\n"; -print < [B<--requirements-met>] [B<--server> server-name] [B<--partition> partition-letter] +B [B<--requirements-met>] [B<--server> I] +[B<--partition> I] =head1 DESCRIPTION -This script sets up an AFS cell's root volumes. It assumes that you -already have a fileserver and database servers. The fileserver should -have an empty root.afs. - This script creates root.cell, user, service and populates root.afs. +This script sets up an AFS cell's root volumes. It assumes that you already +have a fileserver and database servers. The fileserver should have an empty +root.afs. This script creates root.cell, user, and service and populates +root.afs. =head1 AUTHOR @@ -28,130 +32,149 @@ Sam Hartman =cut -use vars qw($rl $server $part $requirements_met); -use vars qw( @unwinds); -use Debian::OpenAFS::ConfigUtils; - - # This subroutine creates a volume, mounts it and then sets the access # to allow read by anyuser. The volume is scheduled for deletion in # case of error. -# mkvol(volume, mount) - sub mkvol($$) { - my ($vol, $mnt) = @_; - run("vos create $server $part $vol -localauth"); - unwind("vos remove $server $part $vol -localauth"); - run("fs mkm $mnt $vol "); - run("fs sa $mnt system:anyuser rl"); - } - -# main script -$rl = new Term::ReadLine('AFS'); - +sub mkvol($$) { + my ($vol, $mnt) = @_; + run("vos create $server $part $vol -localauth"); + unwind("vos remove $server $part $vol -localauth"); + run("fs mkm $mnt $vol "); + run("fs sa $mnt system:anyuser rl"); +} -GetOptions ( - "requirements-met" => \$requirements_met, - "server=s" => \$server, - "partition=s" => \$part - ); +# Main script. Flush all output immediately. +$| = 1; +$rl = new Term::ReadLine('AFS'); +GetOptions ("requirements-met" => \$requirements_met, + "server=s" => \$server, + "partition=s" => \$part); unless ($requirements_met) { - print <readline("Do you meet these conditions? (y/n) "); unless (/^y/i ) { - print "Please restart the script when you meet these conditions.\n"; - exit(1); + print "Please restart the script when you meet these conditions.\n"; + exit(1); + } + if ($> != 0) { + die "This script should almost always be run as root. Use the\n" + . "--requirements-met option to run as non-root.\n"; } - - if ($> != 0) { -die "This script should almost always be run as root. Use the --requirements-met option to run as non-root.\n"; } -} -# Get configuration information we need +# Get configuration information we need. open(CELL, "/etc/openafs/server/ThisCell") -or die "Unable to find out what cell this machine serves: $!\n"; + or die "Unable to find out what cell this machine serves: $!\n"; my $cell = ; close CELL; chomp $cell; unless ($server) { - print <readline("What AFS Server should volumes be placed on? "); - die "Please select a server.\n" unless $server; + $server = $rl->readline("What AFS Server should volumes be placed on? "); + die "Please select a server.\n" unless $server; } unless ($part) { - $part = $rl ->readline("What partition? [a] "); -$part = "a" unless $part; + $part = $rl->readline("What partition? [a] "); + $part = "a" unless $part; } - -run("fs sa /afs system:anyuser rl"); - +# Figure out where root.afs is. There are two possibilities: either we aren't +# running with dynroot, and root.afs is therefore accessible as /afs, or we +# are running with dynroot, in which case we have to create root.cell first +# and then mount root.afs under it. +# +# Always create root.cell first; we may need it if running with dynroot, and +# it doesn't hurt to do it now regardless. +my $rootmnt = "/afs"; run("vos create $server $part root.cell -localauth"); unwind("vos remove $server $part root.cell -localauth"); -# We make root.cell s:anyuser readable after we mount in the next -# loop. - +my $dynroot = (-d "$rootmnt/$cell/."); +if ($dynroot) { + run("fs mkm /afs/$cell/.root.afs root.afs -rw"); + unwind("fs rmm /afs/$cell/.root.afs"); + $rootmnt = "/afs/$cell/.root.afs"; +} +run("fs sa $rootmnt system:anyuser rl"); +# Scan CellServDB and create the cell mount points for every cell found there. open(CELLSERVDB, "/etc/openafs/CellServDB") or die "Unable to open /etc/openafs/CellServDB: $!\n"; -while() { +while () { chomp; - if (/^>\s*([a-z0-9_\-.]+)/ ) { - run("fs mkm /afs/$1 root.cell -cell $1 -fast"); - unwind ("fs rmm /afs/$1"); + if (/^>\s*([a-z0-9_\-.]+)/) { + run("fs mkm $rootmnt/$1 root.cell -cell $1 -fast"); + unwind("fs rmm $rootmnt/$1"); } } +# Now, create the read/write mount points for root.cell and root.afs and set +# root.cell system:anyuser read. run("fs sa /afs/$cell system:anyuser rl"); -run ("fs mkm /afs/.$cell root.cell -cell $cell -rw"); -unwind ("fs rmm /afs/.$cell"); -run("fs mkm /afs/.root.afs root.afs -rw"); -unwind ("fs rmm /afs/.root.afs"); - -mkvol( "user", "/afs/$cell/user" ); -mkvol( "service", "/afs/$cell/service" ); - -$cell =~ /^([^.]*)/; +run("fs mkm $rootmnt/.$cell root.cell -cell $cell -rw"); +unwind("fs rmm $rootmnt/.$cell"); +run("fs mkm $rootmnt/.root.afs root.afs -rw"); +unwind("fs rmm $rootmnt/.root.afs"); + +# Create the user and service mount point volumes to fit the semi-standard AFS +# cell layout. +mkvol("user", "/afs/$cell/user"); +mkvol("service", "/afs/$cell/service"); + +# Strip the domain off of the cell name and create the short symlinks. +$cell =~ /^([^.]+)/; my $cellpart = $1; -run("ln -s /afs/$cell /afs/$cellpart"); -unwind ("rm /afs/$cellpart"); -run( "ln -s /afs/.$cell /afs/.$cellpart" ); -unwind ("rm /afs/.$cellpart"); - -run( "vos addsite $server $part root.afs -localauth" ); -run( "vos addsite $server $part root.cell -localauth" ); -run( "vos release root.afs -localauth" ); -run( "vos release root.cell -localauth" ); -unwind( "vos remove $server $part root.cell.readonly -localauth "); -unwind( "vos remove $server $part root.afs.readonly -localauth "); +if ($cellpart && $cellpart ne $cell) { + run("ln -s $cell $rootmnt/$cellpart"); + unwind("rm $rootmnt/$cellpart"); + run("ln -s .$cell $rootmnt/.$cellpart"); + unwind("rm $rootmnt/.$cellpart"); +} +if ($dynroot) { + run("fs rmm /afs/$cell/.root.afs"); + unwind("fs mkm /afs/$cell/.root.afs root.afs -rw"); +} +# Now, replicate the infrastructure volumes. +run("vos addsite $server $part root.afs -localauth"); +run("vos addsite $server $part root.cell -localauth"); +run("vos release root.afs -localauth"); +run("vos release root.cell -localauth"); +unwind("vos remove $server $part root.cell.readonly -localauth"); +unwind("vos remove $server $part root.afs.readonly -localauth"); + +# Success, so clear the unwind commands. @unwinds = (); +# If we fail before all the instances are created, we need to back out of +# everything we did as much as possible. END { - run(pop @unwinds) while @unwinds; - } - + run(pop @unwinds) while @unwinds; +} diff --git a/debian/changelog b/debian/changelog index 2369993b5..392b0e416 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,13 @@ +openafs (1.3.87-2) unstable; urgency=low + + * Improve the documentation and scripts for setting up new servers or a + new cell. afs-rootvol can now be run from a client configured to use + dynroot. afs-newcell generates the server CellServDB directly to work + around oddities with bos addhost. Thanks to Fahemm Mitha and Sergio + Gelato for analysis and patches. (Closes: #322638) + + -- + openafs (1.3.87-1) unstable; urgency=low * New upstream version.