Product SiteDocumentation Site

3.2. Partitioning the system

3.2.1. Elegir un esquema de particiones inteligente

Un esquema de particiones inteligente depende del uso que vaya a tener la máquina. Una buena regla general es ser bastante liberal con las particiones y prestar atención a los siguientes factores:
  • Any directory tree which a user has write permissions to, such as e.g. /home, /tmp and /var/tmp/, should be on a separate partition. This reduces the risk of a user DoS by filling up your "/" mount point and rendering the system unusable (Note: this is not strictly true, since there is always some space reserved for root which a normal user cannot fill), and it also prevents hardlink attacks. [2]
  • Any partition which can fluctuate, e.g. /var (especially /var/log) should also be on a separate partition. On a Debian system, you should create /var a little bit bigger than on other systems, because downloaded packages (the apt cache) are stored in /var/cache/apt/archives.
  • Cualquier partición en la que quiera instalar software que no pertenezca a la distribución debería estar aparte. De acuerdo con la jerarquía estándar de archivos, debería hacerse con /opt o /usr/local. Si éstos están en particiones separadas, no se borrarán en caso de tener que reinstalar Debian.
  • Desde el punto de vista de la seguridad, cobra sentido intentar mover los datos estáticos a su propia partición, y luego montar esa partición como de sólo lectura. O mejor todavía, poner los datos en un medio de sólo lectura. Mire m~s adelante si quiere m~s detalles.
In the case of a mail server it is important to have a separate partition for the mail spool. Remote users (either knowingly or unknowingly) can fill the mail spool (/var/mail and/or /var/spool/mail). If the spool is on a separate partition, this situation will not render the system unusable. Otherwise (if the spool directory is on the same partition as /var) the system might have important problems: log entries will not be created, packages cannot be installed, and some programs might even have problems starting up (if they use /var/run).
Also, for partitions in which you cannot be sure of the needed space, installing Logical Volume Manager (lvm-common and the needed binaries for your kernel, this might be either lvm10, lvm6, or lvm5). Using lvm, you can create volume groups that expand multiple physical volumes.

3.2.2. Selecting the appropriate file systems

During the system partitioning you also have to decide which file system you want to use. The default file system[3] selected in the Debian installation for Linux partitions is ext3, a journaling file system. It is recommended that you always use a journaling file system, such as ext3, reiserfs, jfs or xfs, to minimize the problems derived from a system crash in the following cases:
  • for laptops in all the file systems installed. That way if you run out of battery unexpectedly or the system freezes due to a hardware issue (such as X configuration which is somewhat common) you will be less likely to lose data during a hardware reboot.
  • for production systems which store large amounts of data (like mail servers, ftp servers, network file systems...) it is recommended on these partitions. That way, in the event of a system crash, the server will take less time to recover and check the file systems, and data loss will be less likely.
Leaving aside the performance issues regarding journalling file systems (since this can sometimes turn into a religious war), it is usually better to use the ext3 file system. The reason for this is that it is backwards compatible with ext2, so if there are any issues with the journalling you can disable it and still have a working file system. Also, if you need to recover the system with a bootdisk (or CD-ROM) you do not need a custom kernel. If the kernel is 2.4 or 2.6 ext3 support is already available, if it is a 2.2 kernel you will be able to boot the file system even if you lose journalling capabilities. If you are using other journalling file systems you will find that you might not be able to recover unless you have a 2.4 or 2.6 kernel with the needed modules built-in. If you are stuck with a 2.2 kernel on the rescue disk, it might be even more difficult to have it access reiserfs or xfs.
In any case, data integrity might be better under ext3 since it does file-data journalling while others do only meta-data journalling, see http://lwn.net/2001/0802/a/ext3-modes.php3.
Notice, however, that there are some partitions that might not benefit from using a journaling filesystem. For example, if you are using a separate partition for /tmp/ you might be better off using a standard ext2 filesystem as it will be cleaned up when the system boots.


[2] A very good example of this kind of attacks using /tmp is detailed in http://www.hackinglinuxexposed.com/articles/20031111.html and http://www.hackinglinuxexposed.com/articles/20031214.html (notice that the incident is Debian-related). It is basicly an attack in which a local user stashes away a vulnerable setuid application by making a hard link to it, effectively avoiding any updates (or removal) of the binary itself made by the system administrator. Dpkg was recently fixed to prevent this (see http://bugs.debian.org/225692) but other setuid binaries (not controlled by the package manager) are at risk if partitions are not setup correctly.
[3] Since Debian GNU/Linux 4.0, codename etch