[sf-lug] What are the best practices for Linux partitioning & Mount points for Production systems

[Jeff Bragg]

For machines that will have actual user data (not just systems and
automation accounts), I like to use a separate /home partition; otherwise
it can just be a directory under /.

/var is where logs go, so there's a good argument for giving it its own
partition (because if you don't rotate the logs regularly it can end up
eating up all the available space, which is not serious if it's a separate
partition, but is if it's just a directory under /).

I don't have a strong opinion about /boot as a separate partition; in
theory, it's probably easier with a separate partition to recover from boot
issues, e.g. MBR corruption, but it's not something I've really had to
fight with in practice.

I leave /usr as a directory on the / partition.  Unless you expect it to be
very volatile (constantly installing new software via the package manager),
I can't really think of a good reason to do otherwise.

/opt is also popular, as a place to install software that isn't available
through the package manager.  If you expect to do that a lot, it may be
worth having a separate partition for it.

I can only offer the most general advice in terms of size of partitions, as
it depends quite a bit on what you plan to do with the machine, and the
size for each depends in part on overall arrangement.  Personally, I like
to make sure that / is at least 10 Gb, and possibly a good deal larger,
especially  if /home isn't a separate partition (and you expect to have
actual users).  If you have users, such as developers, using this machine,
I recommend a separate /home partition, and probably making it the largest
one (perhaps around half the overall disk size).  /var is generally fine at
only a few Gb (< 10).  /tmp should probably be similar to /var in terms of
size (and there are similar reasons for making it a separate partition,
depending on use case).  For /opt it depends on your use case; if you won't
be installing outside of the package manager, and won't be installing
custom software there, probably best to just leave it as a directory under
/.

In general, the more of this you leave as directories rather than
partitions, the larger / should be to accommodate.  In my view, there are
two main reasons to create a partition for these locations:  1) to protect
/ from filling up (and the machine falling over) due to user files,
unexpected log growth or unrotated logs, temporary data, etc, and 2) to
protect the contents of the partition from OS problems (e.g. protecting
user files from deletion in the event that you have to reinstall the OS, or
otherwise need to reformat /).

I hope that helps a bit.

On Fri, Mar 2, 2012 at 1:05 AM, nk oorda <nk.oorda at gmail.com> wrote:

>  Hi
>
> i need some suggestion for defining the partition size for my production
> systems.  we are going to use CentOS 6.2 (64 bit)
>
> - Partition size
> - Mount points
>
> What i am able to get from the google search is:
>
> /            Root File System (/bin , /sbin , /dev , /root
> /usr       program and source
> code
> /var        variable data
> /boot     boot kernels
> /tmp      temp file locations
> /work     to do your work here "you can name it anything"
> Swap
>
>    - */home* - Set option nosuid, and nodev with diskquota option
>    - */usr* - Set option nodev
>    - */tmp* - Set option nodev, nosuid, noexec option must be enabled
>    - /var   local,nodev,nosuid
>
>
> Most of the server will be running
> - Apache
> -Tomcat
> -SOLR
>
> and few of them would be running MySQL as data base.
>
>
> what is concern is that one of the developer accidentally deleted the /usr
> files with sudo access. if somehow i can protect the core system from the
> developers mistake that would be really good.
>
> Thanks in advance for help.
>
> --n
>
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
> Information about SF-LUG is at http://www.sf-lug.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linuxmafia.com/pipermail/sf-lug/attachments/20120302/5ffecfab/attachment.html>