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’t quite cut it. On 29 Jun 2015, at 17:31, Chaskiel Grundman <c...@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. > >> containers are namespaced. > If only that were completely true.... > > > 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: > > lxc.mount.entry = /afs /var/lib/lxc/<name>/rootfs/afs none defaults,bind 0 0 > > Then install openafs-client in your container, but *don't* enable or > run the startup script. fs commands and authentication will work > transparently. > > 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. > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
