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

[Michael Paoli]

Okay :-) ... my comments mixed in below, ...

substantially snipped, more full earlier text (to which this is a reply)
available at:
http://linuxmafia.com/pipermail/sf-lug/2007q2/001454.html

Quoting jim stockford <jim at well.com>:

> On Apr 25, 2007, at 7:39 AM, Michael Paoli wrote:
> > appropriate outage notification and out-of-band status page?
Okay, thus far now have at least:
http://sf-lug.com/wiki/doku.php?id=system:appropriate_outage_notification
based upon summary of what we seem to have come up with thus far.

And random subsequent thought on out-of-band status pages.  Could also
set up such a page on sf-lug.com. for status of sf-lug.org., and
vice versa - could make for a fairly elegant symetry.

> > Hardware documentation?
> 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?
At the 2007-04-16 SF-LUG meeting, there was discussion of potentially
arranging to do this on a Monday evening when SF-LUG doesn't meet.
Want to just pick a suitable day that's a week or more out?  I'd be
interested in having a look (or at least otherwise covering various
hardware and colo questions), I'd think probably at least some of the
sysadmins and others would also be interested.  Don't know what's the
max. number of folks you could escort through there (might want to check
in advance with the colo, in case that could be an issue - and possibly do
some RSVP) ... and may want to coordinate timing if there are folks you
think are "essential" to get the "tour" or whatever.  Other than that, I'd
say pick a date. :-)

> > 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
> 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).
That was pretty intentional, ... there are pros and cons of using
various permissions there.  My first concern was that it be rather
difficult (reduced probability) for anyone to accidentally or intentionally
mess up (e.g. remove or squash) at least those particular log files - hence
the tight write permissions.  I could have allowed group or world write
permissions on the directory and set the sticky bit on the directory,
but that still has some possible downsides (more mischief/accidents can
be done by folks there, and the directory could get a bit more clogged with
various stuff dropped there - I wanted to keep it relatively "clean").
What I was thinking would be most likely "solutions" - using the existing
permissions there - is if/when some other (functional, not necessarily
UNIX/LINUX) group (such as SF-LUG webmaster or BALUG webmaster if/when
those are quite distinct roles) wants to write some similar set of
log files, root could either:
A) create a file or subdirectory within that directory that has
   the permissions allowing the relevant folks to write, or
B) drop in a suitably named symbolic link to wherever such group(s)
   write the relevant data/logs
Either of the two approaches noted above would make them pretty
findable from that fairly centralized location, and would also maintain
a rather high degree of integrity of files where root wouldn't want
other IDs mucking with those few (two thus far) specific files.
It also allows different functionality/roles to be split out a fairly
reasonable bit - e.g. routine "day to day" things that a webmaster may
want to note and log may, for the most part, be of little to no interest
to the systems administrator(s), or vice versa (but most of the
sysadmin stuff is readable for those who want to know, and the sysadmin
has the technical ability to read whatever, and presuming it's invited
or appropriate can look at other logs or such).
Certainly not the only way to slice and dice it ... but it's what I
came up with when I gave it about 20 seconds thought the other day (takes
a wee bit longer to type that up).

Also, another idea which crossed my mind shortly after making the world
readable file - we could also serve that up via the webserver.  Though
it wouldn't make that text into a wiki, it would make that accessible
for all on the Internet to read (which might be much more convenient
for many folks, and would also serve as more of an educational/training
resource with the greater availability).

> > The wiki pages are probably much more suitable for more general
> seems right. For
Yup, ... as I suspected, the "right" answer is neither "do it all
(or even most all) in wiki" or "do it all in flat text files", but
rather use what's most appropriate and fitting and where it fits (and
the "boundaries" of that can generally always be tweaked later).

> I suggest revising the existing wiki text bullet points under
> the Objectives section to be
"done" - not sure if I got it precisely as you had in mind.  I still
kept some of the high availability and related objective stuff up
towards the top, and mostly updated/added where the updated text you
suggested started to essentially overlap some of the existing stuff
written on the wiki.  I also did a s/Unix/LINUX/ substitution.  If I
didn't get it quite right, feel free to tweak and/or let me know.

> > Code of ethics?  Should we add to the "rules of the road" / policy
> don't like the word "professional*". How about
Okay, ... added something on that based upon your suggestion.  Again,
feel free to tweak or let me know if it's not suitably to your liking.

references:
http://linuxmafia.com/pipermail/sf-lug/2007q2/001454.html
http://sf-lug.com/wiki/doku.php?id=system:system_administration_rules_of_the_road_this_box
http://sf-lug.com/wiki/doku.php?id=system:appropriate_outage_notification