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

[Jeff Bragg]

As Jim mentions, sudo fine-tuning is important, if you have a lot of
sudo-enabled users.  Frankly, I advocate starting by removing privileges,
and then adding them back in explicitly as users indicate a need for them
(that is, when the devs scream at you because they were prevented from
doing X).  This approach will be initially painful, to be sure, but it
ensures that you are only elevating privileges that actually need to be
elevated.  Furthermore, a dev who deletes the contents of /usr
(accidentally or otherwise) without one hell of a justification should, in
my view, be put on probation, in terms of OS privileges, as that sort of
action can screw things up for an entire team (and then you have a whole
bunch of devs, etc screaming at you).  On their own machine, give devs
privileges as broad as they want, but on shared machines doing so is
inviting disaster, IMO.

On Fri, Mar 2, 2012 at 12:11 PM, jim <jim at well.com> wrote:

>
>
> >From your description it seems there are three considerations:
> 1 training (or maybe hiring policies): it's possible
>  for experienced and competent engineers to delete
>  all of /usr/ but rare. My guess is the person who
>  did so was not familiar with Unix-like systems.
> 2 sudo fine-tuning: despite widespread information
>  about best or good or other practices, systems are
>  often installed and configured the fastest way
>  possible. In this case, perhaps all sudoers have
>  root privileges. If so, consider setting up some
>  sudoers to have permissions for one or more groups
>  so that they don't have total destruction powers.
> 3 mounting: consider mounting most partitions in
>  read-only mode. This makes updating and upgrading
>  a bit more painful, but think of that as good:
>  the extra hurdle may remind upgraders to be
>  mindful of various considerations.
>    I like choices 1 and 2 a lot.
>
>    I don't see how the issue of partition sizing
> relates to the problem you described. As to sizing,
> seems to me the main consideration these days is
> copying (mainly backups). Another is that you have
> some requirement for different types of filesystems.
>    Most system files are just as well stored on
> the partition that has the root filesystem. The
> exception might be /var/ if there's a lot of
> activity or the possibility of log file overflow.
>    If the host allows only a few users shell access,
> it may or may not be smart to put /home/ on a
> separate partition (if your developers are using
> a version-control repo, maybe they have little or
> no data to store on their /home/ directories on
> this host).
>    The /opt/ and /srv/ directory names are used
> for special (usually big) application software.
> Consider making a /data/ directory or some such.
> In the case that a top-level directory stores
> "variable" data, it's probably good (or "best")
> that it's on a separate partition.
>
>
> On Fri, 2012-03-02 at 14:35 +0530, nk oorda 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/
>
>
>
> _______________________________________________
> 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/c923d846/attachment.html>