User Tools

Site Tools


system:system_administration_rules_of_the_road_this_box

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
system:system_administration_rules_of_the_road_this_box [2015-11-25T10:36:30+0000]
michael_paoli
system:system_administration_rules_of_the_road_this_box [2018-09-03T04:13:22+0000] (current)
michael_paoli updated information on log file locations and URL
Line 1: Line 1:
 +====system administration policies / "rules of the road" (this box)====
 +To the extent feasible, **system administration policies applicable
 +to this "​box"​ (host/​system) are to be documented here**.
  
 +Note that **occasionally there will be some items more appropriately
 +documented elsewhere**. ​ E.g. security sensitive information that
 +shouldn'​t be openly readable to the Internet, or items that may be
 +important to have access to when the wiki isn't available (e.g. critical
 +maintenance related information).
 +In general, **items which shouldn'​t be documented here** on this wiki **but
 +should be documented in local files under
 +file:/​home/​admin/​** - or at least referenced from there.
 +
 +To the extent feasible, **this document should cover current policy**,
 +"rules of the road", etc.  To the extent it's covered, historical, ​
 +outdated, superseded, etc.
 +information should be covered separately (and to the extent feasible,
 +presented in a manner unlikely to cause confusion with current policy
 +and "rules of the road", etc.)
 +
 +===objectives===
 +There are **multiple objectives for this system**. ​ At least at times,
 +these **may appear to conflict**. ​ This list is intended to identify
 +key objectives, and in the case of conflict or potential conflicts,
 +their priority (or at least approximate priority), with highest priority
 +(most important) first.
 +Also, first, bit of "​policy"​ update ... but may be more theoretical (e.g. conflicts with physical
 +reality & resources available at the time of this writing) - and may also, to fair extent, be relatively SF-LUG specific:
 +<​file>​
 +Date: Tue, 24 Nov 2015 22:10:12 +0000
 +From: jim <​jim@well.com>​
 +
 +Policies:
 +* The host of the sf-lug web site is a Linux machine or virtual machine
 +  dedicated to running the sf-lug web site only. A "​different host" may
 +  refer to another VM running on the same physical host as that which
 +  supports the sf-lug web site.
 +* the sf-lug web site itself should be static, with no interactive
 +  software, for ease of maintenance and security; it is essentially an
 +  internet-accessible yellow page style advertisement.
 +* The sf-lug web site can include links to interactive web pages,
 +  although properly such interactive pages should be hosted on some
 +  different host other than that which hosts the sf-lug web site (for
 +  easy maintenance and security).
 +* the sf-lug web site host should be open to sf-lug supporters for
 +  whatever they want to try out. "Trust is efficient."​ We assume no user
 +  will alter work done by other users. We assume users will make mistakes,
 +  even hork the host itself, and that users will use sudo rather than
 +  the root account to make changes (exceptions to this include Michael
 +  Paoli and Jim Stockford and whoever else can get Jim or Michael to
 +  approve). Preferably users should experiment on a host other than that
 +  which runs the sf-lug web site itself.
 +* Jim wishes to deprecate PHP on the host that supports the sf-lug web
 +  site. Jim has no power to enforce this. Jim prefers shell scripts, C,
 +  and Python. Jim's authority derives from his paying for domain name,
 +  electrical power, bandwidth, and other costs. To the extent that
 +  other people pay such costs, they derive authority.
 +</​file>​
 +  ***High availability server** - to the extent feasible, this system should be treated as a server intended to be of rather to quite high availability. ​ E.g. groups (such as [[http://​www.sf-lug.org/​|SF-LUG]] and [[http://​www.balug.org/​|BALUG]]) are or may be rather to quite dependent upon its availability,​ and generally would prefer the system be up and available as much as feasible.
 +    ***Downtime and maintenance (system outages)** - to the extent feasible, when such outages are necessary or appropriate,​ they should be targeted to off-peak hours (usage logs may provide useful guidelines as to what days/times would best meet "​off-peak"​ criteria), and should be scheduled in advance and with [[system:​appropriate outage notification]].
 +  *support command-line activities of users
 +  *provide an educational playground for users who want to explore using LINUX
 +  *support web pages for users
 +  *support web pages and activities of a Red Hat Certification study group
 +  *support web pages and activities of users learning the Python programming language
 +  *support other open-source focussed community groups
 +===dos, don'​ts,​ and how tos===
 +  ***significant changes to policy, use of system**, concerns/​questions,​ etc. - such issues (at least presently) should generally be discussed to "​resolution"​ on the [[http://​linuxmafia.com/​mailman/​listinfo/​sf-lug|SF-LUG list]]
 +  ***avoiding configuration/​usage conflict** - to the extent feasible, items should be appropriately identified and/or located, as applicable, to avoid conflicts and confusion. ​ E.g. for usages which may not be absolutely primary to the box (e.g. BALUG) configurations should be clearly identified (e.g. /​etc/​named-balug.conf,​ /​etc/​init.d/​named-balug) and/or in appropriate areas (e.g. /​home/​balug).
 +  ***logging** - things/​events/​changes should be suitably and appropriately logged, and in appropriate location(s). ​ This is not only generally considered "best practice",​ but it is particularly important when multiple persons are involved (e.g. with systems administration) on a host - such as the case with this host.  There is not only the logging done by software itself (and via its configuration),​ but also appropriate (mostly) human generated log entries and/or details. ​ Exactly how, where, and what, should be logged, may "​evolve"​ over time (and with discussion and seeing what does/​doesn'​t work so well for different stuff). ​ At present, there are at least these, and their apparent current usage:
 +    ***[[system:​change log]]** - relatively selective high-level change log
 +    ***file:/​var/​local/​log/​log** ​ - (up to) rather detailed chronological logging potentially including anything that might be worthy of noting/​recording. ​ It's also readable by anyone via the Internet (accessible as [[http://​www.archive.balug.com/​log.txt]]),​ so only items suitable for being that openly exposed should be placed there.
 +    ***file:/​var/​local/​log/​log.secure** - similar to the above, for items that should have quite minimal exposure (limited to local superuser (UID 0, a.k.a. "​root"​) access.
 +  ***documenting**/​**documentation** - as feasible and appropriate,​ things should be documented (and/or logged). ​ This is particularly noteworthy/​important given both the number of folks that do or may work on this system, and also many of the objectives of the system (e.g. learning/​teaching).
 +  ***IP addresses**:​ see: **[[system:​ip_addresses|IP addresses]]**
 +  ***BALUG webserver**:​ see: **[[BALUG webserver]]**
 +  ***BALUG DNS server**: see: **[[BALUG DNS]]**
 +
 +===Code of Ethics===
 +Access to and use of the system should follow appropriate code of ethics, e.g.
 +the LOPSA/​SAGE/​USENIX code of ethics:
 +  *[[http://​www.sage.org/​ethics/​ethics.html|the LOPSA/​SAGE/​USENIX Code of Ethics]] [[http://​www.usenix.org/​|(USENIX]]/​[[http://​www.sage.org/​|SAGE)]]
 +  *[[http://​lopsa.org/​CodeOfEthics|the LOPSA/​SAGE/​USENIX Code of Ethics]] [[http://​lopsa.org/​|(LOPSA)]]
 +
 +===policies history===
 +[[system:​policies history]]
system/system_administration_rules_of_the_road_this_box.txt ยท Last modified: 2018-09-03T04:13:22+0000 by michael_paoli