[OpenAFS] OpenAFS client in LXC containers

[Neil Davies]

That would be very useful - it would mean stronger isolation between =
docker instances
using AFS.

You would be "trusting" the docker host to operate correctly - but it =
would mean the=20
docker instances share a a common cache (which may have advantages).

We keep all our serious long term state in AFS (i.e. it is the only =
thing we back up),
so we've been using AFS+lxc (now as docker) to do things like mail =
(seperate=20
containers per function), continuous intergration, saltmasters etc etc. =
If the name space
seperation was there then there are more functions I could aggregate =
into single host spaces

This would get me closer to a goal where, on a single ARM instance, I =
can deploy a complete
"basic company infrastructure" - we're a completely distributed company =
and employees could then
have their "local" filestore truely local to them!

On 8 Jul 2015, at 16:17, Charles (Chas) Williams <3chas3@gmail.com> =
wrote:

> I don't think this should be too hard to fix.  We would need to add
> namespace support (keep track of which namespace a uid came from) to
> struct unixuser.
>=20
> On Wed, 2015-07-08 at 16:03 +0100, Neil Davies wrote:
>> On 8 Jul 2015, at 15:23, Bertrand NOEL <bertrand.noel.88@gmail.com> =
wrote:
>>=20
>>> Chaskiel, Neil, thanks for your answers!
>>> I tried your approach. It works well, with the limitations you
>>> describe (I guess the isolation issue would be solved with user
>>> namespace, right?).
>>>=20
>>=20
>> Must admit I've not managed to resolve it that way, PAGs work but
>> the namespace isolation doesn't seem to.
>>=20
>>> This is good to know, but it is difficult to apply to my use-case,
>>> because I create my containers with Openstack, which does not =
support
>>> sharing a folder from host to container. This is why I wanted to =
have
>>> most of the things in the container.
>>>=20
>>> For my first problem (module on host, creating container, starting
>>> afsd, then kill container, create a new container, starting afsd =
gets
>>> stuck), I see that if I reload openafs module between terminating =
the
>>> first container, and creating the new one, it makes afsd work the
>>> second time.
>>=20
>> _______________________________________________
>> OpenAFS-info mailing list
>> OpenAFS-info@openafs.org
>> https://lists.openafs.org/mailman/listinfo/openafs-info
>=20
>=20