User Tools

Site Tools


system:system_administration_rules_of_the_road_this_box

This is an old revision of the document!


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.

  • 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 SF-LUG and 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 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, dont's, 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 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:
    • change log - relatively selective high-level change log
    • file:/home/admlin/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.sf-lug.com/log.txt), so only items suitable for being that openly exposed should be placed there.
    • file:/home/admlin/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.

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:

policies history

system/system_administration_rules_of_the_road_this_box.1177880358.txt.bz2 · Last modified: 2007-04-29T20:59:18+0000 by 198.144.194.236