Notes - Revision history

Support at 01:39, 8 May 2017

2017-05-08T01:39:53Z

Support at 01:38, 8 May 2017

2017-05-08T01:38:44Z

Support: Created page with "Notes / Overview Documentation on this site The documents on this site comprise information compiled over the last 25 years or so by many many Admins. Alot of this follows c..."

2017-05-07T04:37:24Z

Created page with "Notes / Overview Documentation on this site The documents on this site comprise information compiled over the last 25 years or so by many many Admins. Alot of this follows c..."

New page

Notes / Overview

Documentation on this site

The documents on this site comprise information compiled over the last 25 years or so by many many Admins. Alot of this follows conventions of the companies we've worked for, and may or may not be the way you would do it, or the way you would want to do it. We will attempt to explain why and where you would want or wouldn't want to utilize some of these conventions.

All data on /home

Most of the documentation follows various companies convention of separating their code and processes from the OS by dumping everything on/under /home and keeping data/logs/etc. there. This is fine if that is the convention you wish to follow, however, this is difficult to deal with if you are running a secure env using SELinux. There are some advantages with keeping everything on /home, primarily it is easy to reinstall the OS and reformat/rebuild all OS partitions without touching /home and keeping all your code/data/logs/etc. intact. One other primary reason to keep OS and application separate by using /home, when application logs fill up /tmp or /var, you don't crash the OS when it no longer has space left for temp files, or losing OS logs when there's no space left to record issues the OS is having when things go awry.

Whether you choose to keep app and OS separate and run your non-OS specifics from /home is up to you, if you don't (or if you are running SELinux), please ignore and DO NOT do the steps for moving items to home. For example, and using mySQL as a case in point, ignore the commands to move it off of /var;<br>
mv /var/lib/mysql /home/ ; ln -s /home/mysql /var/lib/

Conventions

Many examples show commands typed at a prompt. The convention is something like;<br>
# commandtodosomething
This is not a comment, please don't include the # if copying/pasting from one of these documents. Also, note that the normal prompt as a non-priveledged user is $ and the normal prompt when root is # however the convention here is to use # for all prompts so please ignore the fact that the # prompt in the documents are also shown for a non-root user AND/OR don't assume that since the prompt is # that it means the command is typed in as root.

@@ Line 24: / Line 24: @@
 All data on /home
-Most of the documentation follows various companies convention of separating their code and processes from the OS by dumping everything on/under /home and keeping data/logs/etc. there. This is fine if that is the convention you wish to follow, however, this is difficult to deal with if you are running a secure env using SELinux. There are some advantages with keeping everything on /home, primarily it is easy to reinstall the OS and reformat/rebuild all OS partitions without touching /home and keeping all your code/data/logs/etc. intact. One other primary reason to keep OS and application separate by using /home, when application logs fill up /tmp or /var, you don't crash the OS when it no longer has space left for temp files, or losing OS logs when there's no space left to record issues the OS is having when things go awry.
+Most of the documentation follows various companies convention of separating their code and processes from the OS by dumping everything on/under /home and keeping data/logs/etc. there. This is fine if that is the convention you wish to follow, however, this is difficult to deal with if you are running a secure env using SELinux. There are some advantages with keeping everything on /home, primarily it is easy to reinstall the OS and reformat/rebuild all OS partitions without touching /home and keeping all your code/data/logs/etc. intact. One other primary reason to keep OS and application separate by using /home, when application logs fill up /tmp or /var, you don't crash the OS when it no longer has space left for temp files, or losing OS logs when there's no space left to record issues the OS is having when things go awry with the application.
 Whether you choose to keep app and OS separate and run your non-OS specifics from /home is up to you, if you don't (or if you are running SELinux), please ignore and DO NOT do the steps for moving items to home. For example, and using mySQL as a case in point, ignore the commands to move it off of /var;<br>
   mv /var/lib/mysql /home/ ; ln -s /home/mysql /var/lib/

@@ Line 1: / Line 1: @@
 Notes / Overview
 Documentation on this site
@@ Line 5: / Line 6: @@
 The documents on this site comprise information compiled over the last 25 years or so by many many Admins. Alot of this follows conventions of the companies we've worked for, and may or may not be the way you would do it, or the way you would want to do it. We will attempt to explain why and where you would want or wouldn't want to utilize some of these conventions.
-Most of the documentation follows various companies convention of separating their code and processes from the OS by dumping everything on/under /home and keeping data/logs/etc. there. This is fine if that is the convention you wish to follow, however, this is difficult to deal with if you are running a secure env using SELinux. There are some advantages with keeping everything on /home, primarily it is easy to reinstall the OS and reformat/rebuild all OS partitions without touching /home and keeping all your code/data/logs/etc. intact. One other primary reason to keep OS and application separate by using /home, when application logs fill up /tmp or /var, you don't crash the OS when it no longer has space left for temp files, or losing OS logs when there's no space left to record issues the OS is having when things go awry.
+Linux Distros
 Conventions
@@ Line 17: / Line 20: @@
   # commandtodosomething
 This is not a comment, please don't include the # if copying/pasting from one of these documents. Also, note that the normal prompt as a non-priveledged user is $ and the normal prompt when root is # however the convention here is to use # for all prompts so please ignore the fact that the # prompt in the documents are also shown for a non-root user AND/OR don't assume that since the prompt is # that it means the command is typed in as root.