Re: Changing subscription address
by Abhilash Raj
> On Mar 18, 2021, at 8:29 PM, Stephen J. Turnbull <turnbull.stephen.fw(a)u.tsukuba.ac.jp> wrote:
>
> Thank you for your comments, Allan!
>
> Allan Hansen writes:
>
>> On 3/15/21, 21:28 , "Stephen J. Turnbull" <turnbull.stephen.fw(a)u.tsukuba.ac.jp> wrote:
>
>>> In the 'Mailman Settings' screen, List-based Preferences' tab,
>
>> You may mean the 'Subscriptions' tab.
>
> I did mean the 'List-Based Preferences' tab. The 'Subscriptions' tab
> is non-functional. It's in some sense aesthetically more pleasing
> than 'List-Based Preferences', but you have to do extra, unnecessary
> work to get anything done from the 'Subscriptions' tab. It may make
> sense to just get rid of the current 'Subscriptions' tab and rename
> 'List-based Preferences' to 'Subscriptions'.
+1 We can do that. I don’t think I’ve ever used the subscriptions tab
myself to do anything.
>
> The only functionality of 'Subscriptions' over 'List-based
> Preferences' is that it lists you once for each role and address
> (member, non-member, moderator, owner) that you have for that list.
> This is possibly more confusing than helpful for non-owners.
> Moderators get informed of their role every time they need to do
> something. And it's possible to be both a member and a non-member of
> a list, which is pretty confusing.
Yeah, technically you can be subscribed to a list with all possible roles at
the same time.
>
>> Under 'User profile for <name>', under the 'E-mail Addresses', add
>> button to ensure that 'Primary E-mail' is used for all lists.
>
> If you define "ensure" strictly, this would be a fair amount of work
> because it would require overriding the normal "cascade" of
> preferences, and incidentally a way to turn off that override. I'd
> rather not make the implementation so complicated.
>
> There does need to be a way to revert each option to inherit, and
> there currently doesn't seem to be one. The 'Preferences' interface I
> described in the previous post doesn't provide it either. I will
> think about that.
The implementation of this isn’t very difficult, but the UX of this is
something I don’t know how to implement in that page to be very
honest.
> It should be normally unnecessary to use the 'Preferences' interface,
> because the default subscription should be "use primary address". For
> people using the current versions of Mailman 3, who are already have a
> bunch of subscriptions with the same *explicit* address, I think it is
> good enough. But if there's demand for a "revert all to use primary
> address" button, that would be easy enough to add.
We do already have ability to switch from an explicit address to Primary
Address subscription. I would imagine it would be more than just a
button, but more like a dropdown to choose an email or primary address
and switch all subscriptions to that.
> Here's why I think such a button would be unnecessary in future
> versions of Mailman. What should happen if you subscribe by an
> address not already known to Mailman without creating an account in
> Postorius is
>
> 1. Mailman registers the address.
> 2. Mailman creates a User object to "own" that address, and makes
> that address the primary address for the User.
> 3. Mailman creates a subscription which links the User (not the
> address) to the mailing list so that the primary address is used.
>
> For addresses already known to Mailman, Mailman should look up the
> User registered to that address, and if the subscription address is
> the primary address, set "use primary address" for the subscription.
This is how Core actually does work[1] if you subscribe via Email and you
already have a primary address. It will lookup a user using the address
and if the address is the primary address of the user, it will subscribe
the primary address.
However, if it isn’t the primary address, and this is a new address, it will
subscribe the address instead of user because the address isn’t
verified at this point and hence can’t be a primary address. We could
extend the subscription workflow to add an additional step to set this
address as primary and subscribe the primary address.
Postorius has the full ability to define its own workflow because REST
API provides full expression capability and doesn’t enforce anything.
Previous versions didn’t had support for subscribing as Primary Address,
but that has since changed and is the default one in the dropdown.
This is for authenticated subscription, the anonymous subscribe works
similar to email -join command. Mass-subscribe is probably working the
same way.
[1]: https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/commands/eml_m…
>
> In this scheme, as far as I can see, your user doesn't need to do
> anything with the account until she wants to change the address. At
> that point she needs to activate the account:
>
> - visit her personal options page in Postorius
> - request a password reset (she doesn't have one yet, so she can't log
> in)
> - click the special link
> - set a password or link a social media account, and
> - finally change the address.
>
> Note that this is the bare minimum of work for her. She has to prove
> she can read mail at that address. Anything less, and *anybody* can
> change her subscriptions. We could omit requiring a new password,
> but it's not a lot of work once you've got to this point, while the
> "request, wait for email, click link, do work" dance is pretty
> annoying. Why make someone do it again next time?
>
> This is problematic if she's already lost access to the old address,
> of course, but in that case you're probably going to have to intervene
> anyway.
>
> I don't think Postorius requires her to do anything else, but if she
> wants to she can update her profile at that point.
>
> I have to check the code, and probably also ask Barry and the other
> folks who designed the current subscription mechanism in case there's
> some fatal flaw in the scheme above. But I think that should do what
> almost all "one address" users want, and it's probably what the
> majority of people who have multiple addresses and use different ones
> for different purposes want most of the time, too.
Like mentioned above, it should be possible to do what you suggest. I
am getting into the implementation details here, but the Subscription
workflow would need an additional flag that would verify an address
and use the flag to determine if it should subscribe the address or
addresses’s user if an address is provided to the workflow.
>
> Note to self of possible problems: (1) The primary address is where
> you would send administrative mail to the account holder and that
> might not be an appropriate address for the default subscription.
> (2) This is a pretty radical change from the current situation, so it
> might need to be an option for the list or domain owner.
>
>> And, indeed, new subscriptions should default to 'Use Primary.'
>
> I agree. I'm astonished that there are situations where they don't,
> to be quite honest. That's the whole point of having accounts in the
> first place -- having *one* source of information about the user
> rather than spreading it out over a bunch of lists.
>
>> Is that possible now?
>
> It is already the default for someone who subscribes by logging in to
> Postorius. I assume that it is *not* the default for someone who
> subscribes by email or mass subscription, otherwise you wouldn't have
> the problem.
>
>> Does a member have to have an account for me to set it up thus for
>> them?
>
> Yes. The primary address is an attribute of the account.
> Subscriptions can't know anything about a primary address unless there
> is an account. However, it should be possible to make this default
> for an account that hasn't been activated yet, such as in a mass
> subscription.
Primary Address is also an attribute of the Mailman User, so it should
be possible for an admin to set that for a user if the user doesn’t
have an account. When they sign up, they’d be able to manage
and update accordingly.
I have started working on designing a User management page[2] in
Core which should make it easy for superuser to manage several
things about a User, including the ones that don’t have an account
in Postorius to manage their own. The list os “tasks” an admin can
do isn’t decided, but please feel free to write comments there about
things you’d like to be able to do as a server admin.
[2]: https://gitlab.com/mailman/postorius/-/merge_requests/605
>
> Regards,
> 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/
--
thanks,
Abhilash Raj (maxking)
4 years, 3 months
Re: Mailman backend maintenance task
by Eugenio Jordan (external)
Dear Steve:
I really appreciate you also took your time to provide more insights on
how Mailman works, and how their different components interact each
other.
There are two "minor" tasks and one major task that we would need to
accomplish within PostGRESQL, namely rebuilding the index related to
hyperkitty_email table primary key, rebuilding also another index on
the very same table supporting an uniqueness constraint (these would be
the minor); and running vacuum full on the whole database to
effectively reduce the size of precisely hyperkitty_email table, which
is the largest table in this database, and if possible retrieve back to
the SAN the extra space we had to add to cope with that very table size
increasing.
The way vacuum full locks the tables are, among all the locking
mechanisms provided by PostGRESQL to guarantee the transactional
integrity, one of the strongest, if not the strongest one (as far as I
know, the tables are more ore less recreated when running vacuum full).
The idea we were considering was more or less stopping all of the
components, then starting up only PostGRESQL, and then performing each
one of the mentioned tasks. Actually our PG release allow "online"
indices rebuild (drop + rebuild concurrently), but we did not want to
assume the risk if, for whatever reason, new records were added to the
table breaking the uniqueness of both constraints (fixing this cases
turns out to be a real pain in most cases). Alternatively, we could
lock the table ourselves to get more or less the same effect, true,
although, after all, the final impact on potential connections willing
to run DML would be the same. In other words, rather than having lots
of transactions coming from whether core component processes or web
component processes fail, we prefer to stop everything. But it's got of
course the worst downside: we would receive
Let me please now go back to your kind explanation to see if I did get
things correctly. You mention that regardless the connectivity that
Mailman's core processes might have with the database, the emails will
be received by and queued until the connection is back again and they
can be delivered to the distribution lists' members. Could you please
confirm whether this task would be actually delegated to Postfix (or
any MTA integrated with Mailman)? If so, this is actually what we need:
we could afford delaying the reception a couple of days, whilst we are
sure that no mail will be lost.
Once more, thanks a lot for your kind help. Best regards.
-----"Stephen J. Turnbull" <[1]stephenjturnbull(a)gmail.com> wrote: -----
To: [2]eugenio.jordan(a)esa.int
From: "Stephen J. Turnbull" <[3]stephenjturnbull(a)gmail.com>
Date: 08/24/2021 05:33PM
Cc: [4]mailman-users(a)mailman3.org
Subject: [MM3-users] Mailman backend maintenance task
Hi, Eugenio,
I wrote this earlier but am in the middle of moving my office so my
mail has been intermittent. I have been following your discussion
with Abhilash, and he's definitely the expert, especially if you are
using the containers he creates and distributes. But there's some
information here he hasn't mentioned yet.
Please consider the following discussion to be background that allows
you to understand some of the considerations. I've only run the
Mailman 3 suite with all three running constantly on the same host, so
I have no experience with this kind of issue.
[5]eugenio.jordan(a)esa.int writes:
> Our customer is currently using PostGRESQL as backend, and we would
> like to perform some maintenance tasks, namely running vacuum full,
> or at least trying to rebuild hyperkitty_email primary key related
> index. We have been asked on the real impact of putting in place
> such initiative. Though the latter is related to archiving, I
> haven't found a way to stop just Hyperkitty or Django related
> processes other than stopping Mailman's core, hence preventing
> mails addressed to distribution lists from being delivered, could
> you please confirm if I am correct?
Mailman core can certainly run without either Postorius or HyperKitty.
Controlling Mailman core (moderation, helping users) without Postorius
is annoying, but it can be done. If you stop the HyperKitty process,
what should happen, I believe, is that posts for archiving will
accumulate in the 'archive' queue until HyperKitty is available again.
It's been a while since I studied this so I could be completely wrong,
but as I understand it HyperKitty and Postorius are not daemon
processes. Rather, they are WSGI applications, which means they are
subprocesses spawned by your webserver, and controlled by it. In
order to keep them from running, you would reconfigure the webserver
to not call those WSGI applications. How that is done is specific to
the webserver and the WSGI module. If you are running from Docker
containers, most likely, you can just stop their containers.
The larger problem is that Mailman core uses a RDBMS. Normally both
Django and Mailman are referring to the same RDBMS, PostgreSQL in your
case. I'm not familiar with the vaccuum operation; if it requires
taking the whole RDBMS down, and Mailman is running on that RDBMS,
you're out of luck. Mailman can accept posts and queue them, but it
can't deliver them to subscribers without access to the RDBMS tables.
If it's just a matter of locking some tables while other are
available, then it should work because the tables used by core and
HyperKitty are disjoint as far as I know. (I think Postorius and
HyperKitty both use Django's user tables for authorization, so at
least for those tables both Postorius and HyperKitty will have to be
down, but core can continue running because its database is completely
separate.)
> Regarding the former, as far as I have read, the "mappings" lists
> -> addresses are stored just in the database, so if we run some
> kind of procedure or task like vacuum which will lock exclusively
> tables, or want anyway to have the database stopped for a cold
> backup or whatever, Mailman willl not work, that is, again the
> mails addressed to the distribution lists will not be
> delivered. Will you please confirm this point, too?
That depends on how "vacuum" works. If you can tell the RDBMS not to
lock Mailman core's tables, it can continue to run. Definitely if the
database is not running, Mailman will continue to receive and store
the posts, but it won't be able to distribute mail to subscribers
until its tables are available again. At that point the queued posts
will be processed normally, except that if there's a large backlog,
they won't go out in a quick burst, it may take a while.
One possible worry, depending on how you are connected to the
Internet, is that your provider may interpret the sudden burst of
outgoing mail when Mailman comes back on line as spam or some other
sort of mischief. Mailman has no way to throttle this: it feeds
messages to the MTA until the MTA says "stop". Then it waits until
the MTA is ready again.
Regards,
Steve
This message is intended only for the recipient(s) named above. It may contain p
roprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination
is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropri
ate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Prot
ection Officer (dpo(a)esa.int)
References
1. mailto:stephenjturnbull@gmail.com
2. mailto:eugenio.jordan@esa.int
3. mailto:stephenjturnbull@gmail.com
4. mailto:mailman-users@mailman3.org
5. mailto:eugenio.jordan@esa.int
3 years, 9 months
Re: Postorius confirmation mails shown in uwsgi-error.log but not sent
by Abhilash Raj
On Mon, Mar 30, 2020, at 5:33 AM, Ralph Seichter wrote:
> * Mark Sapiro:
>
> >> $ grep ^EMAIL settings.py
> >> EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend'
> >> EMAIL_HOST = 'localhost'
> >> EMAIL_PORT = 25
> >
> > but is this perhaps overridden in a settings_local.py file?
>
> I don't have a local settings file. I cloned the suite from GitLab[1]
> master branch and modified the existing settings.py, based on Mailman's
> documentation.
>
> [1] https://gitlab.com/mailman/mailman-suite.git
>
> I just verified that EMAIL_BACKEND is not redefined anywhere:
>
> $ grep -r 'mail\.backends' .
> Binary file ./__pycache__/settings.cpython-38.pyc matches
> ./settings.py:EMAIL_BACKEND =
> 'django.core.mail.backends.smtp.EmailBackend'
> ./settings.py:# EMAIL_BACKEND =
> 'django.core.mail.backends.filebased.EmailBackend'
>
> I commented out the "if DEBUG == True" lines, which explains match
> number three. As far as I can see, the mail backed definition for Django
> is as it should be.
>
> I could provide the differences between my settings.py and the Git HEAD
> version if you think that might help.
It definitely would help if you paste the diff of the settings required.
Also, can you jump into a django shell and see if you can get any exceptions trying to send emails:
$ python manage.py shell
>>> from django.core.mail import send_mail
>>> send_mail(
'Subject here',
'Here is the message.',
'from(a)example.com',
['to(a)example.com'],
fail_silently=False,
)
I picked it up from the Django's docs and perhaps fail_silently=False would give some exceptions. Please make sure you tail the logs for any connections.
Abhilash
>
> -Ralph
> _______________________________________________
> 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, 2 months
Re: Postorius no connection to REST API
by Stephen J. Turnbull
Richard,
Thanks for the details and the pointer to the full configs. That
makes it possible to take a look, but I can't spend much time on it
until next week.
I'll see if I can prod Abhilash who is more expert than I on all this
stuff (I just use mod_wsgi), but there's some more urgent (sorry, but
it's security) stuff going on, and his absence speaks for his $DAYJOB,
I guess.
Richard Rosner writes:
> That is entirely possible @Stephen. You can see the entire apache config a few posts back plus the additions from @Mark and mine from the last post. As I interpret it, apache is reverse proxying to the uwsgi app, now through http instead of the socket. But I have no idea if that's the right way round. I'm not sure is the config file templates for apache, nginx and uwsgi that you get with the Debian packages are added by the Debian team or if they are there any way and just have been modified to the Debian file layout, but I'd guess either way it's not that likely that they wrote it the wrong way around. But I'm not too experienced to be able to translate the nginx config to apache to see if that would result in something different.
>
> Also, while the nginx config is written as a standalone website, the apache config seems to have been written to just create a /mailman3 site under an existing website, while I use it as a standalone site. So it's entirely possible that I missed something when I modified the website from mailman2 to serve mailman3, but then it shouldn't have been able to show the website at the beginning.
> _______________________________________________
> 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/
>
>
3 years, 10 months
Re: User settings triggers error
by Mark Dadgar
On Jun 16, 2020, at 6:52 PM, Mark Dadgar <mark(a)pdc-racing.net> wrote:
>> 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.
>
> So one thing I realized: this is the server where I migrated the mm3 databases from sqlite to postgres via pgloader and had the truncated index name warnings that I posted about a while back.
>
> Don’t know if that’s a factor but I thought I’d mention it.
>
>> Mark Dadgar, Can you please let us know the version of sqlalchemy installed with your Mailman?
>
>
> python3-sqlalchemy/focal,now 1.3.12+ds1-1ubuntu2
There is definitely something sketchy going on here. As an admin, I am not getting accurate subscription status about people on a list. For example, I search for a list member, find their listing, check the box and click Unsubscribe Selected, and get an error because it turns out that they had already unsubscribed themselves previously. But Postorius thought they were still subscribed.
mailman.log errors:
--
Jun 18 14:18:47 2020 (1302) 127.0.0.1 - - "GET /3.1/lists/trackjunkies.pdc-racing.net HTTP/1.1" 200 422
Jun 18 14:18:47 2020 (1302) 127.0.0.1 - - "GET /3.1/lists/trackjunkies.pdc-racing.net/roster/owner HTTP/1.1" 200 625
Jun 18 14:18:47 2020 (1302) 127.0.0.1 - - "GET /3.1/lists/trackjunkies.pdc-racing.net/roster/moderator HTTP/1.1" 200 90
Jun 18 14:18:48 2020 (1302) 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 member._member_id = '88b9844d-0791-44eb-8cf4-615a03b5c...
^
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 165, in find
result = attribute(
File "/usr/lib/python3/dist-packages/mailman/rest/lists.py", line 216, in member
return AMember(member.member_id)
File "/usr/lib/python3/dist-packages/mailman/rest/members.py", line 114, in __init__
else service.get_member(member_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/subscriptions.py", line 71, in get_member
if members.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 member._member_id = '88b9844d-0791-44eb-8cf4-615a03b5c...
^
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 member.id AS member_id, member._member_id AS member__member_id, member.role AS member_role, member.list_id AS member_list_id, member.moderation_action AS member_moderation_action, member.address_id AS member_address_id, member.preferences_id AS member_preferences_id, member.user_id AS member_user_id
FROM member
WHERE member._member_id = %(member_id_1)s) AS anon_1]
[parameters: {'member_id_1': UUID('88b9844d-0791-44eb-8cf4-615a03b5cc53')}]
(Background on this error at: http://sqlalche.me/e/f405)
Jun 18 14:18:48 2020 (1302) 127.0.0.1 - - "DELETE /3.1/lists/trackjunkies.pdc-racing.net/member/XXXXXXXX(a)gmail.com HTTP/1.1" 500 59
—
mailman-web.log errors:
--
ERROR 2020-06-18 21:21:06,399 1268 django.request Internal Server Error: /mailman3/postorius/lists/trackjunkies.pdc-racing.net/members/member/
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/mailmanclient/restobjects/mailinglist.py", line 321, in unsubscribe
self._connection.call(path, method='DELETE')
File "/usr/lib/python3/dist-packages/mailmanclient/restbase/connection.py", line 99, in call
raise HTTPError(url, response.status, content, response, None)
urllib.error.HTTPError: HTTP Error 500: b'A server error occurred. Please contact the administrator.'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py", line 34, in inner
response = get_response(request)
File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 115, in _get_response
response = self.process_exception_by_middleware(e, request)
File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 113, in _get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "/usr/lib/python3/dist-packages/django/views/generic/base.py", line 71, in view
return self.dispatch(request, *args, **kwargs)
File "/usr/lib/python3/dist-packages/django/contrib/auth/mixins.py", line 52, in dispatch
return super().dispatch(request, *args, **kwargs)
File "/usr/lib/python3/dist-packages/django/contrib/auth/mixins.py", line 109, in dispatch
return super().dispatch(request, *args, **kwargs)
File "/usr/lib/python3/dist-packages/postorius/views/generic.py", line 65, in dispatch
return super(MailingListView, self).dispatch(request, *args, **kwargs)
File "/usr/lib/python3/dist-packages/django/views/generic/base.py", line 97, in dispatch
return handler(request, *args, **kwargs)
File "/usr/lib/python3/dist-packages/postorius/views/list.py", line 169, in post
return self._member_post(request, role)
File "/usr/lib/python3/dist-packages/postorius/views/list.py", line 120, in _member_post
self.mailing_list.unsubscribe(member)
File "/usr/lib/python3/dist-packages/mailmanclient/restobjects/mailinglist.py", line 324, in unsubscribe
raise ValueError('%s is not a member address of %s' %
ValueError: XXXXXXX(a)gmail.com is not a member address of trackjunkies(a)pdc-racing.net
ERROR 2020-06-18 21:21:06,399 1268 django.request Internal Server Error: /mailman3/postorius/lists/trackjunkies.pdc-racing.net/members/member/
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/mailmanclient/restobjects/mailinglist.py", line 321, in unsubscribe
self._connection.call(path, method='DELETE')
File "/usr/lib/python3/dist-packages/mailmanclient/restbase/connection.py", line 99, in call
raise HTTPError(url, response.status, content, response, None)
urllib.error.HTTPError: HTTP Error 500: b'A server error occurred. Please contact the administrator.'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py", line 34, in inner
response = get_response(request)
File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 115, in _get_response
response = self.process_exception_by_middleware(e, request)
File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 113, in _get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "/usr/lib/python3/dist-packages/django/views/generic/base.py", line 71, in view
return self.dispatch(request, *args, **kwargs)
File "/usr/lib/python3/dist-packages/django/contrib/auth/mixins.py", line 52, in dispatch
return super().dispatch(request, *args, **kwargs)
File "/usr/lib/python3/dist-packages/django/contrib/auth/mixins.py", line 109, in dispatch
return super().dispatch(request, *args, **kwargs)
File "/usr/lib/python3/dist-packages/postorius/views/generic.py", line 65, in dispatch
return super(MailingListView, self).dispatch(request, *args, **kwargs)
File "/usr/lib/python3/dist-packages/django/views/generic/base.py", line 97, in dispatch
return handler(request, *args, **kwargs)
File "/usr/lib/python3/dist-packages/postorius/views/list.py", line 169, in post
return self._member_post(request, role)
File "/usr/lib/python3/dist-packages/postorius/views/list.py", line 120, in _member_post
self.mailing_list.unsubscribe(member)
File "/usr/lib/python3/dist-packages/mailmanclient/restobjects/mailinglist.py", line 324, in unsubscribe
raise ValueError('%s is not a member address of %s' %
ValueError: XXXXXXXXX(a)gmail.com is not a member address of trackjunkies(a)pdc-racing.net
[pid: 1268|app: 0|req: 18686/18686] 76.102.110.193 () {68 vars in 1625 bytes} [Thu Jun 18 21:21:06 2020] POST /mailman3/postorius/lists/trackjunkies.pdc-racing.net/members/member/ => generated 1156 bytes in 162 msecs (HTTP/1.1 500) 5 headers in 182 bytes (1 switches on core 1)
——
Could this somehow be related to my recent migration from sqlite3 to postgres?
- Mark
-----
mark(a)pdc-racing.net | 408-348-2878
5 years
Re: django request error
by Simon Brown
Are you on Ubuntu 20.04 with Apache2? It looks like the same problem I had,
see my message to the list. Try removing the trailing / on localhost on the
uwsgi ProxyPass line in apache.conf
ProxyPass /mailman3 unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/
becomes
ProxyPass /mailman3 unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost
Simon
On Thursday, 30 September 2021 16:58:09 CEST tibor.molnar(a)waltoninstitute.ie
wrote:
> I recently got postorius web interface stopped with an error, from web log:
> WARNING 2021-09-29 14:46:47,071 39320 django.request Not Found:
> /mailman//postorius/lists/ from website: This page either doesn't exist, or
> it moved somewhere else. I wonder what would be the source of this error /
> anyone else experienced this error since I haven't changed anything.
>
> Regards,
> Tibor
> _______________________________________________
> 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/
--
Simon Brown
System Engineer EISCAT Scientific Association
P. O. Box 812, SE-981 28 Kiruna, Sweden simon.brown(a)eiscat.se
3 years, 8 months
Re: Archiver "prototype" and disabling archiving at all
by Abhilash Raj
On Thu, Mar 28, 2019, at 9:18 AM, Torge Riedel wrote:
> Am 24.03.19 um 16:49 schrieb Mark Sapiro:
> > On 3/24/19 5:40 AM, Torge Riedel wrote:
> >> in the settings of a mailing list I can choose two archivers:
> >> "Hyperkitty" and "prototype". What is this archive "prototype" and how
> >> can I disable/remove/deinstall it? And how can I disable archiving at
> >> all, so no archiver can be chosen in the settings.
> >
> > The prototype archiver stores messages individually in
> > var/archives/prototype/LIST_NAME/.
> >
> > You can disable the prototype archiver by putting
> >
> > [archiver.prototype]
> > enable: no
> >
> > in your mailman.cfg. To disable all archiving, just remove all the
> > [archiver.*] sections from your mailman.cfg or set them to 'enable: no'
> >
> >
> Hi Mark,
>
> thanks. This disabled the archivers, but there is still the "Archives"
> link on top of the page. Is it possible to remove it? Cause there is
> nothing to see there. I tried commenting "'hyperkitty'," in
> INSTALLED_APPS, but then I got a 500.
INSTALLED_APPS = (
'postorius',
'django_mailman3',
# Uncomment the next line to enable the admin:
'django.contrib.admin',
# Uncomment the next line to enable admin documentation:
# 'django.contrib.admindocs',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.messages',
'django.contrib.staticfiles',
'django_gravatar',
'allauth',
'allauth.account',
'allauth.socialaccount',
)
This is how it should look like if you want to remove Hyperkitty. There
are a few other settings you should remove.
https://gitlab.com/mailman/postorius/blob/master/example_project/settings.py
This is a Postorius only configuration for reference.
> _______________________________________________
> 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)
6 years, 2 months
Re: where is manage.py for migration?
by Mark Sapiro
On 11/26/20 6:50 AM, Dan Langille wrote:
> Hello,
>
> I am following https://docs.mailman3.org/en/latest/migration.html and I'm trying to "Migrate the list archives from Mailman 2 to Mailman 3 by running the following command":
>
> [mailman@mailman ~]$ python manage.py hyperkitty_import -l biking(a)lists.example.org /usr/local/mailman/archives/private/biking.mbox
> python: can't open file 'manage.py': [Errno 2] No such file or directory
>
> Is the documentation correct? I cannot locate manage.py in the code:
That refers to the Django manage.py script. It's name and location
depends on how you installed Postorius and HyperKitty. Have you
installed those and set up a Django project?
There are sample manage.py files in both postorius/example_project/ and
hyperkitty/example_project/ as well as
mailman-suite/mailman-suite_project/, however, depending on how things
are installed, the Django admin interface could be named manage.py,
django-admin or something else.
--
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
4 years, 6 months
Re: Apache shows No Lists
by Mark Sapiro
On 5/22/23 14:48, ceo(a)sartrack.nz wrote:
> Thanks;
> There has never been a 'Mailman' user. I do have a www-data user (all Apache2 data' and there is a 'list' user.
So what I refer to as the Mailman user (a generic term) is `list` in
your case.
> I may have run the import fuction as root, but I then used chown() to set the directory tree /var/lib/mailman3/* to user 'list'.
OK
> So I upgraded Debian 10 to Debian 11.
> This also upgraded Apache2 I assume, but I kept the original (single) config file.
>
> I then installed the whole Mailman3 package with 'apt'. I may also have installed additional missing bits afterwards, as I think it was not complete. I initially tried to use MariaDB but the installation failed completly because it never asked for the MariaDB root password, and as a result of that everyting else failed too.
> Then I un-installed 5 times, and then I finally went for the 'default' database system.
>
> I then edited the file with the recommended settings for Mailman3:
> Alias /mailman3/favicon.ico /var/lib/mailman3/web/static/postorius/img/favicon.ico
> Alias /mailman3/static /var/lib/mailman3/web/static
>
> <Directory "/var/lib/mailman3/web/static">
> Require all granted
> </Directory>
>
> <IfModule mod_proxy_uwsgi.c>
> ProxyPass /mailman3/favicon.ico !
> ProxyPass /mailman3/static !
> ProxyPass /mailman3 unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/
> </IfModule>
>
> So clearly Apache2 manages to access the data supplied by Postorius because it sees the lists (at least the empty ones).
> -What user should the whole system running under: 'list'? of 'www-data'?
> - Is there anything else I should tell Apache2?
All the web based stuff is a Django application. Django is run by uWSGI
which probably runs as www-data, but Django only accesses hyperkitty,
postorius and django-mailman3 and other Django related tables in the
database. It doesn't need access to file system files other than things
like wsgi.py, urls.py, settings.py and settings_local.py and only read
access to these.
All the mailman3 file system stuff has to be read/write/searchable by
`list`.
> Now I tried to use "django-admin createsuperuser". This also fails because of this error:
> ImportError: cannot import name 'force_text' from 'django.utils.encoding' (/usr/local/lib/python3.9/dist-packages/django/utils/encoding.py)
> And I cannot find where this 'force_text' is called from. It must be removed as it is too old.
It seems your Django installation is broken. Do
cd /usr/local/lib/python3.9/dist-packages/django
grep -r force_text
to find where force_text is called, or maybe add
def force_text(s, encoding='utf-8', strings_only=False,
errors='strict'):
return force_str(s, encoding, strings_only, errors)
to /usr/local/lib/python3.9/dist-packages/django/utils/encoding.py
--
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
2 years
New releases
by Abhilash Raj
Hi Everyone,
I am pleased to announce new stable releases for:
- Postorius: 1.3.3
Changelog: https://docs.mailman3.org/projects/postorius/en/latest/news.html#id1
Download: https://pypi.org/project/postorius/1.3.3/
- Hyperkitty: 1.3.3
Changelog: https://hyperkitty.readthedocs.io/en/latest/news.html#id1
Download: https://pypi.org/project/HyperKitty/1.3.3rc1/
- Mailmanclient: 3.3.1
Changelog: https://docs.mailman3.org/projects/mailmanclient/en/latest/src/mailmanclien…
Download: https://pypi.org/project/mailmanclient/3.3.1/
- Django-mailman3: 1.3.3
Changelog: https://gitlab.com/mailman/django-mailman3/-/blob/master/README.rst
Download: https://pypi.org/project/django-mailman3/1.3.3
Python 3.6+ and Django 2.0+ is supported for all of them. Django 3.0 support for Hyperkitty requires manually upgrading a dependency (django-haystack>=3.0b2, once a stable version of this has been released, it shouldn't require manually upgrading).
There are tons of bug-fixes across the board and some new features.
Biggest visible change is switch to Bootstrap 4, which has been long pending for us. Bootstrap 4 completely changes the CSS grid model using the new Flexbox. There might be some small changes or breakages when using on mobile. Please report such issues to us via Gitlab!
Some other notable changes are in Postorius, which includes many more list settings exposed include content filtering settings, bounce processing (which was added in the previous release of Mailman Core) settings and some other ones. Settings page is also slightly different with all the sections on the vertical menu on left instead of horizontal tabs. You can now also specify a reason when rejecting held messages.
There was also a gnarly bug, which caused the name of some members to be the string "None". For the longest time, I couldn't figure out the reason for it, but it ended up being a simple fix in mailmanclient's json serialization of display_name, which would result in Python's None value being passed as string "None" to Mailman's API for subscription.
There is also better support for filtering visible lists based on the current vhost, which I see a few people are already waiting for from mailman-users list.
A full changelog has been added to each project in the top.
--
thanks,
Abhilash Raj (maxking)
5 years