Search results for query "sapiro"
- 6019 messages
[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)
5 years, 1 month
[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, 5 months
[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, 5 months
[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
6 years
[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]
1 year, 4 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, 9 months
[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 ^[^#] :-)
5 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, 8 months
[MM3-users] Re: Message-Footer after migrating to Mailman3
by Abhilash Raj
> On Jul 9, 2021, at 9:15 AM, christopher.claus(a)tgcamberg1848.de wrote:
>
> Mark Sapiro wrote:
>>> ERROR 2021-05-24 16:22:22,895 1648 django.security.DisallowedHost Invalid HTTP_HOST header: 'tgc_mailman_web:8000'. The domain name provided is not valid according to RFC 1034/1035.
>>> WARNING 2021-05-24 16:22:22,896 1648 django.request Bad Request: /postorius/api/templates/list/homepage.gruppe.tgcamberg1848.de/list:member:regular:footer
>>> It appears you created the new template with Postorius, but there is an
>> issue for Postorius templates. Possibly your Django setting for
>> POSTORIUS_TEMPLATE_BASE_URL needs to be adjusted.
>>> Obviously I have a problem with the hostname. I set
>>> [code]
>>> POSTORIUS_TEMPLATE_BASE_URL=http://tgc_mailman_web:8000
>>> [/code]
>>> where tgc_mailman_web is my container name. This URL ist stored in the DB-table "template" for the name=list:member:regular:footer. A call to my fqdn or to localhost
>>> [code]
>>> wget http://localhost:8000/postorius/api/templates/list/homepage.gruppe.tgcamberg...
>>> [/code]
>>> will return the footer itself - this works fine. Therefore, should i set POSTORIUS_TEMPLATE_BASE_URL to http://localhost:8000?
>>> If that works, yes.
>
> Hi Mark,
>
> thanks for your reply and excuse my delay. I was very busy in the last weeks but made some tests. Newly created templates with POSTORIUS_TEMPLATE_BASE_URL=http://localhost:8000 did not work. I changed it to my fqdn - at the moment I am able to access the template via this URl (e.G. http://lists.example.de:8000/postorius/api/templates/list/homepage.lists.ex…)
> But if I try to send an email I got the following error:
You want the URL at which Postorius (postorius) is available from Core (mailman-core container). The default for that in the container images is set to http://mailman-web:8000. Does that not work for you?
If you want to verify, you want to exec into the Core’s container (`docker exec -it mailman-core bash`) and see if you can curl the URL from inside there. If you are using the default docker-compose-postorius.yaml then there is a /etc/hosts entry created by docker for the mailman-web container, hence `http://mailman-web:8000` works there (but it won’t work on the host, since docker doesn’t modify the host’s /etc/hosts).
There might also be a bug in play here which would cause such connection refused errors when subscribing/unsubscribing when there was a template configured for the list. Is that the case for you or are you seeing always when trying to send the email (which would imply that the Web container simply isn’t reachable from Core).
--
thanks,
Abhilash Raj (maxking)
4 years, 3 months
[MM3-users] Re: Core, Hyperkitty and Postorius releases
by Odhiambo Washington
On Sat, May 15, 2021 at 12:24 AM Abhilash Raj <maxking(a)asynchronous.in>
wrote:
>
>
> On Fri, May 14, 2021, at 2:16 PM, Odhiambo Washington wrote:
> > On Sat, May 15, 2021 at 12:01 AM Mark Sapiro <mark(a)msapiro.net> wrote:
> >
> > > On 5/14/21 1:54 PM, Odhiambo Washington wrote:
> > > >
> > > > /usr/local/include/sass
> > > >
> > > > That is the only thing found that is in the base system.
> > >
> > > And that's the one you want. What is it's mode?
> > >
> >
> > root@gw:/usr/home/wash # ls -al /usr/local/include/sass
> > total 104
> > drwxr-xr-x 2 root wheel 512 Apr 16 16:49 .
> > drwxr-xr-x 176 root wheel 10240 Apr 19 18:05 ..
> > -rw-r--r-- 1 root wheel 2369 Apr 8 11:08 base.h
> > -rw-r--r-- 1 root wheel 10742 Apr 8 11:08 context.h
> > -rw-r--r-- 1 root wheel 6632 Apr 8 11:08 functions.h
> > -rw-r--r-- 1 root wheel 6489 Apr 8 11:08 values.h
> > -rw-r--r-- 1 root wheel 198 Apr 8 11:08 version.h
> >
> > I imagined I needed an executable.
>
> This sounds like a result of you running `pip3 install sass`, probably
> with sudo
> which failed mid-way due to the exception you posted above.
>
Closer to the truth! It failed. I was running this from within the
virtualenv.
> Which OS are you using?
FreeBSD.
> On debian/ubuntu, you can install:
>
> sudo apt install sassc
>
Do I need to install sassc in the base OS or in the virtualenv?
> I am not exactly sure how it got removed during your upgrade
> to the new version of Mailman since it shouldn't affect your system
> packages.
>
The funny part is my MM3 used to run. Mark took so much hand-holding for me
to get it running.
Then one day I used the update process and things got hosed.
The happy part is that I had not put any production lists on MM3 as I
hadn't developed the confidence of managing it.
Did you install Mailman initially using system packages or instructions
> provided at [1]?
>
> [1]:
> https://docs.mailman3.org/en/latest/install/virtualenv.html#virtualenv-inst…
No. I relied on
https://wiki.list.org/DOC/Mailman%203%20installation%20experience. This is
way back!
Your new link is recent, no?
--
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", egrep -v "^$|^.*#" :-)
4 years, 6 months