[sf-lug] sf-lug.com. box questions, documentation, "rules of the road", policies, etc.

jim stockford jim at well.com
Fri Apr 27 11:55:47 PDT 2007


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
yes.
> * 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
http://sf-lug.com/wiki/doku.php?id=system: 
system_administration_rules_of_the_road_this_box

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  
Unix.
* 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.


> 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
>





More information about the sf-lug mailing list