[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: /usr (was: Re: Survey answers part 3: systemd is not portable and what this) means for our ports

On 16 July 2013 19:39, Roger Leigh <rleigh@codelibre.net> wrote:
> On Tue, Jul 16, 2013 at 06:38:18PM +0100, Dmitrijs Ledkovs wrote:
>> On 16 July 2013 17:07, Roger Leigh <rleigh@codelibre.net> wrote:
>> > Once the rootfs is mounted, we parse $root/etc/fstab and mount /usr
>> > using that information.  When init starts, /usr is therefore
>> > available from the beginning.  Note that the objective here isn't
>> > to allow the initramfs to run binaries from /usr, but to ensure
>> > that /usr is available at all times when the system is running--
>> > this means that all programs, libraries, modules, datafiles etc.
>> > are available before init starts.
>> >
>> > There are some complicating details:
>> > - we need to ensure that the modules needed to mount /usr are
>> >   available in the initramfs (copy the needed modules and
>> >   mount helpers into the initramfs)
>> > - we can't fsck /usr when mounted, so this needs doing in the
>> >   initramfs (/ and /usr are fscked, with the appropriate
>> >   helpers copied into the initramfs)
>> > - fsck's -R option updated to skip /usr as well as root.
>> > - /etc/init.d/checkroot.sh updated to handle /usr as well
>> >   as root (e.g. remounting r/w).
>> Up to here, all sounds good.
>> Making the $mountpoints which above are treated / mounted in
>> initramfs, makes sense.
>> To be able to default to "/" only and change to "/ and /usr" if one desires.
>> And even plugin in the feature below.
>> > - using the same infrastructure, it's also possible to
>> >   mount /etc in the initramfs so that you can have e.g. a
>> >   separately encrypted /etc filesystem.  This is a separate
>> >   feature though and can be split out.
>> >
>> Imho the overhead between having just "/etc" vs "/" encrypted is
>> small, if "/var", "/usr", "/home", "/opt" are separate mountpoints.
>> Thus to me, treating "/etc" separately is a misfeature, considering a
>> mounted "/" assumes /etc must be present.
>> At least, it would go against my expectation.
> This is certainly the case at present.  The rationale for doing this
> is that if you have / and /usr on a single filesystem, but you want
> to encrypt the content of /etc, you can now encrypt just /etc.  It
> also means you can have the rootfs read-only with a writable /etc,
> have /etc as a writable overlay or separate fs on a common image for
> cluster environments, etc.  For encrypting stuff, it's moving the
> boundary from one of simple convienience (/usr) to where it's actually
> needed.  But I can accept that this won't have universal appeal.

Thinking about it more, it's possibly not the encryption case which
might be most prominent here.
I have seen containers / images made readonly, with /etc mounted using
overlayfs to provide easily clonable machines (chroots,
lxc-containers, "cloud-images").
Not sure, but probably, capser was used to do the mounting there.

>> I haven't yet reviewed the 17 patches log patch series on [1]. But is
>> "/etc" handling clearly separated in it already, or some
>> rebasing/reshuffling needed?
> It's just patch number 11/17 with some minor documentation comments in
> patch 12/17, so it can be easily dropped without problems (intentionally).
> However, even if applied, it's a strictly optional feature that won't be
> used by default unless you provide etc= options to match the root=
> options on the kernel command-line.

Ok, thanks for the heads up.



Reply to: