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

[jim]

oh yeah: and also, make sure you can rebuild your 
OS system files quickly on demand. Maybe have the 
OS duplicated on a partition that's normally not 
mounted. 



On Fri, 2012-03-02 at 12:54 -0800, Jeff Bragg wrote:
> 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/
>         
> 
> _______________________________________________
> 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/