(no commit message)
[openafs-wiki.git] / InstallingOpenAFSinLXC.mdwn
index 7d294f2..462bbc6 100644 (file)
@@ -31,7 +31,7 @@ We now need a configuration file for the LXC container.  Place the following at
 
     lxc.utsname = lxcafs
     lxc.rootfs = /home/lxc-afs
-    lxc.cap.keep = none
+    lxc.cap.keep = chown dac_override dac_read_search fowner
     lxc.network.type = none
     lxc.pts = 16
     lxc.id_map = u 0 524288 32767
@@ -45,6 +45,10 @@ We now need a configuration file for the LXC container.  Place the following at
     lxc.mount.entry=/sbin      sbin      none  ro,bind  0 0
     lxc.mount.entry=tmpfs      /dev/shm  tmpfs defaults 0 0
 
+If you are not intending to run the file server inside the container, you may replace the capability grants with
+
+    lxc.cap.keep = none
+
 It's easiest to bring up a shell prompt within the container and run the remainder of the setup there.  On the host, run `lxc-execute -n afs-maint -f /home/lxc-afs.conf -- bash`.  This command can be rerun whenever you need a shell "next to" the AFS servers.  At that prompt, you'll want to populate common files, like `/etc/hosts`, `/etc/krb5.conf`, the contents of `/etc/openafs/server`, and `/usr/var/openafs/NetInfo`, as you would any other AFS server.  Be sure to land a `/etc/openafs/server/rxkad.keytab` file.
 
 If you watch, you'll note that while this shell believes these files are owned by root, the host filesystem has them owned by `524288`.  The host `ps`, likewise, will show your shell running as `524288`.  (Note that ownership of files owned by users outside the container's range will get mapped to `nobody`, and mode bits may be squashed.  If files in `/home/lxc-afs` are actually owned by host `root`, for example, they may be unreadable within the container!  This may lead to all kinds of interesting problems, so if things seem to be going wrong, check that first.)
@@ -60,4 +64,4 @@ and either run it by hand or use your host system's process management (sysvinit
 
 ### Set up AFS
 
-At this point, proceed to configure your AFS servers as you would any other; they will run as container root and be able to do the chowns and chmods that they need for the backing store, and will perceive their own UID as 0 without actually having any POSIX capabilities that usually come along with being UID 0.
+At this point, proceed to configure your AFS servers as you would any other; they will run as container root and be able to do the chowns and chmods that they need for the backing store, and will perceive their own UID as 0 without actually having any POSIX capabilities that usually come along with being UID 0 (other than those granted above, of course, which are necessary for the namei fileserver backend's operation).