---------- Forwarded message ---------
From: Michael Paoli <michael.paoli(a)berkeley.edu>
Date: Thu, May 14, 2026 at 2:07 PM
Subject: work-around in place: Re: outage: balug.org, berkeleylug.com,
sf-lug.org, ...
Work-around* in place.
So, things should be meta-stable for now.
Reduced redundancy at present.
Hopefully back to nominal redundancy
soonish (more hardware work to do).
*yanked storage, installed it on another
computer** for now, reconfigured
(because different Ethernet MAC addresses)
booted & running that for now
**https://www.wiki.balug.org/wiki/doku.php?id=system:vicki_documentation
and that documentation is out-of-date,
vicki hasn't been nominal primary host for a long time.
It has only 2GiB of RAM, older CPUs, is rather loud
1U form factor, and sucks a lot of power
relative to what it does. In any case,
for now the VM is atop that.
On Thu, May 14, 2026 at 9:02 AM Michael Paoli
<michael.paoli(a)berkeley.edu> wrote:
>
> outage: balug.org, berkeleylug.com, sf-lug.org, ...
>
> Hardware issue.
> Don't have estimate for when will be back online,
> with bit of luck, etc. hoping for later today PDT.
> Data almost certainly fine, but getting it back online ...
> shall see.
>
> At present that impacts most content on domains
> balug.org, berkeleylug.com, sf-lug.org, etc.
> (but not the BerkeleyLUG nor SF-LUG lists).
> and almost everything with at least IPs that
> match these:
> 96.86.170.224/29
> 2001:470:66:76f::/64
> 2001:470:67:76f::/64
> 2001:470:1f04:19e::/64
> 2001:470:1f05:19e::/64
> 2603:3024:1b29:2::/64
Should be "all better now".
Attempted to fix a minor bug last month,
didn't get it quite right, that then caused this month's
to not go out (on time). Fixed, that,
correctly this time, and now appears all is well
(reran the program slightly later this month after the fix).
Context was already within single quotes ('),
so needed to properly be '\'' to get a net single quote at that level.
Had earlier fixed whitespace after -m option - where shouldn't have
been, but that then caused the loop to error out, until the other issue
was properly corrected.
# rlog lists_monthly 2>&1 | sed -ne '/^revision 1\.6$/q;/^-\{28\}$/,$p'
----------------------------
revision 1.10 locked by: root;
date: 2026/03/02 06:07:30; author: root; state: Exp; lines: +1 -1
properly fix syntax around (intended) log message for context
----------------------------
revision 1.9
date: 2026/02/09 22:35:01; author: root; state: Exp; lines: +1 -2
http --> https; remove set -x
----------------------------
revision 1.8
date: 2026/02/09 22:28:06; author: root; state: Exp; lines: +1 -1
fix syntax on (intended) log message
----------------------------
revision 1.7
date: 2025/07/02 14:44:38; author: root; state: Exp; lines: +8 -0
filter out list has no members stdout output line in case list
membership [for --role] is empty
----------------------------
# rcsdiff -U 0 -r1.7 lists_monthly 2>&1
===================================================================
RCS file: RCS/lists_monthly,v
retrieving revision 1.7
diff -U 0 -r1.7 lists_monthly
--- lists_monthly 2025/07/02 14:44:38 1.7
+++ lists_monthly 2026/03/02 06:07:30
@@ -51 +51 @@
- ci -d -f -l -M -m 'membership update' membership
>>/dev/null 2>&1
+ ci -d -f -l -M -m'\''membership update'\'' membership
>>/dev/null 2>&1
@@ -62 +61,0 @@
- set -x
@@ -68 +67 @@
- echo '\''http://www.balug.org/#Lists'\''
+ echo '\''https://www.balug.org/#Lists'\''
#
On Sun, Mar 1, 2026 at 10:15 PM Michael Paoli via BALUG-Admin
<balug-admin(a)lists.balug.org> wrote:
> Date: Mon, 02 Mar 2026 06:15:38 +0000 (UTC)
> Subject: [BALUG-Admin] BALUG: Lists, stats, etc.
> dates, lists, number of members:
> YYYY-MM-DD announce talk admin
> 2026-03-02 456 238 31
> 2026-02-01 457 237 31
> 2026-01-01 457 236 31
...
So, on the BALUG VM (hosting balug.org, sf-lug.org & berkelug.com.
(except list on those latter two), many additional domains, DNS
primaries for all those, additional secondaries, etc.
So, IP addresses:
$ (for IP in 10.1.10.109 96.86.170.229 2001:470:1f04:19e::2
2001:470:1f05:19e::2 2001:470:1f05:19e::3 2001:470:1f05:19e::4
2001:470:1f05:19e::5 2001:470:1f05:19e::6 2001:470:1f05:19e::7
2001:470:1f05:19e::8 2001:470:1f05:19e::9 2001:470:1f05:19e::a
2603:3024:1b29:0:5054:ff:fe13:5199; do echo "$IP" $(dig
@ns1.google.com. -b "$IP" +short o-o.myaddr.l.google.com. TXT | tr -d
'"'); done)
10.1.10.109 96.86.170.230
96.86.170.229 96.86.170.229
2001:470:1f04:19e::2 2001:470:1f04:19e::2
2001:470:1f05:19e::2 2001:470:1f05:19e::2
2001:470:1f05:19e::3 2001:470:1f05:19e::3
2001:470:1f05:19e::4 2001:470:1f05:19e::4
2001:470:1f05:19e::5 2001:470:1f05:19e::5
2001:470:1f05:19e::6 2001:470:1f05:19e::6
2001:470:1f05:19e::7 2001:470:1f05:19e::7
2001:470:1f05:19e::8 2001:470:1f05:19e::8
2001:470:1f05:19e::9 2001:470:1f05:19e::9
2001:470:1f05:19e::a 2001:470:1f05:19e::a
2603:3024:1b29:0:5054:ff:fe13:5199 2603:3024:1b29:0:5054:ff:fe13:5199
$ dig -4 @ns1.google.com. +short o-o.myaddr.l.google.com. TXT | tr -d '"'
96.86.170.229
$ dig -6 @ns1.google.com. +short o-o.myaddr.l.google.com. TXT | tr -d '"'
2603:3024:1b29:0:5054:ff:fe13:5199
$
Recently started adding more. Some of the motivations:
Had some recent minor glitches between Hurricane Electric (HE.net,
tunnelbroker.net) IPv6 IPs and AT&T (att.com) IPv6 IPs.
I've also got Comcast Business IPv6 IPs potentially available to me (my
current ISP), but for the most part hadn't been using those. Longer
term will likely move to AT&T, but in the meantime. So, started adding
those, not yet all that significantly pressed into service, but mostly
set. Just add relevant statics, DNS entries, etc., and good to go.
And checking side-by-side, the HE.net/tunnelbroker.net IPs perform very
surprisingly well - even with their tunneling, latency and number of
hops, almost indistinguishable. And the up-front prep work will make later
transitioning to AT&T IPs that much simpler.
Also, changed the Mail Transport Agent (MTA) from exim4 to Postfix.
There were multiple motivations on that, including:
exim4 just wasn't cutting it anymore. Most notably, though exim4 has
configuration for source IP(s) for SMTP send, it just doesn't work. I'd
mostly kludged around that, by it / the routing generally using by
default, source of the last (IPv4 or IPv6) IP address added, but that
was no longer sufficient and had bitten me multiple times before.
Though it's documented - it just plain doesn't work - and all the
research basically pointed to same, and I certainly wasn't the only one
to switch from exim4 to Postix to get a proper working solution.
Additionally, exim4 has still no capabilities for per-domain aliasing.
Very annoying, as that means if there's rsvp(a)balug.org, then the alias
for that also applies to rsvp(a)lists.balug.org, and any other mail
domains too - not at all what's desired. So, with Postfix, can well
separate those out. Furthermore, part of the anti-spam configuration
I'd been using with exim4 was highly outdated and not being maintained,
and a bit fragile and crusty, so, also good to get away from that, and
dropping exim4 was also a cleaner simpler way to do that. And, yet
another advantage, mailman3 well supports two MTAs, Postfix and exim,
but it better supports and default configurations support Postix, so,
even simpler to deal with mailman3 on Postfix than exim4. So, all
those reasons, quite overdue to switch to Postfix, and have now done
so. And well tested on the BALUG-Test list too. Most all changes were
also first tested on a test VM (balug13) too, before being implemented
on the production VM (balug).
In the bit of example testing further above, can see for each of many
source IPs, that for all of them we can see that they not only route
properly, but the server in fact sees the expected source IP address,
(same IP, excepting the one v4 behind NAT/SNAT) and likewise also with
default source for v4 and v6 - though on the latter I may or may not
want to change what that default is. But with MTA and DNS using their
proper source IP addresses for their services, in those case, doesn't
much matter what the defaults are when the sources are set properly
when used for the services, most notably source IP on MTA when it sends
or attempts to send email.
So, fair bit of cleanup and improvements on that infrastructure, and
helps well clear the way for more.
So, after BALUG (VM balug) upgraded from Debian 12 to 13 starting
after 2026-01-28T03:50:34Z, significant issues, most notably at least
mailman3 web related stuff wasn't working. This was mostly resolved by
2026-02-09T20:53:03Z
And ... lots of details. Since this month's BALUG meeting has
discussion topic of Testing & Troubleshooting, posted much of the
relevant to the BALUG-Talk list, and archive of that posting is
available here:
https://lists.balug.org/mailman3/hyperkitty/list/balug-talk@lists.balug.org…