User Tools

Site Tools



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

Link to this comparison view

Next revision
Previous revision
system:system_administration_rules_of_the_road_this_box [2007-04-24T04:56:16+0000] created
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 the extent feasible, **system administration policies applicable
-to this "​box"​ (host) are to be documented here**.+to this "​box"​ (host/system) are to be documented here**.
 Note that **occasionally there will be some items more appropriately Note that **occasionally there will be some items more appropriately
Line 7: Line 8:
 important to have access to when the wiki isn't available (e.g. critical important to have access to when the wiki isn't available (e.g. critical
 maintenance related information). maintenance related information).
 In general, **items which shouldn'​t be documented here** on this wiki **but In general, **items which shouldn'​t be documented here** on this wiki **but
-should be documented in local files should be documented ​under+should be documented in local files under
 file:/​home/​admin/​** - or at least referenced from there. file:/​home/​admin/​** - or at least referenced from there.
Line 18: Line 18:
 presented in a manner unlikely to cause confusion with current policy presented in a manner unlikely to cause confusion with current policy
 and "rules of the road", etc.) and "rules of the road", etc.)
 +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:
 +Date: Tue, 24 Nov 2015 22:10:12 +0000
 +From: jim <​>​
 +* 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.
 +  ***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://​​|SF-LUG]] and [[http://​​|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://​​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://​​log.txt]]),​ so only items suitable for being that openly exposed should be placed there.
 +    ***file:/​var/​local/​log/​** - 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://​​ethics/​ethics.html|the LOPSA/​SAGE/​USENIX Code of Ethics]] [[http://​​|(USENIX]]/​[[http://​​|SAGE)]]
 +  *[[http://​​CodeOfEthics|the LOPSA/​SAGE/​USENIX Code of Ethics]] [[http://​​|(LOPSA)]]
 +===policies history===
 +[[system:​policies history]]
system/system_administration_rules_of_the_road_this_box.1177390576.txt.bz2 ยท Last modified: 2007-04-24T04:56:16+0000 by