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