Subject: Re: [vserver] readonly root
From: "Michael S. Zick" <mszick@morethan.org>
Date: Thu, 10 Mar 2011 07:31:16 -0600

On Thu March 10 2011, Corin Langosch wrote:
> On 09.03.2011 15:10, Martin wrote:
> > You may wish to read the Linux Filesystem Standard which tells you which
> > part of the filesystem need to be read / write, which can be read only,
> > etc.  Beyond that you may wish to look at the overlay setup that live
> > CDs use.
> 
> When trying to start a vserver from a read-only path it won't work. 
> chroot-sh complains that several files are read-only, especially 
> /etc/mtab. I'm now using "aufs" with mounting my "shared root" ro and an 
> additional very small tmpfs partition rw (so the vserver can be started).
> 
> > Have you looked at vashify / hardlinks?
> 
> Yes, but I think it's not the best for my needs. I may be I wrong, so 
> I'll explain my needs below. :)
> 
> > Over all what problem are you trying to solve?  Read only filesystems
> > may not be the best way of acheiving reduced memory / disk usage, etc.
> 
> I need to setup a shared hosting environment where users can also login 
> using ssh, for example to work with the shell/ installed tools. So my 
> idea was to have a shared root layout with all common stuff installed 
> there. It must be read-only, so the users dont alter it. The user data/ 
> application code is in a separate folder and will be mounted inside the 
> vserver instance as needed.
> 
> Using this layout I hope to achive maximum performance (shared memory, 
> little virtualization overhead, ..), highest security and still giving 
> the users the freedom to use the shell/ tools. Now with "aufs", I'm only 
> worried if it's killing my reduced memory requirements.
> 

The auFS layer does require its own memory resources, so it will increase
your memory usage.

And here JRO should stop reading (the following is an over-simplification). . . .

In general, auFS just maps auFS:iNode to the filesystem:iNode used by
the corresponding filesystem of multiple filesystems. 
It does not copy the cached iNode buffer (unless it is creating a
new file in the case of the file being written to).

So I don't think that adding the auFS layer will have broken your
overall plan of having everyone reading the same cached iNode.

You may want to setup a more specific layered file system -
something with a bit finer distinction than just "root" (/).

For instance:
Put everything that will be RO in the fs tree into a real, read-only
(RR) file system (such as squashfs), and;

Put an auFS layer over just those files of the fs tree that you need
to allow system writes to (your example given was /etc/mtab).
Although in the case of /etc/mtab you should probably be using /proc/mounts.

Mike
> Thanks,
> Corin
> 
>