UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
Lennart Poettering
mzerqung at 0pointer.de
Sun Oct 30 22:02:20 UTC 2011
On Mon, 24.10.11 13:05, Chris Adams (cmadams at hiwaay.net) wrote:
Here's an attempt to summarize the rationale for merging /bin, /sbin,
/usr/sbin into /usr/bin with different words collecting the various points
raised:
a) the split between sbin and bin requires psychic powers from
upstream developers:
The simple fact is that moving binaries between these dirs is really
hard, and thus developers in theory would need to know at the time
they first introduce a binary whether it *ever* might ever make sense to
invoke it as unprivileged user (because in that case the binary
belongs in /bin, not /sbin). History shows that more often than
not developers have placed their stuff in the wrong directory, see
/sbin/arp, /sbin/ifconfig, /usr/sbin/httpd and then there is no smart
way to fix things anymore since changing paths means breaking all hardcoded
scripts. And hardcoding paths in scripts is actually something we
encourage due to perfomance reasons. The net effect is that many
upstream developers unconditionally place their stuff in bin, and
never consider sbin at all which undermines the purpose of sbin
entirely (i.e. in systemd we do not stick a single binary in sbin,
since we cannot be sure for any of its tools that it will never
ever be useful for non-root users. and systemd is as low-level,
system-specific it can get).
b) The original definition of /sbin is fully obsolete (i.e. the "s" in
sbin stood originally for "static" binaries)
c) /bin vs. /sbin is not about security, never has been. Doing this
would be security by obscurity, and pretty stupid, too.
d) splitting /bin off /sbin is purely and only relevant for $PATH, and
$PATH is purely and only something to ease access to the tools in it
for shell users. The emphasis here is on "ease". It is not a way to
make it harder for users to access some tools. Or in other words: if
your intention is to hide certain tools from the user in order not to
confuse him, then there are much better places for that: the
documentation could document them in a separate section or so. I
don't think it makes any sense at all trying to educate the user by
playing games with what he can see if he presses TAB in the shell. On
top of that users who use the shell are the ones who react allergic
to this kind of attempts of forced education anyway. So just drop
this nonsense.
e) the split between sbin/ and /bin is effectively made redundant already,
since both are listed in the $PATH of all users already since a
couple of Fedora versions. And due to d) the split hence has no
reason to exist, at all.
f) splitting things up complicates stuff. If you want to keep things
separate you really need a good reason for that. We should always
focus on simplifiying things. And merging things into /usr does just
that: it drastically simplifies the complexities we have collected
over 30+ years of Unix heritage.
g) given that some distros place certain binaries in other places than
others, merging the dirs has the big benefit that the four paths are
equivalent and scripts from other distros work on ours, regardless
where the other distros place their stuff
h) the split between /usr and / was mostly about early boot
initialization: i.e. a minimal system was available in / which was
just good enough to find the full OS stuff in /usr. But that hasn't
worked in ages, and the discussion for split off /usr is over and the
install option got removed from anaconda (though you can still
install things like that by hand if you really want to shoot yourself
in the foot)
http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
i) The separation between minimal boot system in / and full system in
/usr is obsoleted by initrd in a way: the new minimal boot system is
the initrd. Stacking multiple levels of "minimal boot system", one
after the other is a stupid game. So let's stick to the one we really
need which is initrd, and forget about the one that we don't need
anymore, and is broken since ages.
j) having all static, distribution-provided, sharable OS stuff in a single dir
in /usr simplifies read-only setups drastically. I think we should
ensure that having the OS itself read-only is something that works
right-away without having to enable special modes that do this which
involves a ton of less-than-beautiful hacks. Being able to make the
libc and other core libraries fully read-only without also having to
make /etc read-only and without having to add a junkload of r/o bind
mounts is highly desirable.
k) having all static, distro-specific, sharable OS in a single dir
makes snapshots of the OS independetly of its state and configuration
truly atomic. In a btrfs world doing 5 snapshots of /lib, /lib64,
/bin, /sbin and /usr instead of just one is not atomic, and hence
racy, and ugly, and boooh!
l) having a clear separation between sharable data
(i.e. /usr) and everything else is highly desirable for
network setups, and for container setups.
m) Upstream build scripts can be vastly simplified, since autoconf does not
know about the separation between / and /usr (and never did), and
getting autoconf right in the context of the split traditional is immensly
difficult, with the effect that almost nobody got it right. And we
have quite a few components who never even tried (i think Plymouth?)
n) Harald has done the work for testing and showed that merging the dirs
works, and that the path towards it is pretty clear and managable,
and that it creates no major issues on the way.
o) we have somebody who wants to do the work.
And that's all I could come up with for now. Putting this together I am
all in favour of this simplification. As a developer it would make
things a lot simpler for me. Packagers will have things much simpler
(after the transition) too, and finally administrators have the major
benefits of the atomicity of the btrfs snapshotting, and for network and
especially container setups. And those three are absolute killer
features in my eyes.
Lennart
--
Lennart Poettering - Red Hat, Inc.
More information about the devel
mailing list