On Sun, 2 Nov 2003 10:59:16 +0000 (UTC) Marco Cecconi <[EMAIL PROTECTED]> wrote:
MC> Hello, I've been having this question on my mind for a bit now: what MC> is the best practice to partition a hard drive under Unix, and in MC> particular under Linux? At work I try to separate different MC> functionalities as much as possible (eg. /boot, /, /var, /home all MC> on different partitions). This makes sense since the machines are MC> servers. What is your experience regarding workstations? Is there MC> any advantage or disadvantage in using a simpler partitioning (eg. MC> only /boot and /)? Ok, so most people agrees that you must mount in its own partition any directory that can grow wild, becouse: 1.- That way you protect the root partition from running out of space, if the users suddenly get the urge to fill its accounts with mp3 (/home), or a rogue program creates the biggest tmp file in history (/tmp), or you get unusual activity and your logs grow exponentially (/var). 2.- On a system upgrade/reinstall all of your data will be in its own partition, and you can safely do wathever you want to root. But there is also another view that I have not seen mentioned: in serious servers, you can also "freeze" the most static parts of your system, namely /bin, /sbin and /usr. This means mounting them read-only. Why? 'Couse: 1.- This way you can use ext2, since journaling is not needed, and that would give a boost on performance, while keeping such partitions completely safe from blackouts and the such. And... 2.- It makes dificult for a newbie/intruder to mess with the system. There is some kernel patch or something (I don't recall right now) that would not let mounting some partitions with write perm unless you do a reboot and authentify yourself with a password. Now, if you still want to occasionally install software without the reboot, you can give /usr/local its own partition and write there. This diminishes security a little, but you are still keeping safe "login" and "ps". I think its a great way to secure a crucial server. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
