[volunteers] Fwd: [web-team] Linode Support Ticket 5649987 - Critical Xen Maintenance / Reboot Schedule
rick at linuxmafia.com
Tue May 3 13:25:08 PDT 2016
Quoting Daniel Gimpelevich (daniel at gimpelevich.san-francisco.ca.us):
> I was pretty sure that backing up the whole of site-docs per the
> previously stated backup spec would already include those, but just to
> make sure, I just now looked in the first backup that was made, and
> those are in there.
Ah, apologies for the ambiguous suggestion. What I meant was: Please
don't forget to update site-docs/TODO and site-docs/ChangeLog .
site-docs/TODO mentions as a to-do item that it would nice to have
regular backups. My point is that, having instituted regular backups,
you should remove that from the to-do list.
Yes, I certainly could have done that for you. And I could, if you wish
-- but I'm trying to coax people into more consistently paying attention
to, and maintaining, the site docs.
site-docs/ChangeLog in a narrow sense might seem to properly record only
changes _on_ www.svlug.org, and maybe you didn't make any in instituting
regular backups -- but the point is that what you did ought to be noted
_somewhere_ (other than on a mailing list, which is the world's most
inadequate form of documentation, because nobody bothers to read or heed
it later -- see below for example), and ChangeLog is arguably the right
Or, at your discretion if you prefer, I suppose you could create
separate file site-docs/system-backups . Your call.
But _somewhere_ in site-docs, the essentials of what has been done ought
to be recorded for collective knowledge, in my opinon.
> Relatedly, I'd like to mention the lack of an analogous ChangeLog for
> the other host. I suppose it could be reconstructed from its bash
> history files, minus the datestamps.
I cannot see any benefit in making the monumental effort required to
try. (But if you seriously think there is, go right ahead.)
As a reminder, it's not safe to make changes to the software of that
host, so we carefully do not do so. It is dangerously brittle and
unmaintainable: Attempts at package operations in the past brought up
scary warning messages, and far too many key parts of its software are
hand-hacked, locally compiled, non-packaged, undocumented pieces of
once-cutting-edge betaware (Mailman, sa-exim, etc.) The only way
forward for that machine is to, at some point, cut our losses and
migrate its functions to a new host. Which would _no longer_ rely on
special-snowflake locally built and hand-hacked software with no
documentation -- which is what it has.
Mind you, some of that hand-hacked, undocumented, locally built software
has been excellent. But at some point it will fail catastrophically,
probably from security breach (though there's always the possibility one
of us will blow it up accidentally).
As a preparation for that event, I keep weekly backups (over e-mail) of
the Mailman rosters, nightly (IIRC) backups of the Mailman mboxes, and
a static offsite copy of all of the host's useful tools -- so that
if/when the host fails and SVLUG must migrate to a new host, we won't
have lost anything worth keeping.
In light of that situation, I have no idea what possible practical use a
Changelog on that host would be. It's pretty much broken, and the
_exact_ history of how it got that way IMO lacks interest.
But if you disagree, go ahead. It's your time to waste. But please,
for God's sake, please be careful on that machine.
More information about the volunteers