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
----- Forwarded message from Al <awbalug(a)sunnyside.com> -----
Date: Tue, 4 Jun 2024 16:29:04 -0700
From: Al <awbalug(a)sunnyside.com>
To: Rick Moen <rick(a)linuxmafia.com>
Subject: Re: [BALUG-Admin] Comcast Business apparently blocking 5353 UDP Re:
linuxmafia.com "retry limit exceeded"
Rick, you're at the right place - that gear icon and right side panel
on business.comcast.com is just the right thing.
And I think the situation as you're outlining it is right to me. So
the answer to your question, broadly, is yes I think you have it
right.
If you end up at securityedge.comcast.com, IMHO you've gone too far.
My sense is that all that stuff is disabled back at the right side
panel...
Once SE (security edge) is disabled I think everything is. That
said, you're being smart about it - if symptoms persist, drill down
and look into individual
settings for various elements of SE and just make sure they're all off
- in case Comcast can't quite sort out how to actually disable stuff.
AFAIK however your nets (yours and Michaels) are unrestricted.
My tests from here are that access to both 96.86.170.229 and
96.95.217.99 on port 53 is not blocked (and not just those /32s but
the entire subnet in each case).
I am looking back over email from the last few days trying to sort out
where 73.189.65.18 crept into the conversation.
As I mentioned I have been unable to focus sufficiently on this the
last few days, and missed where that came from.
I also haven't looked closely enough at the discussion to see if what
I am trying to reproduce isn't exactly where you're having trouble.
I'll go back over the notes and see if I can pay more attention to the
details and whether I can actually add any insight to the discussion.
Al
----- End forwarded message -----
To clarify, I noticed "73.189.65.18" as the source of NOTIFYs for
Michael's domains, which can legitimately come _only_ from Michael's
authoritative nameserver, IP 96.86.170.229.
And 73.189.65.18 is Comcast's _own_ IP, not Michael's.
:r! dig -x 73.189.65.18 +short
c-73-189-65-18.hsd1.ca.comcast.net.
So, something is rotten, there. I'm immediately inclined to suspect
that Comcast is playing man-in-the-middle games with DNS traffic.
Which, if true, suggest Comcast acting like a rogue state security
agency or one operating on behalf of a totalitarian state. Not a good
look.