On 05/10/2020 03:23, tom wrote:
> On Sat, 3 Oct 2020 11:04:23 +0100
> g4sra via Dng <dng@lists.dyne.org> wrote:
>
>> I am seeking any Devuaners with an interest in lxc to bounce ideas
>> off.
-- snip --
>
> Hello grsra, I run LXC on Devuan, and have done so even through the
> ascii->beowulf migration. I have some custom scripts and such for doing
> so, but found the devuan gitlab a little overwhelming and a lack of
> interest by other devuaners with LXC. If your interested in
> Devuan+OpenRC+LXC I'm probably your man.
>
> I would appreciate if we kept this on-board unless needed. Never know
> when someone in the future might find it useful.
>
Hi Tom,
This is my current thinking with regard to a LXC Container system for building
OS images and support software.
The host workstation has all the standard development tools ('build-essential'
etc) that any/all containers would normally need.
This can be updated as required (in effect, updating all containers).
The containers must run unprivileged as the both the software being built and
the build software itself may be of dubious quality (especially if I wrote it).
Container1:
bind,ro mounts the host filesystem providing development tool access
overlayfs a delta filesystem on which required tools\libraries etc can be
built
ContainerN: repeat above as often as required
ContainerX:
bind,ro mounts the host filesystem providing development tool access
bind,ro mounts CN deltas to provide access to the tools\libraries
overlayfs a delta filesystem on which the test OS can be built
Can you:
see anything wrong with the proposed above where container superuser
privileges and device access would allow corruption of either the Host or of a
neighbouring container ?
think of anything builds require that I have not made allowance for ?
detail a better way for obtaining my goal ?
Appreciate your comments Tom.
Charlie
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
