[sf-lug] sf-lug.com. box questions, documentation, "rules of the road", policies, etc.
aldenm at gmail.com
Fri Apr 27 13:16:33 PDT 2007
Ever hear of ITIL? Maybe we can use that standard to base the "rules of the
road"? Just a thought.
On 4/27/07, jim stockford <jim at well.com> wrote:
> my tho'ts interspersed within:
> On Apr 25, 2007, at 7:39 AM, Michael Paoli wrote:
> > sf-lug.com. box questions, documentation, "rules of the road",
> > policies, etc.
> > Still documenting more, but a few questions along the way ...
> > appropriate outage notification and out-of-band status page?
> > We earlier discussed outages, planned outages, etc.
> > Even have a place to document that further
> > (http://sf-lug.com/wiki/doku.php?id=system:
> > appropriate_outage_notification
> > on
> > http://sf-lug.com/wiki/doku.php?id=system:
> > system_administration_rules_of_the_road_this_box).
> > Two particular items/questions occurred to me regarding that.
> > First of all, for planned outages, *who* do we want to notify,
> jim at well.com
> # nathan and michael may wish to add their names to this list
> > and *how* do we want to notify them?
> email seems best.
> > Might that also depend on
> > circumstances, nature of outage (whole box down, or just some
> > important service(s)), duration and timing?
> Anything that seems amiss, no need to classify at this point.
> > Would we want to:
> > * do a wall on the system
> probably not necessary.
> > * edit /etc/motd and/or /etc/issue
> yes in the case of on-going fixes and updates.
> > * e-mail the "pagermonkeys" on the box
> > * e-mail the sf-lug list
> probably not.
> > * and/or other?
> > and do we want to come up with "rules" (/guidelines) on what method(s)
> > should be used under what circumstances?
> the above seems sufficient to me.
> > Also out-of-band status page? It would be potentially very useful to
> > have some out-of-band (independent of that box, and preferably also
> > independent of that colo) status/notification page. E.g. it can be
> > highly useful to have an independent web page (could just be a wiki web
> > page somewhere) that indicates some status information (most notably
> > if/when any unexpected outage occurs - to indicate status and
> > estimate/guestimate on return to service, but also a place for folks to
> > look during scheduled outages - such as if they didn't know in advance
> > about the outage). E.g. rather like:
> > out-of-band status page:
> > http://lambdamoo.blogspot.com/
> > for status of:
> > telnet://lambda.moo.mud.org.:8888
> i suggest sf-lug.org which is hosted by circlesoft.com
> I am struggling to figure out whether I want an internet
> presence coming out of my home, way out at the beach
> fed by corroded overloaded telephone wires and no
> possible higher speed than lowest DSL. If I decide so,
> that would be an additional external resource.
> > Hardware documentation?
> > Although it's possible to use standard LINUX/CentOS tools to get some
> > information on the hardware (e.g. CPU, disk sizes, some bits of
> > chipset information here and there), could someone document the
> > hardware details - e.g. make and model of the system, any particular
> > details of hardware/options installed, etc. Having such information
> > known (and documented!) could come in rather to quite handy in
> > troubleshooting any items that may be hardware related, planning
> > certain optimizations and potential upgrades, etc. If someone is
> > able to at least provide the basic hardware information, we could
> > probably get that up on a wiki page, including hunting down relevant
> > reference information (e.g. links to more detailed hardware
> > specifications for particular make/model of items identified).
> i volunteer to do this given that I own the box. I'll have
> to go down there. Anybody want to come visit the box
> in its colo environment?
> > More documentation/log stuff ...
> > I started two log files on the box - feel free to have a look at
> > the /home/admin/log* files (most notably /home/admin/log). The
> > general idea there is human readable
> > (and fairly searchable by date, or other criteria) log of system
> > changes
> > made, issues/bugs noted/corrected, etc. Most notably the idea here is
> > to keep lots of less details regarding such off of and from
> > piling up ad nauseum on wiki pages (could eventually get quite long),
> > and it's also often much easier to drop information straight into flat
> > file or copy/paste from such, and not have to worry about wiki
> > formatting goop and how to get something to render as plain text.
> strong agreement. Permissions for /home/admin currently are
> 755 for root owner, root group, unwashed. Ergo only root can
> make changes, all can read. Is that best?
> What about an admin group such that permissions are
> 775 root owner, admin group, unwashed. This allows a
> group of administrators that may not have su - privileges.
> Current permissions assume administrators su - (which is
> okay by me, just bringing it up).
> > The wiki pages are probably much more suitable for more general
> > documentation (e.g. policies, how-to, etc.) - such as things likely to
> > be revised over time (as opposed to continually appended to and not as
> > likely to be of more general interest).
> seems right. For
> I suggest revising the existing wiki text bullet points under
> the Objectives section to be
> * support command-line activities of users.
> * provide an educational playground for users who want to explore using
> * support web pages for users.
> * support web pages and activities of a Red Hat Certification study
> * support web pages and activities of users learning the Python
> programming language.
> * support other open-source focussed community groups.
> > For a bit more of an idea,
> > have a look at /home/admin/log - it's already up to 82 lines - and
> > that's just covering a bit of usage/syntax, and noting and dealing with
> > a few minor issues. As I noted, such can get quite long (e.g. on my
> > two
> > home systems, the equivalent file I maintain on each have grown to be
> > in excess of 10,000 lines long (not that we have to be *that* detailed
> > on the sf-lug.com. box - on my home systems, I log, for example, all
> > package additions/removals/upgrades - including package version
> > information, bugs and hardware issues/problems encountered, hardware
> > changes, etc.; capturing/noting at least more noteworthy changes/issues
> > for the sf-lug.com. box would probably be a good thing.)).
> I think /home/admin/log* files are outstanding!
> I hope the administrators will follow the style.
> > Code of ethics? Should we add to the "rules of the road" / policy
> > something indicating an appropriate code of ethics? The more
> > experienced systems administrators likely think such would be quite
> > applicable anyway, but, most notably for those that may be much newer
> > to
> > the field, explicitly noting, or at least referencing such, would help
> > call attention to such, introduce such to those not already familiar
> > with such, and help develop and foster appropriate professionalism.
> > E.g. could add something roughly like:
> > "
> > Users of the system, and most notably systems administrators and any
> > other persons with any type of privileged access to the system, should
> > exercise appropriate professionalism and follow appropriate code of
> > ethics,
> > e.g. the LOPSA/SAGE/USENIX code of ethics:
> > http://www.sage.org/ethics/ethics.html
> > http://lopsa.org/CodeOfEthics
> > "
> don't like the word "professional*". How about
> "...access to the system should follow the code of ethics described in:
> " <http sources follow>
> > Quoting Michael Paoli:
> >> Just a bit of a start (I plan to add more), but I put some of the
> >> information on the wiki. Feel free to correct anything that's
> >> incorrect,
> >> improve formatting/presentation, etc.
> >> http://sf-lug.com/wiki/doku.php
> > http://sf-lug.com/wiki/doku.php?id=system:
> > system_administration_rules_of_the_road_this_box
> >> file://sf-lug.com/home/admin/
> > _______________________________________________
> > sf-lug mailing list
> > sf-lug at linuxmafia.com
> > http://linuxmafia.com/mailman/listinfo/sf-lug
> sf-lug mailing list
> sf-lug at linuxmafia.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the sf-lug