:: Re: [DNG] /usr to merge or not to m…
Página Inicial
Delete this message
Reply to this message
Autor: Didier Kryn
Data:  
Para: dng
Assunto: Re: [DNG] /usr to merge or not to merge... that is the question
Le 28/11/2018 à 10:35, Rick Moen a écrit :
> Quoting Didier Kryn (kryn@???):
>
>>     Files are stored in different directories, that's it for
>> clean bookkeeping. Making these directories mountpoint does not add
>> any sort of ordering. Only the impression they are more secure.
> Here's a real-world example of ordering using filesystem divisions.
> Let's assume a system using spinning rust -- a jocular term for hard
> drives, where 'seeking', the process of moving heads between cylinders,
> is by orders of magnitude the slowest read or write operation, as
> opposed to SSDs, where the concept of 'seeking' doesn't even apply, and
> all sectors are equally reachable in the same ultra-quick amount of
> time, with no seek delay ever.
>
> Ordering the file trees to minimise average seek distance and time
> will thus both speed disk access and reduce wear.
>
> Based on a lot of experimenting by me and others, and occasional but
> seldom systematic measurement, a _reasonable_ general scheme for each
> spindle is as follows:
>
> Near the middle of the set of cylinders, you put the spindle's swap
> partition. On _either_ side of the swap, you put a filessytem tree that
> has a high percentage of the system's reads and/or writes_. /var is
> one obvious candidate. Others might depend on the role of the machine,
> e.g., I tend to have a Web server's public HTML root mounted as /var/www
> (as I disagree with recent FHS releases about /srv for this), so it
> might go on the other side of the swap. And then, proceeding both
> inwards and outwards through the cylinders, other file trees with less
> and less average activity. If you have more than one spindle
> (unmirrored), then put likewise a swap partition in the middle, and
> festoon trees on either side following the same logic.
>
> About the 'impression that they are more secure', the problem with the
> word 'secure' in this context is that two speakers will often use it
> with entirely different referents in mind.
>
> For example, I might outline for you a partition scheme where /usr is
> ext2 and mounted read-only except during package operations and has the
> nodev mount option set, /var/lib is mounted nodev, /var/www is mounted
> nodev,nosuid, and /, /home /var/spool, and /usr/local have default mount
> options -- and your reaction was this gives only the _impression_ of being
> more secure, because a system intruder who cracks root can remount
> anything as desired to overcome such pitiful obstacles.
>
> But that assumes that 'secure' is intended to mean 'defeats remote
> intruders who steal shell and then successfully escalate to system
> privilege' -- whereas by 'secure' I might mean, in this context,
> something much more modest yet pragmatically useful: The biggest
> security threat to any *ix system is a tired and error-prone sysadmin
> working at a shell prompt. Anything that makes common blunders less
> disastrous without excessive cost is a win, e.g., /usr being normally
> mounted read-only averting disaster from an admin recklessly carries out
> a command with system authority that crosses into /usr without he/she
> intending to. Almost as threatening to systems is misbehaving regular
> software. Anything that makes processes going haywire less able to do
> harm without excessive cost is likewise A Good Thing. Last, although
> it's certainly true that a competent human intruder able to break in and
> escalate to root can trivially remount filesystems, most system attacks
> and privilege escalation are carried out by fully automated scripts,
> and, if they fail because they rely on writing to /usr, it's very likely
> they will _not_ be written to debug the problem as mount options and
> do a remount and try again.
>
> As usual, words are the problem. Maybe we should switch to interpretive
> dance. ;->
>

    Hi Rick.

    It seems to me you're fighting to get the last bit of performance
out of mechanical hard drives, including by using different filesystems
for different partitions, which makes a lot of sense for servers. I
agree that filesystem play a major role in performance and safety. For
the performance of the disks, and considering you speak of servers, you
ommit to speak of the RAID configuration, which seems to me more
important than the location of the partitions.

    For what concerns, laptops, I think we are in the era of ssd and,
unfortunately, there is usually only one disk drive per laptop, except
of older ones where the cdrom drive can be replaced by a disk.

    Today, servers are probably still the domain of RAIDs based on
mechanical hard drives, laptops, the domain of ssds, and desktops are
the place where both live together - I have one desktop like this.

        Didier