[sf-lug] sf-lug.{com,org} - wither/whether/weather/where? ;-)

[Michael Paoli]

For those that might not know, the host that provides
[www.]sf-lug.{com,org} is and for many years has been located at
GoGrid (formerly ServePath, and recently acquired by Datapipe) colo
facility in San Francisco, and has been graciously provided by them
gratis (we provided the hardware - which Jim got donated from
Silicon Mechanics).  However, it seems rather probable that may be
changing in near future.  I did get this from Jim Stockford earlier this
week (excerpted SF-LUG relevant bits, anyway):

> From: jim <jim at well.com>
> Date: Tue, 21 Jul 2015 16:37:38 +0000

>     GoGrid wants money to the tune of $200+ per month.
> There was no talking them out of that. I have asked
> them (per their suggestion) to cancel service and
> let me know when I can get the machine.
>
>     As to the use to which we're putting it, I can
> put up the SF-LUG (static) web site on either of
> two hosts, though I have not yet decided which.
>
>     My guess is that the machine is down by the
> time you read this. I don't know when I'll be able
> to retrieve it, I'm guessing this week.

Anyway, I've emailed Jim - also left voicemail message.  Various bits
to consider and work out.  Not sure of the most up-to-the-minute status
regarding the colo facility and the hardware we (SF-LUG) have there, but
if sf-lug.{com,org} winks out of existence from The Internet for a
while, well, that's probably why.  The below is some of the most recent
I'd emailed Jim on the matter, again excerpting mostly just the SF-LUG
relevant and non-redundant bits (and two typo corrections) - also, for
context, "vicki" is the physical host upon which [www.]sf-lug.{com,org}
and the master nameservers for sf-lug.{com,org} reside (actually, upon
the sflug host as qemu-kvm virtual machine atop "vicki" the physical
host).  I'll also mention I've picked up some additional more frequent
backups with the possible/probable imminent demise of the host's present
colo arrangement and connectivity.
$ sudo zfs list -t snapshot
NAME                    USED  AVAIL  REFER  MOUNTPOINT
pool/balug at 2015-07-03   382M      -  4.70G  -
pool/balug at 2015-07-11   240M      -  4.73G  -
pool/balug at 2015-07-21  29.6M      -  4.75G  -
pool/balug at 2015-07-22  29.8M      -  4.75G  -
pool/balug at 2015-07-23  30.7M      -  4.75G  -
pool/balug at 2015-07-24      0      -  4.76G  -
(those actually cover "vicki", "sflug", and also virtual host used by
BALUG - have lots more older backups, but those are just the ones
on-line at my fingertips presently).
And in case someone was wondering how much space "all" that SFLUG stuff
takes up:
$ sudo sh -c 'cd /var/tmp/balug/sf-lug.org./root && du -sh .'
481M    .
(and, no, "root" above isn't root's HOME directory, but rather the root
of the / filesystem for that host - any other filesytems relative
beneath that - reason being UIDs/GIDs are preserved, but don't match
those on host where those backups are, so the sf-lug.org. directory is
owned by UID 0, and has no perms for go (chmod go=), thus preventing
any UID other than 0 (root/superuser) from possibly accessing or
otherwise mucking about with that backed up data).

> From: "Michael Paoli" <Michael.Paoli at cal.berkeley.edu>
> Subject: Re: vicki (exodus) & GoGrid/Datapipe
> Date: Thu, 23 Jul 2015 03:14:08 -0700

> And *so* far vicki is still up and running, but ... I guess we don't
> know for how long that will continue.  So ...
>
> Various SF-LUG things and *some* BALUG things to consider.
>
> Going over SF-LUG first, since it has greater level of direct
> dependencies upon vicki - but there is some BALUG overlap.
>
> SF-LUG:
>
> DNS: sflug host is master for both sf-lug.org. and sf-lug.com.  If where
> that will "land" may not yet be known, it may be advisable to set up a
> multi-master configuration on the shorter term - that way at least
> slaves will still receive and can get updates, even if the sflug host is
> down for some bit.  There may be questions of where, who'd have access
> and maintain, etc., but it's not horribly difficult to put it *almost*
> anywhere.  Mostly just need static IP - and needn't at all be exclusive
> to sf-lug - and most any sufficiently reasonable DNS server can do that,
> and at least preferably, one that can use the existing zone files.
> Oh, also, unless there's some urgent need to change registrars, probably
> *do not want to be changing registrars* while key DNS changes may be
> afoot - notably changes in IP(s) of NS records for sf-lug.{com,org}.
>
> list: I presume list can remain precisely as and where it is - quite
> entirely independent of vicki ... except for the automagic backups.  No
> sflug host, no automagic overnightly backups of the sflug list stuff.
> Note also that automagic overnightly backup stuff is done using rsync
> and explicitly set to go quite easy on bandwidth (notably because
> source site is at end of a DSL line that doesn't have especially high
> bandwidth).  So it would likely remain relatively light on such if
> continues/resumes that client duty.  However, if it goes without doing
> that for a long time, may take it longer to "catch up".
>
> web site: it's highly simplistic, that could probably be
> virtual name hosted *almost* anywhere ... but "of course" there may be
> questions of who has access, who provides the resource(s), who maintains
> it (and wants to and will), etc.
>
> backups & miscellaneous: I do rather regular backups of the sflug host,
> have backups about monthly going back quite a ways.  I do also have
> backup from shortly before the i386 --> amd64 architecture
> conversion/upgrade/sidegrade.  sflug is a virtual machine under
> qemu-kvm, but it's architected quite physical-like, so it could be
> easily transitioned to direct physical if need be.
> $ hostname && echo $(lsb_release -d) $(dpkg --print-architecture)
> sflug
> Description: Debian GNU/Linux 7.8 (wheezy) amd64
> $
>
> SFLUG & BALUG:
> vicki - physical host presently housing the above.  Where will that box
> go?  It's 1U, not very deep, moderate power consumption (two fair sized
> physical disks, older but decent hardware, IPMI capable server, dual
> NICs).  Where that will go and with what kind of access and will it get
> "enough" (or how many?) IPs might answer or help answer how feasible it
> is - or isn't - to deal with some of the other bits upon it.  Earlier I
> was thinking I wouldn't want to host it off my DSL, but actually, given
> the relative shallow depth of the box, I might possibly reconsider
> that (it's not all that huge, and not all that huge a power suck).
> But I couldn't give it 3 IPv4 addresses as it presently has.  I could
> give it 1, or maybe at max possibly 2, but probably not 3 or more.
>
> General:
> Of course easiest and quite possibly best, would be if vicki is able to
> continue as and where it is and has been, and without cost (or
> economical enough no one would sneeze at the cost).  Next best / next
> easiest would be quite similar in another comparably convenient colo -
> that would "just" be physically moving it and changing IP addresses and
> such.  After that, similar and accessible, but not so convenient a
> location (if/when we were to get the remote IPMI fully functional, that
> would significantly ease remote management, making on-site visits almost
> entirely unneeded).  And if none of that is possible/feasible ... can
> vicki be hosted elsewhere reasonably, and if so, how many IPs?
> Bandwidth is also a consideration, but DSL is probably quite
> "fast enough" - though not quite optimal.  How many IPs available where
> and who can have physical access if/when it might be needed - or can
> cover that if/when needed, may end up the deciding factors on where the
> hosts (or their virtual functionality) end up landing.
>
>> From: "Michael Paoli" <Michael.Paoli at cal.berkeley.edu>
>> Subject: vicki (exodus) & GoGrid/Datapipe
>> Date: Tue, 21 Jul 2015 11:21:55 -0700
>
>> Well ... it doesn't appear to be off-line *quite* yet.
>> I do also have fresh backups including 2015-07-03, 2015-07-11, and
>> also attempting to get a nice fresh updated backup now - as long as it
>> remains online while that's running, will also have that fairly shortly.
>>
>> I'll be at BALUG this evening - Jim - perhaps you ought stop by.
>> Perhaps we can discuss a bit more "where from here".
>> Could possibly even pull the physical host this evening if need be.
>> And if you don't want 64-bit for sf-lug, have older i386 backups too
>> (or the 32-bit --> 64-bit procedure could also effectively be reversed).

Oh, and I expect I'll be at BerkelelyLUG this Sunday - and likely even
with those most recent sflug backups with me.  Jim - if you show up
there with something I can write/transfer it too (USB flash/drive,
[micro]SD[HC], {CD,DVD}-R[W], Ethernet port & device/host/protocol I can
reasonably transfer the data to), I can give you a copy of the sflug
data.  (Can't give it all to anyone, but could give anyone copy of the
sflug web page stuff, and DNS data (but not metadata) - but then anyone
can also pull all that stuff straight from the host via The Internet).

Also, had earlier been intending to do
Debian GNU/Linux 7.x (wheezy) --> 8.x (jessie) upgrades, but will defer
those (perhaps indefinitely) until the colo/hosting situation gets
figured out or otherwise stabilized.  Ditto for anything having anything
to do with registrar transfer (and we know how much y'all just *love*
<cough, cough> Network Solutions / Web.com ... that could be some
motivation right there for getting the hosting (colo or otherwise)
situation stabilized).

(crickets?)

Ah yes, can be hard to get things done with mostly or entirely
volunteers & donations (not impossible, but ...).  That's probably also
why, for example, BALUG still has open volunteer position(s) for
"chief/assistant cat herder".