So,
I'd much earlier noted on my calendar:
2024-09-24 >= 10:56AM US/Pacific PST8PDT -07:00, if Comcast Business
hasn't screwed up DNS with linuxmafia.com for more than a year,
probably time to remove the
port 5353 work-arounds.
But, I don't think (year earlier) was
necessarily the last of those Comcast DNS issues.
So, last I see that hints of that
is chatter/discussions that tapered off
around 2024-06-04
https://lists.balug.org/mailman3/hyperkitty/list/balug-admin@lists.balug.or…
So, as earlier, since wasn't our first go-round,
I'll push the end date of that work-around to
>~=2025-06-05
and if it's by then had no more such glitches,
will then drop that work-around.
In the meantime, doesn't really hurt hardly anything,
and easier to already have that workaround in place,
should it be needed at all before then.
So, calendar updated:
2025-06-25 if Comcast Business hasn't screwed up DNS with
linuxmafia.com for more than a year, probably time to remove the port
5353 work-arounds.
After unclean shutdown of mailman3,
even when (re)started with
start --force
mailman3 may fail to remove the lock files and thus fail to (re)start.
Details on (I submitted as):
https://gitlab.com/mailman/mailman/-/issues/1174
I'm definitely not the first person to have noticed this issue.
Hopefully they'll get around to fixing it (it's been over 9 years ...
but they may have lacked sufficient relevant detail in the
earlier reports).
Manual workaround:
remove the lock files in
/var/lib/mailman3/locks/
after checking to ensure that
none of them reference and/or are used by any PID(s) still relevant to mailman3
One thing I do like about Mailman 3 is all the available message
acceptance settings, both for list default, and per user.
Those include:
List default -- follow the list's default member action.
Hold -- This holds the message for approval by the list moderators.
Reject -- this automatically rejects the message by sending a bounce
notice to the post's author. The text of the bounce notice can be
configured by you.
Discard -- this simply discards the message, with no notice sent to the
post's author.
Accept -- accepts any postings without any further checks.
Default Processing -- run additional checks and accept the message.
Most notably - Discard highly useful to set non-members to Discard.
Likewise for moderated list(s) where few are allowed to post (e.g.
balug-announce(a)lists.balug.org).
Makes listadmin life fair bit easier, as most all such posting attempts,
that would otherwise be held for moderation on Mailman 2, can be simply
discarded, as almost all of them are junk/garbage/spam and the like -
maybe only about once a year or so does a legitimate message come in
that way. And Reject really isn't that useful, as that happens after
the email has already been received, rather than at SMTP time, so there
would be backscatter issues with that (the overwhelming number of such
mail is spam, and those are typically rather to quite forged senders,
victim compromised accounts, etc.).
And ... not sure exactly how much I (dis)like it on Mailman 3,
but Mailman 2 data was mostly in python 2 pickle (.pck) format files,
with data/configuration bits also being in flat (and also html) files.
Well, Mailman 3, while some configuration bits are stored in flat
configuration files, for better and/or worse, most of the data is stored
in an actual relatively proper database (e.g. sqlite).
So, balug-announce(a)lists.balug.org e.g. imported from Mailman 2,
most all users had the moderation set to hold (Mailman 2 didn't have a
discard option). On Mailman 3 I set the list default to discard for
that list. But almost all users were imported from Mailman 2 and that
import preserved their hold setting. I wanted to change it for those
users to the list default (discard). A bit to chase it down in the
database, but once found and reasonably tested, one SQL statement to do
the needed:
UPDATE member SET moderation_action = NULL WHERE list_id =
'balug-announce.lists.balug.org' and moderation_action = 0;
... and with that done for 492 users. Yay!(?)
Not super easy/pleasant but ... well, compared to Mailman 2,
yeah I think it's at least fair bit better than Mailman 2,
at least on that point/feature/capability.
FYI, did send this out:
---------- Forwarded message ---------
From: Michael Paoli <michael.paoli(a)berkeley.edu>
Date: Mon, Jul 15, 2024 at 11:54 PM
Subject: Mailman 3 listadmin testing (and potential hosting) available
To: Grant Bowman <grantbow(a)gmail.com>, Grant Bowman
<grantbow(a)dvlug.org>, Aaron <acohen36(a)gmail.com>, Tom
<tomrlopes(a)gmail.com>, Ian <droid1836(a)gmail.com>, Rick Moen
<rick(a)linuxmafia.com>, Al <aw009(a)sunnyside.com>
Various SF Bay Area [L]UG(s) [potential] list admin folk(s),
May potentially be some additional folks (if interested, contact me).
Thought I'd invite, for possible testing, etc. some folks that are
list admins of various SF Bay Area [L]UG(s), or might be potentially
very seriously interested in that.
Most notably, have Mailman 3 fairly well set up (at least metastable)
on the BALUG VM (still have more Mailman 2 --> Mailman 3 migration
steps to fully test out and validate before I do all those migrations
for the production lists, including related infrastructure of automation
and information, etc.).
In those regards, if folks are interested in a test list on there for
potentially testing for [L]UG use and list administration thereof,
just let me know. Note that there are test list(s) there currently
(notably balug-test3(a)lists.balug.org which is on Mailman 3 and will
eventually become and be merged into balug-test(a)lists.balug.org
when that gets migrated to Mailman 3), but I was thinking more
significantly and distinct from that, list(s) where I could grant folks
full listadmin access and control. E.g.:
sf-lug-test(a)lists.balug.org
dvlug-test(a)lists.balug.org
berkeleylug-test(a)lists.balug.org
etc.
Could even do different (sub)domains, e.g.:
@lists.dvlug.org
@lists.sf-lug.org
etc., though subdomains would require some fair bit of additional
work/coordination to set that all up properly (DNS, SPF, TLS, ...)
so @lists.balug.org would be the simpler easier place to start and is
already available.
Anyway, if interested, let me know (and notably list name).
If you merely want to test list, can use the existing
balug-test3(a)lists.balug.org e.g.
send email to: balug-test3-subscribe(a)lists.balug.org to subscribe
or see:
https://lists.balug.org/mailman3/postorius/lists/balug-test3.lists.balug.or…
And yes, for at least many (SF [L]UG lists), I'd be willing to host on
the BALUG VM (and in general they could have their own subdomain,
in fact for actual general production use that would be exceedingly
recommended, e.g. something like, say for SF-LUG:
sf-lug(a)lists.sf-lug.org
sf-lug-test(a)lists.sf-lug.org)
But even if one mostly wants to reasonably well test out Mailman 3 and
list administration thereof, the BALUG VM may be a useful place to be
able to reasonably well do that (want to test drive Mailman 3 and see if
it might make suitable list infrastructure for your [L]UG?).
> From: Michael Paoli <michael.paoli(a)berkeley.edu>
> Date: Sat, Jun 29, 2024 at 1:52 PM
> Subject: Re: dvlug list
> To: Grant Bowman <grantbow(a)gmail.com>
> Cc: Diablo Valley Linux Users Group (DVLUG) <dvlug(a)linuxmafia.com>,
> Diablo Valley Linux Users Group (DVLUG) <list(a)dvlug.org>
>
> Grant,
...
> Oh, ... I'll also hang it out there for your consideration, if you
> may be interested ... if you may possibly want to have subdomain with
> DVLUG list(s) on <whatever>@lists.dvlug.org., I could potentially
> host that if you so wanted that ... but maybe ask me again in a
> couple weeks or so ... I'm still doing migration off of mailman
> version 2 (could do mailman 2 in the meantime if you really wanted
> that), so still have more testing, etc. to do, and want to wait a bit
> 'till that's all done and the dust well settled before I consider
> that migration to be a full success (in case I find any latent issues
> that may not be immediately apparent). I'd also think Rick might
> even be willing to do same (notably subdomain part for list) on the
> existing linuxmafia.com host. In any case, food for thought. Could
> also potentially migrate so all the old (most notably archives) would
> still also be present under lists.dvlug.org (similar to how things
> are for BALUG under lists.balug.org). Anyway, just a thought, and
> thought I'd hang the offer out there if you may be interested (and
> would also have the capability to access and back up full archives,
> also member subscription list). And, yeah just to think about it
> more generally, if you use a subdomain (e.g. lists.dvlug.org) for
> list(s), rather than the main domain (dvlug.org), that does leave
> things much more flexible for how one may want to handle list(s),
> most notably it can be hosted or the like, exceedingly independent of
> whatever else may be going on for hosting or whatever on
> [www.]dvlug.org (e.g. web site, etc.).
More of same, involving back-to-back NOTIFY traffic about mpaoli.net,
allegedly originating from master nameserver 96.86.170.226 . Michael, I
greatly doubt your nameserver is doing this. mpaoli.net's zonefile is
pretty unchanging. I suspect Comcast middleman fsckery. Thoughts?
----- Forwarded message from logcheck system account <logcheck(a)linuxmafia.com> -----
Date: Tue, 04 Jun 2024 02:02:01 -0700
From: logcheck system account <logcheck(a)linuxmafia.com>
To: root(a)linuxmafia.com
Subject: linuxmafia.com 2024-06-04 02:02 System Events
System Events
=-=-=-=-=-=-=
Jun 4 01:47:15 linuxmafia named[15622]: zone mpaoli.net/IN: Transfer started.
Jun 4 01:47:15 linuxmafia named[15622]: transfer of 'mpaoli.net/IN' from 96.86.170.226#53: connected using 96.95.217.99#52012
Jun 4 01:47:15 linuxmafia named[15622]: zone mpaoli.net/IN: transferred serial 1717468800
Jun 4 01:47:15 linuxmafia named[15622]: transfer of 'mpaoli.net/IN' from 96.86.170.226#53: Transfer completed: 1 messages, 6 records, 546 bytes, 0.064 secs (8531 bytes/sec)
Jun 4 02:00:09 linuxmafia named[15622]: zone mpaoli.net/IN: Transfer started.
Jun 4 02:00:09 linuxmafia named[15622]: transfer of 'mpaoli.net/IN' from 96.86.170.226#53: connected using 96.95.217.99#57758
Jun 4 02:00:09 linuxmafia named[15622]: zone mpaoli.net/IN: transferred serial 1717491608
Jun 4 02:00:09 linuxmafia named[15622]: transfer of 'mpaoli.net/IN' from 96.86.170.226#53: Transfer completed: 1 messages, 15 records, 1266 bytes, 0.072 secs (17583 bytes/sec)
----- End forwarded message -----
Ah ... sounds good.
So ... I'm guessing soon...ish, you'll have
2603:3024:180d:f100:50:242:105:34 (nsx.sunnyside.com.)
operational again (no extreme rush) ... or at least nsx.sunnyside.com.
regaining an operational AAAA that also works for DNS.
I noticed earlier it wasn't working ... then subsequently
you apparently dropped the AAAA record for it
(perfectly fine thing to do while it's not working!)
... I did try the IP directly - still no DNS response,
but I note also that that AAAA record hasn't been
restored yet either ... or any AAAA record for that domain.
$ eval dig @ns0.sunnysidex.com. +noall +answer +norecurse
nsx.sunnyside.com.\ A{,AAA}
nsx.sunnyside.com. 600 IN A 50.242.105.52
$
https://dnsviz.net/d/balug.org/Zl6vNw/responses/https://dnsviz.net/d/balug.org/ZmGAnw/responses/https://dnsviz.net/d/balug.org/ZmHuow/responses/
> 19 tickets closed almost immediately without comment
Let's see, if we have a ticketing system, and highly
incentivized folks to close tickets quickly, we get ...
lots of tickets closed quickly ... doesn't mean anything
gets fixed. And yes, have seen this before ... alas, even
in some departments/areas at some employers I've
worked at.
"Be careful what you measure." (And how one uses it).
Same employer, a much more astute manager with a
much better functioning department ... how did they
do it? They surveyed the customers, and used that
as a large measure of determining how well the technicians were
doing at getting issues solved ... not how quickly
the techs closed tickets. Alas, that highly well
performing department stuck out like a sore
thumb ... so ... eventually management "fixed"
that issue ... by subsuming that department into
the other, thus ensuring there wouldn't be such
a good standout to embarrass the rest.
Anyway, glad your Comcast issue finally got resolved.
< From: Michael Paoli <michael.paoli(a)berkeley.edu>
< Date: Tue, Jun 4, 2024 at 4:21\xe2\x80\xafPM
< Subject: Re: [BALUG-Admin] (forw) linuxmafia.com 2024-06-04 02:02
System Events
< To: Rick Moen <rick(a)linuxmafia.com>
< Cc: BALUG-Admin <balug-admin(a)lists.balug.org>, Al <aw009(a)sunnyside.com>
<
< And thirdly - relatively minor issue. Al's got
< (at least last I checked, yesterday or so) issues with
< 2603:3024:180d:f100:50:242:105:34 (nsx.sunnyside.com.)
< not responding.
On Thu, Jun 6, 2024 at 7:45 AM Al <aw009(a)sunnyside.com> wrote:
>
> The manager that took one of my tickets and refused to let it be closed has helped me to finally get my case resolved.
> I have tested access from AWS successfully, and the modem does in fact seem to have my /56 back in it instead of what
> looked very much like a dynamic /64.
> It's also amazing that anyone talked to me at all. I had 19 tickets closed almost immediately without comment.
>
>
> -------- Forwarded Message --------
> Subject: Comcast Service Ticket CR144883981
> Date: Thu, 6 Jun 2024 14:12:18 +0000
> From:
> To: awcomcast(a)sunnyside.com <awcomcast(a)sunnyside.com>
>
>
> Good morning,
>
>
>
> I am reaching out to you in regards to ticket CR144883981. This was in regards to reclaiming your original IPv6 prefix. I worked with our device support, and we were able to reclaim 2603:3024:180d:f100 for you. As of this morning, the IPv6 has been restored onto your modem.
>
>
>
>
>
> Thank you for using Comcast,
>
>
>
> Shana Rich
>
> Tech 4, CSSA (ABS)
>
> Complex & Strategic Service Assurance
>
> Avail Hours Mon-Fri, 8:00am – 4:30pm MST
>
> Comcast Business Services