At Thu, 30 Jan 2020 12:00:13 +0100, Edgar Fuß <ef%math.uni-bonn.de@localhost> wrote:
Subject: merging /usr/bin etc. to / (was: Solving the syslogd problem)
>
> > This is elegant and I would like to see it. Just remove /usr entirely and
> > collapse its contents into / - no /usr/bin, no /usr/lib, etc.
>
> This thread started because syslogd lives in /usr, mounting of /usr
> depends on NETWORK, and so network daemons are unable to log to syslog
> (at least in the beginning).
>
> I guess mounting /usr depends on NETWORK for a reaseon, that reason
> most probably being to make it network-mountable.
>
> So if you move /usr (or /usr/bin etc.) to /, you lose the ability to
> have the contents of /usr/bin etc. reside on the network. You could
> just as well decide that /usr must be a local filesystem, no?
>
I think the network mountability of the "system" filesystem should be
thought of the other way around. I.e. not as a separate "/usr", but as
a combined single root filesystem with a separate "/etc" (and "/var").
I.e. if you want to mount all of the "system" files from a network
filesystem, then you should be able to do that even if it is all in /
(i.e. in the "root" filesystem) (and you should be able to make this
root FS read-only too, though perhaps there are niggles to work out
w.r.t. mounting onto a read-only root FS, as I recall).
This is all doable with traditional diskless "netboot" techniques (or
even disk-full/data-less with a minimal local "/boot", but see below).
In fact I have old (1.6) patches I once used to netboot and mount a
shared NFS root filesystem along with a separate NFS /etc for each
workstation host. I.e. I made the kernel make requests (with either
BOOTP or DHCP) for both root ("/") and "/etc" filesystems and mount them
both before starting init. I left /var to be handled by mountcritremote
using the now NFS-mounted /etc. "/usr" was just a directory on the
shared "/".
This could also be done to find a local /etc filesystem (and any other
filesystems required), i.e. with either a local or shared-remote root
filesystem.
Indeed in some situations even /etc could be read-only and thus part of
a shared read-only root filesystem; and /var could be a memory
filesystem.
Syslogd, if it finds no /etc/syslog.conf and/or no /var/log, could just
write early messages to /dev/console _and_ buffer them in as large a
ring buffer as might be reasonable until it gets its first SIGHUP (when
it reads /etc/syslog.conf for the first time). It could then be started
first, and never need to be re-started (leaving a gap). It would of
course want to listen for network interface changes too (though
re-binding to the listen address and re-opening the log_socket could be
done on SIGHUP too).
Then separate /opt, /home, /var, etc. can come from wherever, probably
with /var next in order to allow syslogd to write out any buffered log
messages as early as possible (i.e. send SIGHUP to syslogd once /var is
mounted.
It would even be possible to avoid in-kernel netboot techniques entirely
using a small local /boot partition with static-linked dhcpcd, ifconfig,
syslogd, etc. One possible trick to make this work would be for the
kernel to start with a memory filesystem for "/" and be able to mount
this "/boot" filesystem there. Then once the real "/" is mounted to
flip the /boot mount onto the new "/boot" directory on the real root
filesystem, all the while keeping the references to any running programs
started from it to allow for them to have demand paged text areas.
I.e. fake up an empty "/" memory filesystem with a single "/boot"
directory, mount the real /boot there, then replace the memory
filesystem with the new real root filesystem, updating the "/boot" mount
point to be on the new real "/boot" directory. /etc could be a union
mount between /boot/etc and some other etc filesystem.
But current netboot code probably suffices for most uses.
To me having a read-only shared root filesystem (with or without a
"/usr" sub-directory) and with a private writeable /etc and /var
filesystems has always seemed to be the ideal way to configure both VMs
and traditional workstations/server-farms (with possibly shared /opt and
/home, etc.).
Even when such a combined root filesystem comes from a locally attached
storage device on a stand-alone system it would be nice to be able to
make it all read-only with separate writeable /etc and /var filesystems.
Then comes my real blue-sky dream of using network and/or direct-
attached storage for shared read-only filesystems (i.e. as opposed to a
traditional network filesystem like NFS). E.g. for shared mounts of
/dev/xbd?? devices in Xen, or shared mounts of a single FibreChannel or
iSCSI target. Can we even invent a new kind of shareable filesystem
using, e.g., lockless on-disk data structures for writeable mounts?
--
Greg A. Woods <gwoods%acm.org@localhost>
Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost>
Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpdrZq7LWKSw.pgp
Description: OpenPGP Digital Signature