Search results for query "sapiro"
- 5707 messages

[MM3-users] Re: Improve logging?
by Odhiambo Washington
On Tue, Jan 31, 2023 at 7:42 PM Mark Sapiro <mark(a)msapiro.net> wrote:
> On 1/31/23 00:40, Odhiambo Washington wrote:
> > Some entries in the log files can be very scary, while in actual sense
> they
> > are harmless.
> > Such inconsequential, but scary entiess can mess up the well-being of a
> > SysAdmin.
> > I humbly request for the logs related to posts by non-members to a MM3
> list
> > to be improved a little bit :-)
> > Here is the example in mailman.log:
> >
> > <cut>
> > Jan 31 10:03:54 2023 (92481) DISCARD: <
> > 2a1c588a6ccd47abbf57ee5fc61c9946(a)phellineconsultancy.co.ke>; ['The
> message
> > is not from a list member']
> > [31/Jan/2023:10:04:48 +0300] "GET
> > /3.1/users/1bad08f703fe4bc0a829f4bdce10fc8f HTTP/1.1" 200 253 "-" "GNU
> > Mailman REST client v3.3.5"
> > [31/Jan/2023:10:04:48 +0300] "GET
> > /3.1/users/1bad08f703fe4bc0a829f4bdce10fc8f/addresses HTTP/1.1" 200 473
> "-"
> > "GNU Mailman REST client v3.3.5"
> > Jan 31 10:18:09 2023 (92343) deque: do_confirm_verify
> > Traceback (most recent call last):
> > File
> >
> "/opt/mailman/mm/venv/lib/python3.9/site-packages/mailman/app/workflow.py",
> > line 69, in __next__
> > return step()
> > File
> >
> "/opt/mailman/mm/venv/lib/python3.9/site-packages/mailman/app/subscriptions.py",
> > line 476, in _step_send_confirmation
> > raise StopIteration
> > StopIteration
> > </cut>
> >
> > Is there a possibility to change the logging engine to just *fold* the
> last
> > 7 lines into "The message is not from a list member. It was discarded",
> or
> > something close?
>
> No.
>
> This entry
>
> Jan 31 10:03:54 2023 (92481) DISCARD:
> <2a1c588a6ccd47abbf57ee5fc61c9946(a)phellineconsultancy.co.ke>; ['The
> message is not from a list member']
>
> is a single entry about a discarded message.
>
> The next two are logging requests via the REST API that have nothing to
> do with the discard and are logged by a different module.
>
> The last entry with a traceback is yet another separate event. That one
> could probably be suppressed because raising StopIteration is a normal
> occurrence in workflow processing.
>
I was thiinking that they were all related.
The scary part though is the line that starts with ' Traceback'.
It's what I'd love to not-see unless there is a serious problem.
--
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)
2 years, 5 months

[MM3-users] Re: MM2 to MM3 on debian 10
by Gelpi Andrea
Il 27/04/20 18:59, Mark Sapiro ha scritto:
> On 4/27/20 8:26 AM, Gelpi Andrea wrote:
>> Hi, on a debian 10 with MM3 I'm trying to migrate form some old MM2
>> mailing lists. I know that not all can work.
>>
>> In my old lists I have email and regular expressions in
>> reject_these_nonmembers and discard_these_nonmembers
>>
>> After importing the list all these email are in non member list.
>>
>> All these email have Delivery status enabled.
>
>
> Delivery status is not relevant for non-members and only has to do with
> receiving list posts in any case.
>
> What version of Mailman core is this? There have been changes in
> `mailman import21` that may affect this, but an address in
> `reject_these_nonmembers` should be imported as a non-member with a
> moderation action of `reject` and similarly for `discard`.
>
> Note that regexps in *_these_nonmembers should be imported into the MM 3
> legacy *_these_nonmembers attributes. Some older versions of import21
> also imported non-regexp addresses here, but that was wrong.
>
Mailman V 3.2.1
Python V 3.7.3
Postorius V 1.3.2
Hiperkitty V 1.2.2
Yes reject_these_nonmembers has a moderation action of 'reject' and the
some for discard.
>
>> Does this mean that all of them will receive any message sent to the list?
>> The moderation rule is correct, but if I understood correct Delivery
>> status should be disabled.
>
>
> Delivery status is irrelevant for non-members. Only members are
> candidates for delivery.
>
Ok, but will non-members receive the list posts or only members will?
>
>> For migration I followed this link
>> https://docs.mailman3.org/en/latest/migration.html
>>
>> To migrate archives it states to run
>>
>> python manage.py hyperkitty ...
>>
>> I cant' find a manage.py on debian 10
>
>
> manage.py is a Django generic term for the Django admin command. You
> probably want something called django-admin or similar.
>
Yes in debain 10 exists django-admin.
Now I need to understand how to use it. It asks me to load a configuration.
>
>> A search shows the only /usr/share/mailman3-web/manage.py exists.
>>
>> Is there any documentation specific for debian?
>
> That would be up to Debian.
>
--
Gelpi ing. Andrea
--------------------------------------------------------------
It took the computing power of three C-64s to fly to the Moon.
It takes a 486 to run Windows 95. Something is wrong here.
--------------------------------------------------------------
5 years, 2 months

[MM3-users] Re: Confirm and Moderate Unsubscribe Requests
by Abhilash Raj
On Wed, Oct 21, 2020, at 3:35 PM, Brian Carpenter wrote:
>
> On 10/21/20 5:39 PM, Mark Sapiro wrote:
> > On 10/21/20 12:14 PM, Brian Carpenter wrote:
> >>
> >> Well I can't dictate that to my list owners and there is no confirm
> >> token sent with the moderation notice. Why include this option in
> >> Postorius when it can't be properly handled?
> >
> > Postorius is still a work in progress. The unsubscription policies are
> > in core and are exposed in Postorius. Certainly the ability to moderate
> > an unsubscription should be in Postorius, but it isn't yet. We are an
> > all volunteer project and there aren't that many of us, and perhaps I'm
> > overreacting, but the tone of some of your recent posts seems a bit
> > demanding.
>
> I apologize. I didn't think I was coming across demanding but I am
> somewhat exasperated at some of these issues. I have a list owner who is
> now going to get a moderated request notice everyday that he can't do
> anything about it.
>
> But my question still remains: why is this option in Postorius when it
> can't be handled properly? Surely the option can be easily removed, right?
I added the option in my drive to expose every possible Mailinglist settings via Postorius and missed the fact that we weren't actually able to moderate those requests.
Yes, this option can be hidden if it doesn't work until the next stable release. I hid one of the list settings in Postorius exactly because it didn't work, but this one slipped.
>
> Is the ability to list (via the pending moderation notices tab) and
> handle (as in the List owner can decide a moderation response) an
> unsubscribe moderation request there in Mailman core so that I can
> properly address it via Affinity?
Unfortunately no, there is a bug report open for it though and I have some done some analysis on root cause[1]. The bug turned out to be a more than a trivial one and I haven't been able to get to it yet.
[1]: https://gitlab.com/mailman/mailman/-/issues/768
>
> --
>
> Brian Carpenter
> Harmonylists.com
> Emwd.com
> _______________________________________________
> Mailman-users mailing list -- mailman-users(a)mailman3.org
> To unsubscribe send an email to mailman-users-leave(a)mailman3.org
> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
>
--
thanks,
Abhilash Raj (maxking)
4 years, 8 months

[MM3-users] Re: User settings triggers error
by Abhilash Raj
On Tue, Jun 16, 2020, at 12:47 PM, Mark Sapiro wrote:
> On 6/16/20 12:18 PM, Mark Dadgar wrote:
> > On Jun 16, 2020, at 11:47 AM, Mark Sapiro <mark(a)msapiro.net> wrote:
> >>> File "/usr/lib/python3/dist-packages/mailmanclient/restbase/connection.py" in call
> >>> 99. raise HTTPError(url, response.status, content, response, None)
> >>
> >> And gets a 500 from core.
> >>
> >>
> >>> During handling of the above exception (HTTP Error 500: b'A server error occurred. Please contact the administrator.'), another exception occurred:
> >>
> >>
> >> Which we aren't interested in.
> >>
> >> The next step is to look in core's mailman.log to see what the rest call
> >> was and the exception and hopefully traceback the caused the 500 response.
> >
> >
> > Here’s what’s logged during that error:
> >
> > Jun 16 12:16:54 2020 (1326) 127.0.0.1 - - "GET /3.1/users/mark(a)pdc-racing.net HTTP/1.1" 200 432
> > Jun 16 12:16:54 2020 (1326) REST request handler error:
> > Traceback (most recent call last):
> > File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1245, in _execute_context
> > self.dialect.do_execute(
> > File "/usr/lib/python3/dist-packages/sqlalchemy/engine/default.py", line 581, in do_execute
> > cursor.execute(statement, parameters)
> > psycopg2.errors.UndefinedFunction: operator does not exist: text = uuid
> > LINE 4: WHERE "user"._user_id = '05dcbeb4-b784-45eb-96f8-6f9e4b7ab6c...
> > ^
> > HINT: No operator matches the given name and argument types. You might need to add explicit type casts.
> >
> >
> > The above exception was the direct cause of the following exception:
> >
> > Traceback (most recent call last):
> > File "/usr/lib/python3.8/wsgiref/handlers.py", line 137, in run
> > self.result = application(self.environ, self.start_response)
> > File "/usr/lib/python3/dist-packages/mailman/database/transaction.py", line 50, in wrapper
> > rtn = function(*args, **kws)
> > File "/usr/lib/python3/dist-packages/mailman/rest/wsgiapp.py", line 218, in __call__
> > return super().__call__(environ, start_response)
> > File "falcon/api.py", line 232, in falcon.api.API.__call__
> > File "falcon/api.py", line 229, in falcon.api.API.__call__
> > File "falcon/api.py", line 582, in falcon.api.API._get_responder
> > File "/usr/lib/python3/dist-packages/mailman/rest/wsgiapp.py", line 131, in find
> > attribute = getattr(resource, name, MISSING)
> > File "/usr/lib/python3/dist-packages/mailman/rest/users.py", line 203, in _user
> > return user_manager.get_user_by_id(user_id)
> > File "/usr/lib/python3/dist-packages/mailman/database/transaction.py", line 85, in wrapper
> > return function(args[0], config.db.store, *args[1:], **kws)
> > File "/usr/lib/python3/dist-packages/mailman/model/usermanager.py", line 94, in get_user_by_id
> > if users.count() == 0:
> > File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3630, in count
> > return self.from_self(col).scalar()
> > File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3355, in scalar
> > ret = self.one()
> > File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3325, in one
> > ret = self.one_or_none()
> > File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3294, in one_or_none
> > ret = list(self)
> > File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3367, in __iter__
> > return self._execute_and_instances(context)
> > File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3392, in _execute_and_instances
> > result = conn.execute(querycontext.statement, self._params)
> > File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 982, in execute
> > return meth(self, multiparams, params)
> > File "/usr/lib/python3/dist-packages/sqlalchemy/sql/elements.py", line 287, in _execute_on_connection
> > return connection._execute_clauseelement(self, multiparams, params)
> > File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1095, in _execute_clauseelement
> > ret = self._execute_context(
> > File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1249, in _execute_context
> > self._handle_dbapi_exception(
> > File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1476, in _handle_dbapi_exception
> > util.raise_from_cause(sqlalchemy_exception, exc_info)
> > File "/usr/lib/python3/dist-packages/sqlalchemy/util/compat.py", line 398, in raise_from_cause
> > reraise(type(exception), exception, tb=exc_tb, cause=cause)
> > File "/usr/lib/python3/dist-packages/sqlalchemy/util/compat.py", line 152, in reraise
> > raise value.with_traceback(tb)
> > File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1245, in _execute_context
> > self.dialect.do_execute(
> > File "/usr/lib/python3/dist-packages/sqlalchemy/engine/default.py", line 581, in do_execute
> > cursor.execute(statement, parameters)
> > sqlalchemy.exc.ProgrammingError: (psycopg2.errors.UndefinedFunction) operator does not exist: text = uuid
> > LINE 4: WHERE "user"._user_id = '05dcbeb4-b784-45eb-96f8-6f9e4b7ab6c...
> > ^
> > HINT: No operator matches the given name and argument types. You might need to add explicit type casts.
> >
> > [SQL: SELECT count(*) AS count_1
> > FROM (SELECT "user".password AS user_password, "user".id AS user_id, "user".display_name AS user_display_name, "user"._user_id AS user__user_id, "user"._created_on AS user__created_on, "user".is_server_owner AS user_is_server_owner, "user"._preferred_address_id AS user__preferred_address_id, "user".preferences_id AS user_preferences_id
> > FROM "user"
> > WHERE "user"._user_id = %(user_id_1)s) AS anon_1]
> > [parameters: {'user_id_1': UUID('05dcbeb4-b784-45eb-96f8-6f9e4b7ab6cb')}]
> > (Background on this error at: http://sqlalche.me/e/f405)
> > Jun 16 12:16:54 2020 (1326) 127.0.0.1 - - "GET /3.1/users/05dcbeb4b78445eb96f86f9e4b7ab6cb/addresses HTTP/1.1" 500 59
> > Jun 16 12:16:54 2020 (1326) REST request handler error:
> > Traceback (most recent call last):
> > File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1245, in _execute_context
> > self.dialect.do_execute(
> > File "/usr/lib/python3/dist-packages/sqlalchemy/engine/default.py", line 581, in do_execute
> > cursor.execute(statement, parameters)
> > psycopg2.errors.UndefinedFunction: operator does not exist: text = uuid
> > LINE 4: WHERE "user"._user_id = '05dcbeb4-b784-45eb-96f8-6f9e4b7ab6c...
> > ^
> > HINT: No operator matches the given name and argument types. You might need to add explicit type casts.
>
>
> This looks like another manifestation of the issue reported at
> https://gitlab.com/mailman/django-mailman3/-/issues/35 and
> https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message…
>
> If you are running django-mailman3 1.3.3 and haven't upgraded to
> django-mailman3 1.3.4, see the above list post for a workaround.
This is a different issue actually, seems like a bug in Core.
Interesting part of the above traceback is:
> > File "/usr/lib/python3/dist-packages/mailman/rest/users.py", line 203, in _user
> > return user_manager.get_user_by_id(user_id)
and
> > FROM "user"
> > WHERE "user"._user_id = %(user_id_1)s) AS anon_1]
> > [parameters: {'user_id_1': UUID('05dcbeb4-b784-45eb-96f8-6f9e4b7ab6cb')}]
Which makes me think that we need to call `str()` on the UUID before passing it to sqlalchemy.
I wonder why it didn't show up already on our Mailman 3 instances, which also runs postgres. Perhaps, a different version of sqlalchemy triggers this. We'd need to look more into the specific version of sqlalchemy that causes this.
Mark Dadgar, Can you please let us know the version of sqlalchemy installed with your Mailman?
--
thanks,
Abhilash Raj (maxking)
5 years

[MM3-users] Re: User settings triggers error
by Mark Dadgar
On Jun 18, 2020, at 4:08 PM, Mark Sapiro <mark(a)msapiro.net> wrote:
> On 6/18/20 3:33 PM, Mark Dadgar wrote:
>>
>> Any thoughts on how to salvage ~20 years of list archives?
>
>
> The archives shouldn't be an issue. I don't think they are involved in
> the corruption, but anyway, hopefully you still have the archive mbox
> you imported. Then for the messages since then, you should be able to
> get a mbox from hyperkitty with something like
>
> https://example.com/hyperkitty/list/listname@example.com/export/arbitrary-n…
>
> with the obvious substitutions and appropriate start and end dates.
So in trying to download the recent archives ("export/trackjunkies-new.mbox.gz?start=2019-10-10&end=2020-06-28”), I end up with an 8.5MB file with one day’s worth of posts in it (2019-10-10).
I see these errors in the mailman-web.log:
Traceback (most recent call last):
File "/usr/lib/python3.8/email/_header_value_parser.py", line 2060, in get_msg_id
token, value = get_dot_atom_text(value)
File "/usr/lib/python3.8/email/_header_value_parser.py", line 1325, in get_dot_atom_text
raise errors.HeaderParseError("expected atom at a start of "
email.errors.HeaderParseError: expected atom at a start of dot-atom-text but found ' <BYAPR02MB5976132151FF19510269C44CB3940(a)BYAPR02MB5976.namprd02.prod.outlook.com>>'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/hyperkitty/views/mlist.py", line 332, in stream_mbox
msg = email.as_message()
File "/usr/lib/python3/dist-packages/hyperkitty/models/email.py", line 175, in as_message
msg["Message-ID"] = "<%s>" % self.message_id
File "/usr/lib/python3.8/email/message.py", line 409, in __setitem__
self._headers.append(self.policy.header_store_parse(name, val))
File "/usr/lib/python3.8/email/policy.py", line 148, in header_store_parse
return (name, self.header_factory(name, value))
File "/usr/lib/python3.8/email/headerregistry.py", line 602, in __call__
return self[name](name, value)
File "/usr/lib/python3.8/email/headerregistry.py", line 197, in __new__
cls.parse(value, kwds)
File "/usr/lib/python3.8/email/headerregistry.py", line 530, in parse
kwds['parse_tree'] = parse_tree = cls.value_parser(value)
File "/usr/lib/python3.8/email/_header_value_parser.py", line 2117, in parse_message_id
token, value = get_msg_id(value)
File "/usr/lib/python3.8/email/_header_value_parser.py", line 2064, in get_msg_id
token, value = get_obs_local_part(value)
File "/usr/lib/python3.8/email/_header_value_parser.py", line 1509, in get_obs_local_part
obs_local_part[1].token_type=='dot'):
IndexError: list index out of range
[pid: 1359|app: 0|req: 12933/12933] 76.102.110.193 () {60 vars in 1504 bytes} [Sun Jun 28 19:52:57 2020] GET /mailman3/hyperkitty/list/trackjunkies@pdc-racing.net/export/trackjunkies-new.mbox.gz?start=2019-10-10&end=2020-06-28 => generated 5572382 bytes in 4271 msecs (HTTP/1.1 200) 5 headers in 203 bytes (377 switches on core 1)
Thoughts? It would be nice to salvage the last 8 months of archives.
- Mark
-----
mark(a)pdc-racing.net | 408-348-2878
5 years

[MM3-users] Re: UnicodeEncodeError: 'ascii' codec can't encode character
by Marvin Gülker
Hi,
Am 11. Dezember 2019 um 13:49 Uhr -0800 schrieb Mark Sapiro:
>OK. I have verified that this is due to
><https://bugs.python.org/issue32330> and has actually been reported as
><https://gitlab.com/mailman/mailman/issues/441> and worked around in
>Mailman by <https://gitlab.com/mailman/mailman/merge_requests/350> which
>is included in Mailman 3.2.0 and up.
Thanks, and sorry for bugging you about old versions then. I'm going to
forward the problem to Ubuntu's bugtracker then.
But I now have a different problem. I've removed all offending messages
(it were more than just one that caused the UnicodeEncodeError), but I
still can't access the page for the held messages queue. It gives an
error 500, now with a different exception in the log. I've included it
below. It looks to me that the messages haven't properly been deleted.
What I did was this: for each offending message hash
1. I ran the DELETE query
2. I deleted the file from the file system
3. I ran the delete_message() function
I originally wanted to run only the delete_message() function, but a
quick check on the DB and the file system after running it for one hash
told me that it neither deletes the message from the DB nor from the
file system. So I did everything at once. I do have a backup of both the
DB and the filesystem from before I started this, in case this broke
something.
Is there something left that I have to do now?
Here's the exception:
Dec 12 08:34:30 2019 (9570) REST request handler error:
Traceback (most recent call last):
File "/usr/lib/python3.6/wsgiref/handlers.py", line 137, in run
self.result = application(self.environ, self.start_response)
File "/usr/lib/python3/dist-packages/mailman/database/transaction.py", line 50, in wrapper
rtn = function(*args, **kws)
File "/usr/lib/python3/dist-packages/mailman/rest/wsgiapp.py", line 214, in __call__
return super().__call__(environ, start_response)
File "falcon/api.py", line 215, in falcon.api.API.__call__ (falcon/api.c:2872)
File "falcon/api.py", line 189, in falcon.api.API.__call__ (falcon/api.c:2419)
File "/usr/lib/python3/dist-packages/mailman/rest/post_moderation.py", line 167, in on_get
resource = self._make_collection(request)
File "/usr/lib/python3/dist-packages/mailman/rest/helpers.py", line 159, in _make_collection
for resource in collection]
File "/usr/lib/python3/dist-packages/mailman/rest/helpers.py", line 159, in <listcomp>
for resource in collection]
File "/usr/lib/python3/dist-packages/mailman/rest/post_moderation.py", line 157, in _resource_as_dict
resource = self._make_resource(request.id)
File "/usr/lib/python3/dist-packages/mailman/rest/post_moderation.py", line 78, in _make_resource
resource['msg'] = msg.as_string()
AttributeError: 'NoneType' object has no attribute 'as_string'
--
Blog: https://mg.guelker.eu
5 years, 6 months

[MM3-users] Re: Clearing webserver cache - Nginx
by Odhiambo Washington
On Mon, Aug 5, 2024 at 8:19 PM Mark Sapiro <mark(a)msapiro.net> wrote:
> On 8/5/24 07:04, Odhiambo Washington via Mailman-users wrote:
> > I am having an ugly-looking https://mm3-lists.kictanet.or.ke/archives/
> page
> > because of cached content:
> >
> > ```
> > 2024/08/05 17:00:31 [error] 694#694: *9562 open()
> > "/opt/mailman/mm/static/CACHE/css/output.6dab123e4897.css" failed (2: No
> > such file or directory), client: 172.70.111.39, server:
> > mm3-lists.kictanet.or.ke, request: "GET
> > /static/CACHE/css/output.6dab123e4897.css HTTP/2.0", host: "
> > mm3-lists.kictanet.or.ke", referrer: "
> > https://mm3-lists.kictanet.or.ke/archives/"
> > 2024/08/05 17:00:31 [error] 694#694: *9564 open()
> ...
> > That IP address appearing there is not my actual IP, but Cloudflare's,
> > which is acting as proxy for the site.
>
>
> I **think** you may have something like
>
> location /static/ {
> alias /opt/mailman/web/static/;
> }
>
> in nginx on cloudflare, but since cloudflare is not the Mailman server,
> /opt/mailman/web/static/ doesn't exist there.
>
Actually, what I mean is that CF is proxying requests to the host named
m3-lists.kictanet.or.ke.
I do not have any configuration other than DNS proxying at CF.
I can't be sure on how to configure this without knowing the details of
> how requests get from cloudflare to mm3-lists.kictanet.or.ke and from
> there to the wsgi server.
>
When you ping m3-lists.kictanet.or.ke, the IP you get is CFs, not the
actual IP of the host.
So when you talk to m3-lists.kictanet.or.ke via a browser, it's CF IP who
you talk to and it in turn talks to the host directly.
So the IP address you see in the logs is CF's IP address, not yours, not
mine and CF are doing some caching. That's why
they are requesting for expired files.
> However, if cloudflare just proxies the request for /static/ to the
> Mailman server and nginx on that server has the above `location`
> directive, that may do it.
>
I suppose it's possible to configure Nginx to NOT ALLOW caching of content
from the /static/ location.
Being new to Nginx, time to say hi to uncle G again.
--
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
In an Internet failure case, the #1 suspect is a constant: DNS.
"Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)
[How to ask smart questions:
http://www.catb.org/~esr/faqs/smart-questions.html]
10 months, 3 weeks

[MM3-users] Re: A little stuck with installation of MM3 - ModuleNotFoundError: No module named 'flufl.lock'
by Odhiambo Washington
On Sat, 25 Jul 2020 at 22:11, Mark Sapiro <mark(a)msapiro.net> wrote:
> On 7/25/20 11:37 AM, Odhiambo Washington wrote:
> > On Sat, 25 Jul 2020 at 19:58, Mark Sapiro <mark(a)msapiro.net> wrote:
> >>
> >> This is a packaging glitch with the flufl modules. Remove and reinstall
> >> them.
> >>
> >> pip uninstall flufl.bounce flufl.i18n flufl.lock
> >> pip install flufl.bounce flufl.i18n flufl.lock
> >>
> >>
> > It would appear that luck isn't just on my side:
> >
> > root@gw:/opt/mailman/mm # pip uninstall flufl.bounce flufl.i18n
> flufl.lock
> ...
>
>
> You need to run these pip commands in your venv. I.e. do this
>
> > [root@gw /opt/mailman/mm]# source /opt/mailman/mm/venv/bin/activate
>
> before the pip uninstall and pip install.
> <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/>
That has solved the problem. Thank you very much.
I have taken note of that. for my NOTES.
Finally, I have adapted your init script to get some rudimentary one that I
could use on FreeBSD.
I have to change /opt/mailman to be owned by mailman3:mailman3 (because I
have "live" MLs on this server, using mailman-2.1.34.
I am not sure if they can co-exist. I suppose they could, but what might be
the security implication, if any??
This is what the init script looks like (rudimentary!!):
(venv) [root@gw /usr/local/etc/rc.d]# less mailman3
### BEGIN INIT INFO
# Provides: GNU Mailman
# Short-Description: Mailman3 Service
# Description: service control for Mailman3
### END INIT INFO
PATH=/opt/mailman/mm/bin:/opt/mailman/mm/venv/bin:/usr/sbin:/usr/bin:/bin:/sbin:
DESC="GNU Mailman service"
DAEMON=/opt/mailman/mm/bin/mailman
NAME=mailman
USER=mailman3
GROUP=mailman3
# Needed by click
export LANG=en_US.UTF-8
# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0
# Load the VERBOSE setting and other rcS variables
#. /lib/init/vars.sh
# Define LSB log_* functions.
# Depend on lsb-base (>= 3.2-14) to ensure that this file is present
# and status_of_proc is working.
#. /lib/lsb/init-functions
case "$1" in
start)
[ "$VERBOSE" != no ] && echo "Starting $DESC" "$NAME"
# use --force to remove a stale lock.
/usr/local/bin/sudo -u $USER $DAEMON start --force
;;
stop)
[ "$VERBOSE" != no ] && echo "Stopping $DESC" "$NAME"
/usr/local/bin/sudo -u $USER $DAEMON stop
;;
status)
/usr/local/bin/sudo -u $USER $DAEMON status
;;
reopen)
/usr/local/bin/sudo -u $USER $DAEMON reopen
;;
restart)
log_daemon_msg "Restarting $DESC" "$NAME"
/usr/local/bin/sudo -u $USER $DAEMON restart
;;
*)
echo "Usage: $SCRIPTNAME {start|stop|status|reopen|restart}" >&2
exit 3
;;
esac
It does start mailman3 for sure, but also complains after a few seconds
with the message:
(venv) [root@gw /usr/local/etc/rc.d]#
*/opt/mailman/mm/venv/lib/python3.7/site-packages/mailman-3.3.2b1-py3.7.egg/mailman/rest/wsgiapp.py:180:
DeprecatedWarning: Call to deprecated function __init__(...). API class may
be removed in a future release, use falcon.App instead.*
* **kws)*
But:
(venv) [root@gw /usr/local/etc/rc.d]# ps ax | grep mailman
11677 - Is 0:00.01 /usr/local/bin/python
/usr/local/mailman/bin/mailmanctl -s -q start (python2.7)
15860 - S 0:07.86 /usr/local/bin/python
/usr/local/mailman/bin/qrunner --runner=ArchRunner:0:1 -s (python2.7)
16310 - S 0:07.43 /usr/local/bin/python
/usr/local/mailman/bin/qrunner --runner=BounceRunner:0:1 -s (python2.7)
16928 - S 0:07.07 /usr/local/bin/python
/usr/local/mailman/bin/qrunner --runner=CommandRunner:0:1 -s (python2.7)
17335 - S 0:07.47 /usr/local/bin/python
/usr/local/mailman/bin/qrunner --runner=IncomingRunner:0:1 -s (python2.7)
17975 - S 0:07.02 /usr/local/bin/python
/usr/local/mailman/bin/qrunner --runner=NewsRunner:0:1 -s (python2.7)
18419 - S 0:20.06 /usr/local/bin/python
/usr/local/mailman/bin/qrunner --runner=OutgoingRunner:0:1 -s (python2.7)
19015 - S 0:07.13 /usr/local/bin/python
/usr/local/mailman/bin/qrunner --runner=VirginRunner:0:1 -s (python2.7)
19131 - I 0:00.15 /usr/local/bin/python
/usr/local/mailman/bin/qrunner --runner=RetryRunner:0:1 -s (python2.7)
27273 - Is 0:01.64 /opt/mailman/mm/venv/bin/python
/opt/mailman/mm/venv/bin/master --force -C /opt/mailman/mm/mailman.cfg
(python3.7)
28526 - S 0:01.70 /opt/mailman/mm/venv/bin/python
/opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/mailman.cfg
--runner=archive:0:1 (python3.7)
28627 - I 0:01.77 /opt/mailman/mm/venv/bin/python
/opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/mailman.cfg
--runner=bounces:0:1 (python3.7)
28988 - S 0:01.70 /opt/mailman/mm/venv/bin/python
/opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/mailman.cfg
--runner=command:0:1 (python3.7)
29341 - S 0:01.69 /opt/mailman/mm/venv/bin/python
/opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/mailman.cfg
--runner=in:0:1 (python3.7)
29978 - S 0:01.68 /opt/mailman/mm/venv/bin/python
/opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/mailman.cfg
--runner=lmtp:0:1 (python3.7)
30843 - S 0:01.70 /opt/mailman/mm/venv/bin/python
/opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/mailman.cfg
--runner=nntp:0:1 (python3.7)
31541 - S 0:01.70 /opt/mailman/mm/venv/bin/python
/opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/mailman.cfg
--runner=out:0:1 (python3.7)
31675 - S 0:01.70 /opt/mailman/mm/venv/bin/python
/opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/mailman.cfg
--runner=pipeline:0:1 (python3.7)
32181 - S 0:01.77 /opt/mailman/mm/venv/bin/python
/opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/mailman.cfg
--runner=rest:0:1 (python3.7)
33166 - I 0:01.65 /opt/mailman/mm/venv/bin/python
/opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/mailman.cfg
--runner=retry:0:1 (python3.7)
33694 - S 0:01.70 /opt/mailman/mm/venv/bin/python
/opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/mailman.cfg
--runner=virgin:0:1 (python3.7)
34600 - S 0:01.69 /opt/mailman/mm/venv/bin/python
/opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/mailman.cfg
--runner=digest:0:1 (python3.7)
41250 - S 0:00.01 /opt/mailman/mm/venv/bin/python
/opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/mailman.cfg
--runner=rest:0:1 (python3.7)
41533 - S 0:00.01 /opt/mailman/mm/venv/bin/python
/opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/mailman.cfg
--runner=rest:0:1 (python3.7)
98450 - I 0:00.45 httpd: mailman-web (httpd)
59886 0 S+ 0:00.00 grep mailm
Assuming that I am using mod_wsgi with Apache, and that I have configured
apache right using
https://wiki.list.org/DOC/Mailman%203%20installation%20experience?action=At…
..
should I be able to access the MM3 web UI??
At that point, I am feeling somewhat confused as to what to try next.
(venv) [root@gw /opt/mailman/mm/var/logs]# less mailman.log
Jul 25 22:53:16 2020 (40670) Master started
Jul 25 22:53:18 2020 (42036) bounces runner started.
Jul 25 22:53:18 2020 (45205) out runner started.
Jul 25 22:53:19 2020 (41191) archive runner started.
Jul 25 22:53:19 2020 (46670) retry runner started.
Jul 25 22:53:19 2020 (44567) nntp runner started.
Jul 25 22:53:19 2020 (43069) in runner started.
Jul 25 22:53:19 2020 (46960) virgin runner started.
Jul 25 22:53:20 2020 (45720) pipeline runner started.
Jul 25 22:53:20 2020 (47326) digest runner started.
Jul 25 22:53:20 2020 (43755) lmtp runner started.
Jul 25 22:53:20 2020 (45922) rest runner started.
[2020-07-25 22:53:20 +0300] [45922] [INFO] Starting gunicorn 20.0.4
[2020-07-25 22:53:20 +0300] [45922] [INFO] Listening at:
http://127.0.0.1:8001 (45922)
[2020-07-25 22:53:20 +0300] [45922] [INFO] Using worker: sync
[2020-07-25 22:53:20 +0300] [54732] [INFO] Booting worker with pid: 54732
[2020-07-25 22:53:20 +0300] [55467] [INFO] Booting worker with pid: 55467
Jul 25 22:53:21 2020 (42743) command runner started.
How do I access the web UI for MM3 now?
Thanks in advance.
--
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)
4 years, 11 months

[MM3-users] Re: postfix malformed address with confirm replies
by Stephen Mats Mats
> On Feb 28, 2021, at 01:32, Stephen J. Turnbull <turnbull.stephen.fw(a)u.tsukuba.ac.jp> wrote:
>
> Mark Sapiro writes:
>> On 2/27/21 4:36 AM, Stephen J. Turnbull wrote:
>
>>> is legal, and I think that most servers will accept it, but RFC
>>> 5321 sets a limit of 64 octets on mailboxes[1], and your
>>> confirmation mailbox is 67 octets.
>>
>> Since the -confirm+<token> part is fixed at 49 octets, this would imply
>> a limit in list names of 15 octets. Ouch!
>
> I'm pretty sure we would have run into this before, if there were a
> lot of servers out there imposing this limit. 15 octets is pretty
> darn short, there are probably quite a few list names out there longer
> than that. Not to mention that the RFC itself says "you SHOULD NOT be
> a jerk about this". :-) So I don't think this is a big problem in
> practice, and I hope Steve can reconfigure the obstructive server to
> not be so picky.
>
To be clear the 'obstructive server’ is mailman-core. :)
[ec2-user@ip-172-31-18-xxx ~]$ telnet 172.19.199.2 8024
Trying 172.19.199.2...
Connected to 172.19.199.2.
Escape character is '^]'.
220 mailman-core GNU Mailman LMTP runner 2.0
LHLO ip-172-31-18-xxx.us-west-2.compute.internal
250-mailman-core
250-SIZE 33554432
250-8BITMIME
250 HELP
MAIL FROM:<stephen.s.w.matsmats(a)gmail.com>
250 OK
RCPT TO:<matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55856(a)mm3.aca-aws.s.uw.edu>
553 5.1.3 Error: malformed address
RCPT TO:<matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55(a)mm3.aca-aws.s.uw.edu>
250 OK
quit
221 Bye
Didn’t really dig but my guess would be the LMTP from aiosmtpd.lmtp is actually throwing the 553.
For a bit of context, of the 25,801 mailman2 lists we have here at University of Washington 5,211 have names longer than 15 characters (we don’t have any lists with multibyte characters in their names). Our longest list name is 33 characters. I didn’t dump every config to see the number of lists that subscribe_policy set to confirm or confirm and approve. But I expect it’s a small minority.
steve
> For Mailman, I doubt we need a full SHA1 (?) for the purpose. We can
> truncate the thing, probably opportunistically (ie, so the whole
> confirmation mailbox fits in 64 octets, or we could even parse the
> bounce message and resend only if we run into a problem).
>
> Steve
> _______________________________________________
> Mailman-users mailing list -- mailman-users(a)mailman3.org
> To unsubscribe send an email to mailman-users-leave(a)mailman3.org
> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
4 years, 4 months

[MM3-users] Non-ascii characters missing from Pipermail archive txt and gz downloads
by Mark Dale
Mailman 2.1.34
Debian 10
Postfix
Hi
I'm hoping someone can shine a light on character encoding issue I've encountered.
A plain-text email with non-ascii characters in the body gets posted to the list.
As per Mark Sapiro's guide I've captured the incoming message to file.
- https://www.mail-archive.com/mailman-users@python.org/msg73469.html
The message is received by Mailman with the non-ascii characters displaying correctly.
The header of that message has:
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.9.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-AU
Content-Transfer-Encoding: 8bit
In the list's mbox file and archive webpage, the message displays the non-ascii characters correctly.
In the archive's downloaded .txt (and also .gz) file, the non-ascii characters are missing and displayed as "?".
I've copied the message text in below, from both the correct one from the email and the erroneous .txt file. Hopefully they won't get scrambled up when I send this.
Any advice on getting the non-ascii characters written into the archive .txt file would be gratefully received.
Thanks,
Mark
=== Message text as okay in mbox and as shown on the archive webpage ===
If one goes by the definition of veḷippaṭai as given in the Tamil Lexicon that the meaning of an ambiguous word should be disambiguated by a qualifying word, then aruvi āmpal does not conform to that definition since in the case of aruvi āmpal in Patiṟṟuppattu 63, aruvi is really made up of aru+vi, a compound. Moreover, the expression aṭai aṭuppu aṟiyā is already there to clarify that āmpal is a number and not a flower. Thus, aruvi simply provides information in addition to aṭai aṭuppu aṟiyā that āmpal is not a flower. The modern commentator Aruḷampalavaṉār also does not call it veḷippaṭai.
===
=== Message text with missing characters in te archive's txt and gz downloads ==
If one goes by the definition of ve?ippa?ai as given in the Tamil Lexicon that the meaning of an ambiguous word should be disambiguated by a qualifying word, then aruvi ?mpal does not conform to that definition since in the case of aruvi ?mpal in Pati??uppattu 63, aruvi is really made up of aru+vi, a compound. Moreover, the expression a?ai a?uppu a?iy? is already there to clarify that ?mpal is a number and not a flower. Thus, aruvi simply provides information in addition to a?ai a?uppu a?iy? that ?mpal is not a flower. The modern commentator Aru?ampalava??r also does not call it ve?ippa?ai.
===
4 years, 2 months