[sf-lug] sf-lug.com. box questions, documentation, "rules of the road", policies, etc.
jim at well.com
Fri Apr 27 16:22:34 PDT 2007
No, not until now, and thanks. It's big.
Seems a good point of reference.
On Apr 27, 2007, at 1:16 PM, Alden Meneses wrote:
> 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
>> > should be used under what circumstances?
>> the above seems sufficient to me.
>> > Also out-of-band status page? It would be potentially very useful
>> > 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
>> > 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
>> > 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
>> > 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
>> > to keep lots of less details regarding such off of and from
>> > piling up ad nauseum on wiki pages (could eventually get quite
>> > and it's also often much easier to drop information straight into
>> > 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
>> > be revised over time (as opposed to continually appended to and not
>> > 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
>> * 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
>> > a few minor issues. As I noted, such can get quite long ( e.g. on
>> > two
>> > home systems, the equivalent file I maintain on each have grown to
>> > in excess of 10,000 lines long (not that we have to be *that*
>> > 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
>> > 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
>> > to
>> > the field, explicitly noting, or at least referencing such, would
>> > 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,
>> > 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
>> " <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
> sf-lug mailing list
> sf-lug at linuxmafia.com
More information about the sf-lug