Recommended Partitioning Debian7 Web Server

8,356

Solution 1

I can't believe people are still arguing the toss over partitioning.

You have 3 sane choices.

1) Automatic Partitioning. Allow the OS to choose the best way to configure the disk. Works for me 99% of the time.

2) Complicated partitioning. Do whatever you like with hard primary/extended partitions. Your above schema might work, but you end up with the common problem where you've got huge amounts of allocated, but wasted space under /home, and /usr is running out of space.

3) LVM Partitioning. It's awesome, but takes a little while to understand. You allocate your disks as Physical Volumes (PVs), bundle the Physical Volumes into Volume Groups (VGs) , and carve out Logical Volumes (LVs) out of that.
Once you've got a Logical Volume, you can format it how you like, mount it where you want, and more importantly, resize or shrink it.

I'd probably be tempted to do some kind of hybrid as follows:

/dev/sda1    500MB    /boot
/dev/sda2    REST OF DISK    LVM

so you've got /boot actually on the physical disk, first partition, and the bootloader on the MBR. This can be helpful for older GRUBs or LILOs where the bootloader might not be aware of LVM.

-- The thing is, you can do some interesting stuff if you combine Software RAID (mdraid) with LVM.

Imagine you have 4 disks of 1TB each.

/dev/sda
/dev/sdb
/dev/sdc
/dev/sdd

I'd probably be tempted to partition as follows.

/dev/sd[a-d]1    RAID Member    0.5% total space
/dev/sd[a-d]2    RAID Member    99.5% total space

Then form 2 raid sets,

/dev/md0 is RAID 1, of /dev/sd[a-d]1, giving a 5GB RAID 1 array /dev/md1 is RAID 6, of /dev/sd[a-d]2, giving a 1.9TB RAID 6 array.

Then mount /dev/md0 as /boot (lots of protection for that), and then /dev/md1 becomes your first PV for your first VG, and you can chunk it up with LVM.

Solution 2

The following gives a good explanation:

http://www.debian.org/doc/manuals/securing-debian-howto/ch3.en.html#s3.2

An intelligent partition scheme depends on how the machine is used. A good rule of thumb is to be fairly liberal with your partitions and to pay attention to the following factors:

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.

Any partition where you want to install non-distribution software should be on a separate partition. According to the File Hierarchy Standard, this is /opt or /usr/local. If these are separate partitions, they will not be erased if you (have to) reinstall Debian itself.

From a security point of view, it makes sense to try to move static data to its own partition, and then mount that partition read-only. Better yet, put the data on read-only media. See below for more details.

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).

Basically what it comes down to is that you don't want log files in /var, temp files in /tmp, or a user making mess, to fill up the disk(s) rendering the system unusable. So you need to separate filesystem destinations in partitions.

Personally I would avoid lvm unless it's useful when creating encrypted partitions or software raids, although that also works without lvm. However others do like it.

In practice, when I have the choice I set up servers more or less as described below (order matters little):

/boot  should be small, about 1 GB
/       should be small as well, a few GB, you could combine / and /boot
swap  
/usr    reasonably large, 20 GB or more
/var    not too small either, 10+ GB?
/opt 
/tmp 
/home   I always use the remainder of the disk for that (which is most disk space)

If it's a desktop you could simplify it to something like this:

/boot
/
swap
/home
Share:
8,356

Related videos on Youtube

Admin
Author by

Admin

Updated on September 18, 2022

Comments

  • Admin
    Admin almost 2 years

    I am web developper and now I am running a VPS. I always work on my own machine, I have handled various Linux distributions but never a production server.

    I have created a VPS with 1Gb RAM and 100Gb hard drive to start (if needed they can be enlarged in blocks of 100GB). On this server I will install five applications developed in Symfony2 (PHP) . Less than 1Gb everything, but can grow depending on the videos / photos users upload. It is for internal company use.

    Right. I´ll install the LAMP in Debian7, but What do you think that is a good partition distribution? Something like that would be fine? / (Root) 5Gb / (Swap) 2Gb / tmp 5Gb / home 5Gb / var the rest

    I have another server where all virtual host are hosted on /home but I know that in Debian they are hosted on /var/www is that the reason to assign the rest of the disk

    One more thing, do I install the graphical environment? being beginner I like the idea of having something to connect with windows but I manage quite well via ssh.

    Thank you very much in advance

    P.D. Sorry for my poor english.

    • Zoredache
      Zoredache about 11 years
    • Zoredache
      Zoredache about 11 years
      My opinion, setup LVM. Create your swap. Setup a smallish root partition. Then leave yourself lots of unallocated space in the volume group. Create LVs, or expand LVs as needed.