> From: "Michael Paoli" <Michael.Paoli(a)cal.berkeley.edu>
> To: BALUG-Talk <balug-talk(a)lists.balug.org>
> Subject: test DNS that returns SERVFAIL? ... ! :-)
> Date: Mon, 13 Apr 2020 03:14:35 -0700
> Ah yes, I'm quite starting to get used to and like/prefer dynamic DNS
> update. Significantly more goof-resistant, and most of the time I don't
> even have to think about the zone serial number. Which reminds me,
> I do still want to add some version "control" (tracking) ... driven via
> cron, so I'll at least have periodic snapshots of changes (since no
> longer using ye olde manual method & manual version control). For
> more recent changes, and fine-grained history of changes, logs cover
> that quite well. But for the longer historical record ... wee bit 'o
> gap presently to fill on that.
And now added. Doesn't catch the "why", and doesn't catch
change-by-change, but automatic daily check-in of any changes,
"good enough" for my(/our?) purposes here, and have that now:
$ cat /etc/cron.d/local-bind-master-auto-rcs
0 10 * * * root exec >>/dev/null 2>&1 && for zone in
e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa berkeleylug.comsf-lug.comsflug.comsf-lug.netsflug.netbalug.orgberkeleylug.orgsf-lug.orgsflug.org; do rndc sync -clean "$zone" && rndc freeze "$zone" && {
rcsdiff digtitalwitness.org || { rcsdiffrc="$?"; [ "$rcsdiffrc" -ne 1
] || { ci -l -d -M -m'checking in change(s)' "$zone"; }; }; rndc thaw
"$zone"; }; done; :
$ hostname
balug-sf-lug-v2.balug.org
$ ls -l /etc/localtime
lrwxrwxrwx 1 root root 27 Apr 19 09:56 /etc/localtime ->
/usr/share/zoneinfo/Etc/UTC
$
Okay, one more time ... hopefully relatively smoothly this time.
Have done fair bit more thorough testing, essentially on
"cloned" virtual machines (while also taking the appropriate
precautions to avoid conflicts with the running production).
Anyway, will restart the upgrade process soon.
If all goes relatively smoothly, should be complete after
a few hours or so.
Services - for the most part will mostly remain up and operational
throughout, but there will definitely be at least some disruptions,
due to some required reboot(s) and stopping and restarting of
services. I'll update once things have completed and things
look good ... or any substantially different results.
This BALUG VM is the host that supports essentially all (except some
additional DNS slaves) services of:
BALUG
and likewise excepting list services, for:
SF-LUG
BerkeleyLUG
references/excerpts:
https://lists.balug.org/pipermail/balug-admin/2020-February/001017.htmlhttps://lists.balug.org/pipermail/balug-admin/2020-February/001018.htmlhttp://linuxmafia.com/pipermail/conspire/2020-April/010521.htmlhttp://linuxmafia.com/pipermail/conspire/2020-April/010525.html