Quoting John Morris (jmor...@beau.org): > Dunno, that one actually makes a lot of sense.
At minimum, it's definitely not something to get religious over, so nobody should be hyperventilating over it. > The original reason no longer applies, we should all agree on that > point, right? Sure. Rob Landley's historical recounting should be sufficient refutation of any claim that the /usr split was originally for well-thought-out and persistently important reasons. http://lists.busybox.net/pipermail/busybox/2010-December/074114.html > We don't NEED to install on a small volume and then mount > the large stuff on a different media, even when we install /usr on a > different filesystem it is almost always a partition on the same > physical device. Nope, we don't _need_ to. However, even in case of the rootfs and a separate /usr filesystem being on the same physical device, that doesn't mean there cannot be reasons for separate /usr that the local admin considers compelling. > The arguments they advance for snapshotting, using a read-only mount > or network share of pretty much the entire non-host specific portion > of the OS is a pretty good reason to pick putting everything down > /usr. Those goofballs talk about 'sharing the operating system over the network' and 'a read-only export of the vendor supplied OS to the network, which will contain almost the entire operating system resources' because they have absolutely no clue about security -- one of the several individually compelling reasons to be suspicious of their advice. And there's nothing about separate /usr that prevents use of lvcreate or similar snapshotting if you wish to use that: Their allegation to the contrary seems... unexplained. I might be missing something, so, if you know what they're referring to, I'd appreciate hearing what. > If you don't want to use an initrd, just avoid making /usr a mountpoint. Can certainly be done, but suppose you want the functional advantages of separate /usr? ;-> (Oh, you assumed there aren't any. Well, there's your problem, then.) Separate /usr is one of several measures I take to help guard against a variety of mishap. For one thing, it then becomes possible to give /usr custom mount options, including the one that makes it normally read-only.[1] (I have hooks to apt/dpkg to automatically remount as required for apt operations. See this Anthony Towns post for details: https://lists.debian.org/debian-devel/2001/11/msg00212.html ) The aims of my partitioning strategy include getting everything feasible off the root filesystem to keep it small and fairly static. This in general terms keeps it far less likely to suffer mishap that includes but is not limited to hitting 100% full or getting filesystem damage in various ways. The rootfs having this passive protection against most forms of damage means that crucial tools needed for recovery or restore operations _or_ filesytem repair of other filesystems are highly likely to be available without needing to resort to CD/DVD images, USB key drives, or PXE-booting a recovery image. That's not everything, but it's certainly a great deal more than nothing. As a point of possible tangential interest, I use custom mount options on several filesystems as a belt-and-suspenders security assist in some cases, and to gain small performance advantages in others: /usr nodev,ro /var/lib nodev /var noatime,nodev,nosuid /var/www nodev,nosuid What I mean by 'belt-and-suspenders security assist' is: Suppose some process is somehow caused to run that attempts to do system harm. Almost all such attack tools are automated and tend to be a bit brittle, and it's conceivable that disallowing special files ('nodev') in a file tree where they should never be present might cause the attack script to fail. Likewise nosuid in trees where there should never legitimately be an executable with the SUID property. The 'noatime' on /var is of course for performance. (As always, one must make sure nothing in that filesystem is going to need atime time-stamping. Anyway, I have no problem with the Freedesktop.org kiddies deciding that my sysadmin use-case doesn't exist or should be ignored, because I can work around their opinions and set my own local policy and practices. So, we both get to be happy. [1] This helps prevent accidental sysadmin-caused damage to the sytem trees. It's proverbial that the biggest threat to the typical Unix system is the root user. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng