[OpenAFS] OpenAFS client in LXC containers

[Neil Davies]

This approach has worked fine for us for several years now.

Note there is an isolation issue - if you grab tokens for UID 1000 =
inside a
container A, then all UID 1000 in all the other containers have tokens.

You can run processes within PAG within the container, but sometimes =
(for
certain daemon process scenarios) that doesn=92t quite cut it.


On 29 Jun 2015, at 17:31, Chaskiel Grundman <cg2v@andrew.cmu.edu> wrote:

>> afsd is a userspace process, and
> Not quite true... afsd used to provide a process context for kernel
> threads to run in, but doesn't even do that anymore. The only =
userspace
> part of afsd is the DNS lookup mechanism.
>=20
>> containers are namespaced.
> If only that were completely true....
>=20
>=20
> In any event, depending on your actual end goal, there's an easy =
answer to
> this: run openafs on the host, and put an afs entry in =
lxc.mount.entry:
>=20
> lxc.mount.entry =3D /afs /var/lib/lxc/<name>/rootfs/afs none =
defaults,bind 0 0
>=20
> Then install openafs-client in your container, but *don't* enable or
> run the startup script. fs commands and authentication will work
> transparently.
>=20
> The only disadvantage to this that I can see is that the the host and =
the
> host's networking will be used to make afs requests, and so if the =
host
> is not on the network, or you need to be able to identify which guest =
is
> making which requests, then this won't work.
>=20
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info