[sf-lug] A side note for clarity / "policy" (& reality)

[Michael Paoli]

Regarding:

> From: jim <jim at well.com>
> Date: Sat, 2 Jan 2016 18:14:56 +0000

> A side note for clarity:
http://linuxmafia.com/pipermail/sf-lug/2016q1/011600.html

A bit of reality ;-) ... slightly redacted, and omitting a long trail  
of earlier
referenced email chain it had included, I show below email I sent a  
while back to
the SF-LUG systems administrators (plus one person who has volunteered  
to assist as
webmaster).  I'll also note that the "vicki" situation and where the SF-LUG
stuff (other than the list) runs, has changed a bit since the earlier  
email below.
For an udpate/refresher on that, have a look here:
http://linuxmafia.com/pipermail/sf-lug/2015q4/011584.html

Anyway, from my earlier email, regarding "policy", etc.:

----- Forwarded message from Michael.Paoli at cal.berkeley.edu -----
     Date: Wed, 25 Nov 2015 02:21:30 -0800
     From: "Michael Paoli" <Michael.Paoli at cal.berkeley.edu>
  Subject: Re: SF-LUG policy(?)
       To: [SF-LUG systems administrators]
       Cc: [someone who volunteered to be webmaster]

[[someone who volunteered to be webmaster] - FYI, [SF-LUG systems  
administrators] is off-list alias that goes to
SF-LUG sysadmin folks - includes Jim, Grant, myself, and some other(s)]

Well, a bit of reality ;-) ... and some commentary:
May want to put this "policy" information where folks can see, find,
read, reference, and if/as/when appropriate, update it.  E.g. somewhere
under:
http://www.wiki.balug.org/wiki/doku.php?id=system:system_administration_rules_of_the_road_this_box
or:
http://www.wiki.balug.org/wiki/doku.php?id=start&idx=system
or:
http://www.wiki.balug.org/wiki/doku.php?id=start&idx=sf-lug
(and yes, I know, the above mostly hasn't been updated yet to reflect
"vicki" having been powered down at the colo, and its subsequent
relocation out of the colo more than 60 days later, nor the relocation
of BALUG VM relatively shortly after the aforementioned power down, and
relatively quick moving of essential SF-LUG services onto that BALUG
host, plus some other fair bits that are also out-of-date).
(registration on the wiki is locked down to keep bad bots from causing
issues - just let me know if you need/want an account on the wiki if
you don't already have one).
And since, per "policy" sf-lug web site content is to be relatively
static, etc. and prefers to move away from PHP, etc., seems some site
not on sf-lug (or not on sf-lug "proper"/main) site, would be
relatively fitting.

Sounds a bit more like goals/ideals :-) ... than, at least current
"policy"/reality.

At present time (2015-11-24) and since >~=2015-08-24, the sf-lug "site"
is merely virtual name hosted atop a BALUG host - which is itself a
virtual machine (got IPv4 addresses?).  It's not an "SF-LUG" host, but
is a BALUG host which, as courtesy, is also hosting some SF-LUG stuff
(notably web pages, DNS master, and automagic daily backups of the
more/most critical SF-LUG list data (roster and mbox archive, and also
hosts fair bit of version history/control metadata thereof).

Anyway, so long as it's (for whatever "it" is) sitting on my personal
home network and/or running on my own personal hardware, I'll have at
least some say on who has what type of access (e.g. do they get
unrestricted root or not).

There *is* ("was"?) an SF-LUG virtual machine - it still exists, but is
mostly (mostly - since I recently fired it up again for a bit,
disabled/reconfigured some things to prevent "accidents" and the like -
believe I also noted those in /var/local/log/log on that host) sitting
dormant thus far, atop ye olde "vicki" host.  Jim - you can have that
SF-LUG VM disk image if you want - I can provide copy or arrange to
transfer copy to anyone you so designate - just provide suitably large
enough writable media (e.g. USB or SD or microSD, etc.) - it's 11 GiB -
that's the full disk image size - and likely compresses down to well
under 2 GiB.  Perfectly good ready to run OS (Debian GNU/Linux 7.8
(wheezy) x86_64), just could use a bit of updating, since it's mostly
not been running for over 2 months now (I did upgrade the BALUG VM and
the "vicki" host OS to Debian GNU/Linux 8.2 (jessie) x86_64).  Jim - if
you want the entire physical "vicki" host, you can have that ... but it
is pretty darn noisy when it's running - mostly quite a bit of fan
noise - so be forewarned.  But I'd kind'a hate to have it deployed
somewhere where it won't get at least some reasonable use (where I have
it now, it will at least be providing higher availability for both
BALUG VM, and also the SF-LUG stuff running on that (web site & DNS
master).  Anyway, that's where things are at now.  If the box was quite
a bit quieter, I'd probably opt to leave it running 7x24, but it's not.
But even if it was, I don't have much in the way of IPv4 addresses to
spare for LUG(s).  So, ... have one for BALUG.  Maybe I'll be able to
squeeze out another for SF-LUG, but quite possibly not, and I'd also
rather not "give" or provide such if I might need to take it back.  I
anticipate being able to do IPv6 as needed and more-or-less desired,
but still, with the noise of the "vicki" physical host, I'm more likely
to just have the one BALUG VM running (which also currently has the
SF-LUG aforementioned services hosted on it), and move it to the
"vicki" hardware when my laptop isn't available at home and/or when I'm
not at home.  Could possibly do separate VM for SF-LUG, and do some
type of forwarding of ... eh, that sort'a could possibly be done, but
gets messy, ugly, complex ,.. and/or also infeasible.  E.g. can't
really do two separate DNS masters on same IP address on different
hosts - no particularly good way to "forward" that in a way that would
work properly for both to work as expected as masters ... though not
impossible to sort'a kind'a fake it ... maybe - at least partially.

So, ... "the host of sf-lug web site" ... "dedicated to running the
sf-lug web site only" - definitely not the case where it's presently
hosted.

"sf-lug web site itself" ... "static" yep, but it could do with some
updating ;-) ... still says "located at the ServePath Colocation
facility on Spear Street, courtesy of ServePath/ColoServe" ... looks
like it's not been ServePath since ... sometime in 2011-04.
https://web.archive.org/web/201104*/http://www.servepath.com/
(but looks like ServePath ... not the only kind'a out-of-date web page
out there ... only in 2014 did it change from being "A ServePath
Company", to showing it as part of Go Grid:
https://web.archive.org/web/20140*/http://www.coloserve.com/
)
"the sf-lug web site host should be open to sf-lug supporters for
whatever they want to try out" ... well, were it on it's own dedicated
hardware resources, etc., sure, but if it's just some services on a VM
that's primarily for something else anyway, can't exactly have folks
goin' hog wild on it.

"Trust is efficient" ... don't forget also, "Principle of least
privilege"
https://en.wikipedia.org/wiki/Principle_of_least_privilege
And yes, use sudo, etc.
Let's see, e.g. ...
$ hostname; { last; last -f /var/log/wtmp.1; } | awk '
> {if(($1~/./)&&($0 !~/^wtmp[^ ]* begins /))print $1;}' | sort |
> uniq -c | sort -bnr
balug-sf-lug-v2.balug.org
       9 mpaoli
       6 reboot
$ lastlog -u root
Username         Port     From             Latest
root             ttyS0                     Tue Feb 28 23:12:31 -0800 2012
$
Obviously not too many direct root logins, and none recently - been over
3 years since there was a direct root login - and even that last one was
"only" on the (virtual serial) console.  (And a moderate number of
reboots in the last couple months or so, as the host changed physical
locations, and did also go through a major OS upgrade
(Debian GNU/Linux 7.9 (wheezy) --> 8.2 (jessie))).

Deprecate PHP ... fine and good, easy enough to do with the web pages
themselves - if they're using PHP.  As for host, that's more practical
if it's an SF-LUG dedicated host - PHP may be used/needed for other
things ... or not.  Not sure off-hand why I've got PHP on that host -
might've needed it for the SF-LUG pages - which presently use PHP ...
or perhaps it was some other requirement or the like that brought in
PHP ... ah, actually needed, if for nothing else, also for the BALUG
wiki stuff (dokuwiki).

"authority derives from" ... well, authority comes from multiple
sources and practical matters.  Domains - sf-lug.{org,com) - Jim's ...
paid for such?  As I understand it, Jim, you didn't pay, the domains
expired
(
http://linuxmafia.com/pipermail/sf-lug/2015q3/011275.html
) and somehow Asheesh managed to talk Network Solutions / Web.com into
reinstating the account into good standing and extending the expiration
for another two years - and on both domains - and without paying anyone
anything.
(
http://linuxmafia.com/pipermail/sf-lug/2015q3/011313.html
)
I don't think Jim is currently paying for any electrical power for
sf-lug.{org,com} or its hosting.  I'm providing the power, but if it's
VM on my laptop, it's pretty trivial incremental.  If it's powered up
"vicki" box, it's fair bit more power, but nothin' that's gonna break
my bank.  Bandwidth?  Presently provided by Rick Moen (lists) and me
(web site & DNS master; slaves are and/or have been provided by various
folks/entities), physical box power & bandwidtth formerly provided by
Datapipe formerly provided by Go Grid formerly provided by ServePath.
The "vicki" hardware was donated by Silicon Mechanics to Jim/SF-LUG.
And other costs?  I'm sure Jim (and others) cover/contribute to various
random incidentals (e.g. like bothering to show up at meetings, giving
folks rides home, ...) - not to be understated or underestimated
(sometimes the little things matter ... sometimes a lot).

I tend to think "authority"/control/etc. - basic running of LUGs,
typically boils down to a few factors - who holds & controls the "keys
to the kingdom" (owns/controls the domains, access to and/or controls
host(s)/services), and also he/she that gets the work done and/or
coordinates other(s) to do so.

Anyway, if/when things change, ... I might have or more feasibly be
able to have "vicki" up 7x24, or provide it ample Internet IPv4
addresses, etc., but that's not presently the case - and I don't see
that as probable to change in near to medium-term future..  May be able
to do more VMs if/when I do some memory and/or drive upgrades - but
don't know if/when that will be.  In the meantime, ... situation
presently is what it is.

> To: Michael Paoli <Michael.Paoli at cal.berkeley.edu>, [someone who  
> volunteered to be webmaster]
> Cc: [some of the SF-LUG systems administrators]
> From: jim <jim at well.com>
> Subject: Re: [sf-lug] sf-lug site & hardware
> Date: Tue, 24 Nov 2015 22:10:12 +0000

> Sorry, I mis-read.
>
> Policies:
> * The host of the sf-lug web site is a Linux machine or virtual machine
>  dedicated to running the sf-lug web site only. A "different host" may
>  refer to another VM running on the same physical host as that which
>  supports the sf-lug web site.
> * the sf-lug web site itself should be static, with no interactive
>  software, for ease of maintenance and security; it is essentially an
>  internet-accessible yellow page style advertisement.
> * The sf-lug web site can include links to interactive web pages,
>  although properly such interactive pages should be hosted on some
>  different host other than that which hosts the sf-lug web site (for
>  easy maintenance and security).
> * the sf-lug web site host should be open to sf-lug supporters for
>  whatever they want to try out. "Trust is efficient." We assume no user
>  will alter work done by other users. We assume users will make mistakes,
>  even hork the host itself, and that users will use sudo rather than
>  the root account to make changes (exceptions to this include Michael
>  Paoli and Jim Stockford and whoever else can get Jim or Michael to
>  approve). Preferably users should experiment on a host other than that
>  which runs the sf-lug web site itself.
> * Jim wishes to deprecate PHP on the host that supports the sf-lug web
>  site. Jim has no power to enforce this. Jim prefers shell scripts, C,
>  and Python. Jim's authority derives from his paying for domain name,
>  electrical power, bandwidth, and other costs. To the extent that
>  other people pay such costs, they derive authority.

[big snip of lots of earlier referenced emails]

----- End forwarded message -----