Upgrading other python packages than the mailman ones in a venv results in dependency conflicts
by Ulf R.
Hello,
I know this should be the way to upgrade:
https://docs.mailman3.org/en/latest/upgrade-guide.html
I have 3.3.10 installed.
I saw that some python packages are outdated an tried this which install all outdated packages in a row:
pip list --outdated --format=json | jq '.[].name' | xargs -n1 pip install -U
One outdated package was django and this part happened:
-------------------------------
vDownloading Django-5.1.4-py3-none-any.whl (8.3 MB)
Installing collected packages: Django
Attempting uninstall: Django
Found existing installation: Django 4.2.16
Uninstalling Django-4.2.16:
Successfully uninstalled Django-4.2.16
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
hyperkitty 1.3.12 requires django<5.1,>=4.2, but you have django 5.1.4 which is incompatible.
mailman-web 0.0.9 requires django<4.3,>=4.0, but you have django 5.1.4 which is incompatible.
postorius 1.3.13 requires django<5.1,>=4.2, but you have django 5.1.4 which is incompatible.
django-mailman3 1.3.15 requires django<5.1,>=4.2, but you have django 5.1.4 which is incompatible.
Successfully installed Django-5.1.4
-------------------------------
So I made a roll back.
Is this really the only secure way to update the venv?:
pip install -U mailman postorius django-mailman3 hyperkitty mailman-web
May be yes and I have to ignore the rest? ;-)
Thank you und regards
1 year, 9 months
Avoiding non-members to be saved.
by Stephen J. Turnbull
Guillermo Hernandez (Oldno7) via Mailman-users writes:
> Yesterday I had a problem with a private list. A spammer sent a mail
> forging one address that was a non-member (in fact was an "accept this
> no subscriber mails" from mailman 2.1 import) with very bad intentions
> and it was distributed.
If you upgrade from Mailman 2 to Mailman 3, the accept_these_nonmembers
list for each list is grandfathered into the Mailman 3 list (from
rules/moderation.py):
# Check the '*_these_nonmembers' properties first. XXX These are
# legacy attributes from MM2.1; their database type is 'pickle' and
# they should eventually get replaced.
for action_name in ('accept', 'hold', 'reject', 'discard'):
legacy_attribute_name = '{}_these_nonmembers'.format(
action_name)
> There were no list of "accept this non members" in the Postorius
> config
If there is no such list in Postorius, I would guess that some
developer thought "OK, this is a legacy feature and I'll get back to
it when we move it to the proper database" (unfortunate, but most of
us have open-subscription member-posts-only lists, and the current
workflow seems to work well, so this feature may not be so salient).
> I think it is solved now (deleting all and putting to hold just the
> non-members addresses that I would want to pass messages on)
This should not be necessary, unless there were pre-approved addresses
that are no longer appropriate. But Mailman can't know that!
> The fact is that any sender address of mails sent to the list is saved
> as a "non member", and it make me nervous as it will grow despite it is
> a legitimate message or not.
As far as I can see there is no other rule except that legacy rule
(and the rule that accepts all posts, which is rarely used) that will
accept a post from nonmembers.
> Anybody knows if there is a per list config to avoid saving all that
> addresses as non members? o a overall config?
No, there isn't, and there never will be. This is a basic design
decision about the representation of "people who participate in any
way in mailing lists". The only way to prevent creation of an Address
object for the sender of an email is to reject or discard the post (in
which case the "create an Address" path isn't entered), and don't set
a moderation action on the sender. Obviously if you set a moderation
action, that will create an Address in the database.
The problem you encountered is not preventable by any means
whatsoever: a malicious actor discovered an address that is allowed to
post. The specific case you're worried about, that nonmembers will
automatically be allowed to post, is not possible. The only way to
get on the list of "accept_these_nonmembers" is to be inherited from
accept_these_nonmembers on the parent Mailman 2 list, or an explicit
decision by a moderator.
The fact that this list is not exposed in Postorius is a bug, but I
can't say when it might be fixed. It appears that the current process
(the moderator can set the sender's persistent moderation action
separately from approving or rejecting a particular post) works fine,
since this is the first time I've heard of this issue, and as you
present it, Mailman is doing the best it can since Somebody Authorized
put that sender on the approved list in Mailman 2.
If a particular nonmember becomes a problem, you can access that
User or Address in Postorius and set them to Hold, Reject, or Discard.
The process of deleting all nonmembers has been more difficult than it
should be, but this is being fixed, IIRC in the next release.
Steve
5 years, 1 month
Re: Default values for lists in Mailman 3
by Markus Grandpré
Dear Mark, dear list,
in Menu "Mass Operations / Mass Subscription" I have set the default
value for checkbox "Invitation" in file
</usr/lib/python3/dist-packages/postorius/forms/list_forms.py> (on
Debian 12) as you had suggested:
invitation = forms.BooleanField(
label=_('Invitation'),
initial=True,
required=False,
help_text=_(
'If checked, the other checkboxes are ignored and the users
will '
'be sent an invitation to join the list and will be
subscribed '
'upon acceptance thereof.'
),
widget=forms.CheckboxInput(),
)
However, administrators of mailing lists on our Mailman3 demo system
report that the invitation is still sent, even if they have deactivated
the sending of the invitation via the “Invitation” checkbox.
What have I done wrong?
Best regards,
Markus
Am 20.09.24 um 09:05 schrieb Markus Grandpré:
> Thank you very much for your answer.
>
> Best regards,
> Markus
>
> Am 19.09.24 um 22:03 schrieb Mark Sapiro:
>> On 9/19/24 05:46, Markus Grandpré wrote:
>>> Dear list,
>>>
>>> I would like to activate the invitation setting for all lists as
>>> default. In Mailman 2.1 I have done this in the file </etc/mailman/
>>> mm_cfg.py>:
>>>
>>>
>>> DEFAULT_SUBSCRIBE_OR_INVITE = Yes
>>>
>>>
>>> How can I do this in Mailman 3?
>>
>> There is a draft merge request at https://gitlab.com/mailman/
>> postorius/-/merge_requests/930 which implements a framework for
>> setting Postorius defaults and creates a setting to set the default
>> for pre- verified on the mass subscription page. Once merged, this can
>> easily be extended to provide a default for Invitation.
>>
>> In the mean time, you can only do this by patching src/postorius/
>> forms/ list_forms.py like
>> ```
>> --- a/src/postorius/forms/list_forms.py
>> +++ b/src/postorius/forms/list_forms.py
>> @@ -1283,7 +1283,7 @@ class ListMassSubscription(forms.Form):
>>
>> invitation = forms.BooleanField(
>> label=_('Invitation'),
>> - initial=False,
>> + initial=True,
>> required=False,
>> help_text=_(
>> 'If checked, the other checkboxes are ignored and the
>> users will '
>> ```
>>> Can I also transfer other default values like:
>>>
>>> ...
>>> DEFAULT_SERVER_LANGUAGE = 'en'
>>> DEFAULT_SEND_REMINDERS = 1
>>> DEFAULT_SUBSCRIBE_OR_INVITE = Yes
>>> DEFAULT_PRIVATE_ROSTER = 2
>>> DEFAULT_ARCHIVE = Off
>>> DEFAULT_ARCHIVE_PRIVATE = 1
>>> ...
>>>
>>> from the very same configuration file to Mailman 3? Is there a
>>> documentation of the default values for lists in Mailman 3?
>>
>> This is done by creating a list style with the desired defaults. See
>> https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/
>> styles/ docs/styles.html for documentation of styles and see https://
>> gitlab.com/ mailman/example-mailman-plugin for an example of creating
>> a plugin in Mailman core to make a persistent style.
>>
>> There is no specific doc for the list settings. You need to look at
>> https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/styles/
>> base.py for the various settings and https://gitlab.com/mailman/
>> mailman/-/blob/master/src/mailman/styles/default.py to see which
>> default classes are applied for various styles.
>>
>
>
> _______________________________________________
> 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/
> Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message…
>
> This message sent to markus.grandpre(a)uni-konstanz.de
--
Markus Ludwig Grandpré
Universität Konstanz
Kommunikations-, Informations-, Medienzentrum (KIM)
Abteilung IT-Dienste Forschung und Lehre,
B803, Tel: ++49 7531 88 4342
1 year, 11 months
Re: Fwd: Re: Removing a mail addresses and users
by Abhilash Raj
On Wed, Jun 10, 2020, at 3:33 PM, Allan Hansen wrote:
> All,
>
> This disconnect between Mailman Core and Django and Postorius is, by
> far, the weakest and, for subscribers, most confusing aspect of MM3
> (once it has been installed, which is extremely hard and confusing).
The disconnect was intentional to make sure that we are fully able to leverage the power of Django's ability to run multiple dis-connected applications in a single Site and Account system. And Mailman Core was intentionally designed to not be an account management system so it can be kept simple.
The disconnect however has caused more confusion than has helped, which we acknowledge. But this disconnect doesn't exist all that much right now, barring any bugs. We synchronize most of the state from Postorius down to Mailman Core including, any additional addresses that you add, primary address etc. Display Names don't trigger an update in Core, but it isn't that hard to do if you open a ticket.
>
> In a true account-centric system, you set up a web account and from
> there manage your emails and, for each email, your subscriptions.
> Subscription options would be hierarchical: account/email/list, with
> lower levels inheriting/overriding settings from/the level above.
You are able to sign in via web and manage your email and subscriptions. The preferences also work exactly how you described above where the lower level override the default and/or upper level settings.
>
> That’s really what I had expected when I pushed for us to move our 50
> email lists to MM3 and I was very excited about the prospect,
> as it would solve a lot of system/subscriber management issues I had
> managing MM2.
>
> Alas, I was very surprised that that’s not how MM3 works. Some things
> got harder, even, such as the inability to change subscription
> addresses, which should have been a showstopper from the start!
> I still hope that MMxx OOTB will get there, but I guess it’ll be along
> haul. Would we be talking about MM4 to be released 20 years from now?
As a Subscriber, you are able to do switch emails in subscriptions from your options page. The URL to which is displayed in the List's Summary page when you are logged in. Yes, it requires an approval if the list's settings are set to moderate but that is going to be fixed, see this issue[1]. It is quite simple IMO to fix this one, if someone wants to take this up.
[1]: https://gitlab.com/mailman/postorius/-/issues/425
Are you asking about switching emails as an administrator for your subscribers?
> Some dedicated and skilled developers are currently investing heavily
> in a replacement for Postorius, but I really believe that any work is
> better spent transforming Mailman Core etc. into a true account-based
> system. Then, and only then, will it make sense to build new and better
> interfaces on top, as, without a healthy core, such interface will
> currently may have to inherit the confusion and disconnect that
> currently is so aggravating.
I don't know if we want to add account management to Core, but User management is missing from Postorius, that is true. We punted on it and delegated that part to Django's admin interface. Long long time ago, I remember seeing that there was a User's tab for managing users, but that has since changed I think.
If you and some others on this list would like to propose an RFC here[2], it would be a great help for me. What I am basically looking for is what kind of "User management" are administrators looking for. It doesn't have to be too detailed but a single line example would be:
- As a Admin, I would like to delete a User completely from my system, including all their addresses and subscription
- Also, it would be good to delete their account but retain their subscriptions
- As a Admin, I would like to update User's attributes in the system like:
- Manually verify their email address
- Manually update their Name
- As a User, I would like to delete my own account and all the subscriptions.
Maybe this could be a starting point, but something like this can be added to Postorius.
[2]: https://gitlab.com/mailman/postorius/-/issues/new
As for the question in this thread, you are able to delete the User from Django's admin page and that would delete all the related EmailAddress for them. Deleting an Email address doesn't delete the User, since the relationship exists that User owns Emails. There is currently no way to delete all the subscriptions for a User though.
> The above is not meant to aggravate the MM3 development team, for which
> I have utmost respect and gratitude, and which I admire for their
> tireless support given over decades to the community of admins.
> Software development is devilishly hard and time consuming.
And thank you for posting what you think is an important enhancement to Postorius. We don't have a very strict process to choose what new features to work on, so email like this do help us prioritize. Other users could also help by upvoting or just adding "+1" to the bugs/feature enhancements that affects them the most so we can fix them sooner rather than later. I would be more than happy if more people participated in just being able to prioritize features, all the work really happens in the open on Gitlab.
As administrators of some 'open source' lists, the needs of us as admins are somewhat different from what would be in a closed organization and ability to kick someone completely out of the system is something never I had to do since folks are supposed to manage their own subscriptions. We do ban people from sending emails if they've been spamming, but that is a different thing, they are still able to login into Postorius AFAIK.
> Yours,
>
> Allan Hansen
> hansen(a)rc.org
>
>
>
>
> > Begin forwarded message:
> >
> > From: Mark Sapiro <mark(a)msapiro.net>
> > Subject: [MM3-users] Re: Removing a mail addresses and users
> > Date: June 10, 2020 at 12:46:01 PDT
> > To: mailman-users(a)mailman3.org
> >
> > On 6/10/20 10:23 AM, Abhijith PA via Mailman-users wrote:
> >> Hello.
> >>
> >> I tried to remove random email address signing ups (which I signed up
> >> while testing) via admin panel. After removing I tried to sign up again,
> >> but I am getting,
> >>
> >> 'A user is already registered with this e-mail address'
> >
> > You removed the user's subscription from the list, but you didn't remove
> > the user from the system.
> >
> > Mailman3 has a concept of `user` which didn't exist in Mailman 2.1.
> > User's have addresses and a user or one of the user's addresses can
> > belong to a list with one or more roles (non-member, member, moderator
> > or owner)
> >
> >
> >> Combing through the database, I found auth_user table in mailman3web db
> >> still contain those mail address. How to wipe email address entirely
> >> from the db so I can signup again without the 'forget password' method
> >
> > There are a couple of things. If you log in to the web UI as a django
> > superuser, you can go to the django admin UI -> Users section and delete
> > the User, but I think that will only delete the web user and not delete
> > the user from Mailman core.
> >
> > You can also log in to the web UI as the user and go to
> > <https://lists.mailman3.org/user-profile/delete>, but that again only
> > deletes the web user, and if you could do that, you could just subscribe
> > once you're logged in, so I assume that's what you want to avoid.
> >
> > I don't think there is a way for a user as opposed to a site admin to
> > delete her user record from Mailman core and even for a site admin,
> > there's no way in Postorius to delete a user from core. It has to be
> > done via REST
> > <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/…>
> > or `mailman shell`.
> >
> > --
> > Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
> > San Francisco Bay Area, California better use your sense - B. Dylan
> > _______________________________________________
> > 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/
>
> _______________________________________________
> 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, 3 months
Re: Help with installing Postorius and Hyperkitty on Ubuntu 19
by Andrew Bernard
Hi Mark,
Thanks for your great help. But despite decades of UNIX experience, my area
is not Django (yet). The nub of my question is that I thought you have to
have a manage.py file for Django to be able to set up the various affairs,
such as making the database migrations and so on. It is that that is
eluding me. Apologies for this hopelessly newbie question.
I was impressed with your method of installation in the page referenced,
and I have foolwed that closely. But I am puzzled about the build script.
If I run as user mailman, not root, it wanted to install under /usr. which
of course results in permission denied. I had to modify the script to say
this:
python setup.py install --prefix /opt/mailman/mm/venv
I am concerned that I have also misunderstood something here.
A
On Sun, 9 Jun 2019 at 00:57, Mark Sapiro <mark(a)msapiro.net> wrote:
> On 6/8/19 4:04 AM, Andrew Bernard wrote:
> >
> > Where is the Django config area for the
> > pip installed modules? It is this that I find obscure.
>
> The short answer is wherever you put it. If you look at
> <https://wiki.list.org/DOC/Mailman%203%20installation%20experience>
> which Abhilash mentioned, you'll see what I do.
>
>
>
7 years, 3 months
Re: Apache shows No Lists
by Mark Sapiro
On 5/22/23 12:57, ceo(a)sartrack.nz wrote:
> Postorius is running.
> I just removed all mailing lists, and created new empty ones.
> These now show in the Apache2 website, via the link to Postorius I assume.
> Then I imported members from the old mailing list "Templist" into the new one.
> Now the "templist" is no longer visible on the website!
Did you do this import with `mailman import21`? If so, did you run it as
the Mailman user and not as root?
> It is here:
> https://sartrack.nz/mailman3/
> Note that the existing list "Templist" is missing.
https://sartrack.nz/mailman3/ is missing CSS. Apache doesn't know how to
access /static/ or you never built it with the django admin
collectstatic command.
> Now I need to login as 'superuser' or whatever it is called, so I can manage all the lists.
> Where do I set up my login and password for access via the web browser?
You create a superuser with the django admin createsuperuser command.
How you invoke the django admin command depends on how you installed
Mailman. Please tell us how you installed Mailman so we don't have to
guess about this and other things.
--
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
3 years, 4 months
Re: Installed from Howto_Install_Mailman3_On_Debian10, web not quite working
by Odhiambo Washington
On Sun, May 7, 2023 at 8:52 PM Volkmar Grote <volkmar(a)grote-family.com>
wrote:
> Hi Mark,
>
> On 07.05.23 01:31, Mark Sapiro wrote:
> > On 5/6/23 16:02, volkmar(a)grote-family.com wrote:
> >>
> >> My urls.py:
> >>> (venv) mailman@me:/opt/mailman/mm$ grep -v "^#" urls.py
> >>> from django.contrib import admin
> >>> from django.urls import include, reverse_lazy, re_path
> >>> from django.views.generic import RedirectView
> >>>
> >>> urlpatterns = [
> >>> re_path(r'^$', RedirectView.as_view(
> >>> url=reverse_lazy('list_index'),
> >>> permanent=True)),
> >>> re_path(r'^postorius/', include('postorius.urls')),
> >>> re_path(r'^hyperkitty/', include('hyperkitty.urls')),
> >>> re_path(r'', include('django_mailman3.urls')),
> >>> re_path(r'^accounts/', include('allauth.urls')),
> >>> # Django admin
> >>> re_path(r'^admin/', admin.site.urls),
> >>> ]
> >
> >
> > We and the various docs are inconsistent about 'postorius' vs
> > 'mailman3' and 'hyperkitty' vs 'archives' in urls. Add these
> >
> > re_path(r'^mailman3/', include('postorius.urls')),
> > re_path(r'^archives/', include('hyperkitty.urls')),
> >
> > to your urlpatterns list in urls.py to cover both variants.
> >
> thanks for the quick reply.
> I am one step closer to a solution,
> "http://127.0.0.1:8000/postorius/lists/?all-lists#" seems to work now.
> I get the functionality, but it looks ugly w/o any graphics, for which I
> get yet another, slightly similar, error message:
> >
> >
> > Page not found (404)
>
You can run:
'/opt/mailman/mm/bin/django-admin clear_cache' as the mailman user.
After that you can also restart Nginx, then test again and see if
everything works.
--
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)
[How to ask smart questions:
http://www.catb.org/~esr/faqs/smart-questions.html]
3 years, 4 months
Docker files for mailman
by Simon Hanna
Hi,
I started working on docker files for Mailman.
I created three repositories:
- https://github.com/simonsmiley/postorius-docker
Holds the files needed to create a postorius container
- https://github.com/simonsmiley/mailman-docker
Holds the files needed to create a core container
- https://github.com/simonsmiley/mailman-compose
Holds docker-compose files that greatly simply the process of running
the containers
* The mailman repo currently lacks documentation
* Currently no emails can be sent.
I still have to figure out what the best way is...
* Hyperkitty will be added next
(together with a complete "bundler" install)
I pushed two images to the docker hub. Their names are
thelinuxguy/postorius and thelinuxguy/mailman
I created two organizations
mailman on docker hub and gnu-mailman on github
https://github.com/gnu-mailman
https://hub.docker.com/u/mailman/
I know we shouldn't use github, but there is no way around
github/bitbucket for automated builds on docker hub.
I post here to inform you about the docker images and I also to ask if
I'm allowed to keep these two organizations and move my images/repos
there. I'll happily give push/owner access to additional people if
requested.
The repositories could be mirrored to the gitlab mailman group,
sadly the process doesn't work the other way round just yet.
In case this request gets denied, I'll just remove the organizations and
let the images be "unofficial".
cheers,
Simon
10 years, 2 months
Re: Migration from old server to new server failed
by Helio Loureiro
Hi,
I repeated the steps today.
First I waited to end the errors raised because the mailman3-web wasn't
running.
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File
"/local/mailman/venv/lib/python3.10/site-packages/urllib3/connectionpool.py",
line 793, in urlopen
response = self._make_request(
File
"/local/mailman/venv/lib/python3.10/site-packages/urllib3/connectionpool.py",
line 496, in _make_request
conn.request(
File
"/local/mailman/venv/lib/python3.10/site-packages/urllib3/connection.py",
line 400, in request
self.endheaders()
File "/usr/lib/python3.10/http/client.py", line 1278, in endheaders
self._send_output(message_body, encode_chunked=encode_chunked)
File "/usr/lib/python3.10/http/client.py", line 1038, in _send_output
self.send(msg)
File "/usr/lib/python3.10/http/client.py", line 976, in send
self.connect()
File
"/local/mailman/venv/lib/python3.10/site-packages/urllib3/connection.py",
line 238, in connect
self.sock = self._new_conn()
File
"/local/mailman/venv/lib/python3.10/site-packages/urllib3/connection.py",
line 213, in _new_conn
raise NewConnectionError(
urllib3.exceptions.NewConnectionError: <urllib3.connection.HTTPConnection
object at 0x7f0fdc2f72b0>: Failed to establish a new connection: [Errno
111] Connection refused
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File
"/local/mailman/venv/lib/python3.10/site-packages/requests/adapters.py",
line 486, in send
resp = conn.urlopen(
File
"/local/mailman/venv/lib/python3.10/site-packages/urllib3/connectionpool.py",
line 847, in urlopen
retries = retries.increment(
File
"/local/mailman/venv/lib/python3.10/site-packages/urllib3/util/retry.py",
line 515, in increment
raise MaxRetryError(_pool, url, reason) from reason # type:
ignore[arg-type]
urllib3.exceptions.MaxRetryError: HTTPConnectionPool(host='127.0.0.1',
port=8000): Max retries exceeded with url: /archives/api/mailman/archive
(Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at
0x7f0fdc2f72b0>: Failed to establish a new connection: [Errno 111]
Connection refused'))
Which seems to keep forever. So eventually I gave up and moved forward.
And I changed to use the uwsgi socket instead of the direct port.
(venv) mailman@new-mailman3 ~ (v3.1.1) [0|SIGINT]> mailman-web migrate
System check identified some issues:
WARNINGS:
account.EmailAddress: (models.W036) MariaDB does not support unique
constraints with conditions.
HINT: A constraint won't be created. Silence this warning if you
don't care about it.
account.EmailAddress: (models.W043) MariaDB does not support indexes on
expressions.
HINT: An index won't be created. Silence this warning if you don't
care about it.
Operations to perform:
Apply all migrations: account, admin, auth, contenttypes,
django_mailman3, django_q, hyperkitty, postorius, sessions, sites,
socialaccount
Running migrations:
Applying account.0003_alter_emailaddress_create_unique_verified_email...
OK
Applying account.0004_alter_emailaddress_drop_unique_email... OK
Applying account.0005_emailaddress_idx_upper_email... OK
Applying admin.0003_logentry_add_action_flag_choices... OK
Applying auth.0009_alter_user_last_name_max_length... OK
Applying auth.0010_alter_group_name_max_length... OK
Applying auth.0011_update_proxy_permissions... OK
Applying auth.0012_alter_user_first_name_max_length... OK
Applying django_mailman3.0003_sessions... OK
Applying django_q.0010_auto_20200610_0856... OK
Applying django_q.0011_auto_20200628_1055... OK
Applying django_q.0012_auto_20200702_1608... OK
Applying django_q.0013_task_attempt_count... OK
Applying django_q.0014_schedule_cluster... OK
Applying hyperkitty.0016_auto_20180309_0056... OK
Applying hyperkitty.0017_file_attachments... OK
Applying hyperkitty.0018_threadcategory_color... OK
Applying hyperkitty.0019_auto_20190127_null_description... OK
Applying hyperkitty.0020_auto_20190907_1927... OK
Applying hyperkitty.0021_add_owners_mods...Traceback (most recent call
last):
File
"/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/utils.py",
line 87, in _execute
return self.cursor.execute(sql)
File
"/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/mysql/base.py",
line 75, in execute
return self.cursor.execute(query, args)
File
"/local/mailman/venv/lib/python3.10/site-packages/MySQLdb/cursors.py", line
179, in execute
res = self._query(mogrified_query)
File
"/local/mailman/venv/lib/python3.10/site-packages/MySQLdb/cursors.py", line
330, in _query
db.query(q)
File
"/local/mailman/venv/lib/python3.10/site-packages/MySQLdb/connections.py",
line 261, in query
_mysql.connection.query(self, query)
MySQLdb.OperationalError: (1050, "Table 'hyperkitty_mailinglist_moderators'
already exists")
Then dropping table hyperkitty_mailinglist_moderators.
(venv) mailman@new-mailman3 ~ (v3.1.1)> mailman-web migrate
System check identified some issues:
WARNINGS:
account.EmailAddress: (models.W036) MariaDB does not support unique
constraints with conditions.
HINT: A constraint won't be created. Silence this warning if you
don't care about it.
account.EmailAddress: (models.W043) MariaDB does not support indexes on
expressions.
HINT: An index won't be created. Silence this warning if you don't
care about it.
Operations to perform:
Apply all migrations: account, admin, auth, contenttypes,
django_mailman3, django_q, hyperkitty, postorius, sessions, sites,
socialaccount
Running migrations:
Applying hyperkitty.0021_add_owners_mods...Traceback (most recent call
last):
File
"/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/utils.py",
line 87, in _execute
return self.cursor.execute(sql)
File
"/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/mysql/base.py",
line 75, in execute
return self.cursor.execute(query, args)
File
"/local/mailman/venv/lib/python3.10/site-packages/MySQLdb/cursors.py", line
179, in execute
res = self._query(mogrified_query)
File
"/local/mailman/venv/lib/python3.10/site-packages/MySQLdb/cursors.py", line
330, in _query
db.query(q)
File
"/local/mailman/venv/lib/python3.10/site-packages/MySQLdb/connections.py",
line 261, in query
_mysql.connection.query(self, query)
MySQLdb.OperationalError: (1050, "Table 'hyperkitty_mailinglist_owners'
already exists")
After dropping table hyperkitty_mailinglist_owners.
(venv) mailman@new-mailman3 ~ (v3.1.1) [0|1]> mailman-web migrate
System check identified some issues:
WARNINGS:
account.EmailAddress: (models.W036) MariaDB does not support unique
constraints with conditions.
HINT: A constraint won't be created. Silence this warning if you
don't care about it.
account.EmailAddress: (models.W043) MariaDB does not support indexes on
expressions.
HINT: An index won't be created. Silence this warning if you don't
care about it.
Operations to perform:
Apply all migrations: account, admin, auth, contenttypes,
django_mailman3, django_q, hyperkitty, postorius, sessions, sites,
socialaccount
Running migrations:
Applying hyperkitty.0021_add_owners_mods...Traceback (most recent call
last):
File
"/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/utils.py",
line 87, in _execute
return self.cursor.execute(sql)
File
"/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/mysql/base.py",
line 75, in execute
return self.cursor.execute(query, args)
File
"/local/mailman/venv/lib/python3.10/site-packages/MySQLdb/cursors.py", line
179, in execute
res = self._query(mogrified_query)
File
"/local/mailman/venv/lib/python3.10/site-packages/MySQLdb/cursors.py", line
330, in _query
db.query(q)
File
"/local/mailman/venv/lib/python3.10/site-packages/MySQLdb/connections.py",
line 261, in query
_mysql.connection.query(self, query)
MySQLdb.OperationalError: (1050, "Table 'hyperkitty_mailinglist_moderators'
already exists")
After dropping table hyperkitty_mailinglist_moderators.
(venv) mailman@new-mailman3 ~ (v3.1.1) [0|1]> mailman-web migrate
System check identified some issues:
WARNINGS:
account.EmailAddress: (models.W036) MariaDB does not support unique
constraints with conditions.
HINT: A constraint won't be created. Silence this warning if you
don't care about it.
account.EmailAddress: (models.W043) MariaDB does not support indexes on
expressions.
HINT: An index won't be created. Silence this warning if you don't
care about it.
Operations to perform:
Apply all migrations: account, admin, auth, contenttypes,
django_mailman3, django_q, hyperkitty, postorius, sessions, sites,
socialaccount
Running migrations:
Applying hyperkitty.0021_add_owners_mods... OK
Applying hyperkitty.0022_mailinglist_archive_rendering_mode... OK
Applying hyperkitty.0023_alter_mailinglist_name... OK
Applying postorius.0004_create_email_template...Traceback (most recent
call last):
File
"/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/utils.py",
line 87, in _execute
return self.cursor.execute(sql)
File
"/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/mysql/base.py",
line 75, in execute
return self.cursor.execute(query, args)
File
"/local/mailman/venv/lib/python3.10/site-packages/MySQLdb/cursors.py", line
179, in execute
res = self._query(mogrified_query)
File
"/local/mailman/venv/lib/python3.10/site-packages/MySQLdb/cursors.py", line
330, in _query
db.query(q)
File
"/local/mailman/venv/lib/python3.10/site-packages/MySQLdb/connections.py",
line 261, in query
_mysql.connection.query(self, query)
MySQLdb.OperationalError: (1050, "Table 'postorius_emailtemplate' already
exists")
After dropping table postorius_emailtemplate.
(venv) mailman@new-mailman3 ~ (v3.1.1) [0|1]> mailman-web migrate
System check identified some issues:
WARNINGS:
account.EmailAddress: (models.W036) MariaDB does not support unique
constraints with conditions.
HINT: A constraint won't be created. Silence this warning if you
don't care about it.
account.EmailAddress: (models.W043) MariaDB does not support indexes on
expressions.
HINT: An index won't be created. Silence this warning if you don't
care about it.
Operations to perform:
Apply all migrations: account, admin, auth, contenttypes,
django_mailman3, django_q, hyperkitty, postorius, sessions, sites,
socialaccount
Running migrations:
Applying postorius.0004_create_email_template... OK
Applying postorius.0005_auto_20180707_1107... OK
Applying postorius.0006_auto_20180711_1359... OK
Applying postorius.0007_auto_20180712_0536... OK
Applying postorius.0008_auto_20190310_0717... OK
Applying postorius.0009_auto_20190508_1604... OK
Applying postorius.0010_auto_20190821_0621... OK
Applying postorius.0011_auto_20191109_1219... OK
Applying postorius.0012_auto_20200420_2136... OK
Applying postorius.0013_auto_20201116_0058... OK
Applying postorius.0014_auto_20210329_2248... OK
Applying postorius.0015_auto_20210619_0509... OK
Applying postorius.0016_auto_20210810_2157... OK
Applying postorius.0017_alter_emailtemplate_language... OK
Applying postorius.0018_alter_emailtemplate_language... OK
Applying socialaccount.0004_app_provider_id_settings... OK
Applying socialaccount.0005_socialtoken_nullable_app... OK
Applying socialaccount.0006_alter_socialaccount_extra_data... OK
At this point the errors remains about not reaching web part. So I started
mailman3-web.
Then I see these errors on var/log/mailman.log
Feb 19 15:35:14 2024 (543890) Traceback (most recent call last):
File
"/local/mailman/venv/lib/python3.10/site-packages/mailman_hyperkitty/__init__.py",
line 158, in _archive_message
url = self._send_message(mlist, msg)
File
"/local/mailman/venv/lib/python3.10/site-packages/mailman_hyperkitty/__init__.py",
line 228, in _send_message
raise ValueError(result.text)
ValueError: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL was not found on this server.</p>
<hr>
<address>Apache/2.4.52 (Ubuntu) Server at 127.0.0.1 Port 80</address>
</body></html>
Feb 19 15:35:14 2024 (543890) HyperKitty failure on
http://127.0.0.1/archives/api/mailman/archive: <!DOCTYPE HTML PUBLIC
"-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL was not found on this server.</p>
<hr>
<address>Apache/2.4.52 (Ubuntu) Server at 127.0.0.1 Port 80</address>
</body></html>
(404)
Feb 19 15:35:14 2024 (543890) Could not archive the message with id <
ff1707bb-d105-4f37-b3f8-9766b3563127(a)SESAMR604.domain.com>
Feb 19 15:35:14 2024 (543890) archiving failed, re-queuing (mailing-list
mylist.new-mailman.domain.com, message <
ff1707bb-d105-4f37-b3f8-9766b3563127(a)machine.domain.com>)
Feb 19 15:35:14 2024 (543890) Exception in the HyperKitty archiver:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL was not found on this server.</p>
<hr>
<address>Apache/2.4.52 (Ubuntu) Server at 127.0.0.1 Port 80</address>
</body></html>
And I can't get access to the hyperkitty at all.
On var/logs/uwsgi-error.log:
--- Logging error ---
Traceback (most recent call last):
File
"/local/mailman/venv/lib/python3.10/site-packages/django_q/cluster.py",
line 356, in pusher
task = SignedPackage.loads(task[1])
File
"/local/mailman/venv/lib/python3.10/site-packages/django_q/signing.py",
line 25, in loads
return signing.loads(
File
"/local/mailman/venv/lib/python3.10/site-packages/django_q/core_signing.py",
line 35, in loads
base64d = force_bytes(TimestampSigner(key, salt=salt).unsign(s,
max_age=max_age))
File
"/local/mailman/venv/lib/python3.10/site-packages/django_q/core_signing.py",
line 70, in unsign
result = super(TimestampSigner, self).unsign(value)
File
"/local/mailman/venv/lib/python3.10/site-packages/django_q/core_signing.py",
line 55, in unsign
raise BadSignature('Signature "%s" does not match' % sig)
django.core.signing.BadSignature: Signature "48do9gGvueBxakX_a4uNmSwD7cs"
does not match
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3.10/logging/__init__.py", line 1100, in emit
msg = self.format(record)
File "/usr/lib/python3.10/logging/__init__.py", line 943, in format
return fmt.format(record)
File "/usr/lib/python3.10/logging/__init__.py", line 678, in format
record.message = record.getMessage()
File "/usr/lib/python3.10/logging/__init__.py", line 368, in getMessage
msg = msg % self.args
TypeError: not all arguments converted during string formatting
Call stack:
File "/local/mailman/venv/bin/mailman-web", line 8, in <module>
sys.exit(main())
File
"/local/mailman/venv/lib/python3.10/site-packages/mailman_web/manage.py",
line 90, in main
execute_from_command_line(sys.argv)
File
"/local/mailman/venv/lib/python3.10/site-packages/django/core/management/__init__.py",
line 446, in execute_from_command_line
utility.execute()
File
"/local/mailman/venv/lib/python3.10/site-packages/django/core/management/__init__.py",
line 440, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File
"/local/mailman/venv/lib/python3.10/site-packages/django/core/management/base.py",
line 402, in run_from_argv
self.execute(*args, **cmd_options)
File
"/local/mailman/venv/lib/python3.10/site-packages/django/core/management/base.py",
line 448, in execute
output = self.handle(*args, **options)
File
"/local/mailman/venv/lib/python3.10/site-packages/django_q/management/commands/qcluster.py",
line 22, in handle
q.start()
File
"/local/mailman/venv/lib/python3.10/site-packages/django_q/cluster.py",
line 78, in start
self.sentinel.start()
File "/usr/lib/python3.10/multiprocessing/process.py", line 121, in start
self._popen = self._Popen(self)
File "/usr/lib/python3.10/multiprocessing/context.py", line 224, in _Popen
return _default_context.get_context().Process._Popen(process_obj)
File "/usr/lib/python3.10/multiprocessing/context.py", line 281, in _Popen
return Popen(process_obj)
File "/usr/lib/python3.10/multiprocessing/popen_fork.py", line 19, in
__init__
self._launch(process_obj)
File "/usr/lib/python3.10/multiprocessing/popen_fork.py", line 71, in
_launch
code = process_obj._bootstrap(parent_sentinel=child_r)
File "/usr/lib/python3.10/multiprocessing/process.py", line 314, in
_bootstrap
self.run()
File "/usr/lib/python3.10/multiprocessing/process.py", line 108, in run
self._target(*self._args, **self._kwargs)
File
"/local/mailman/venv/lib/python3.10/site-packages/django_q/cluster.py",
line 168, in __init__
self.start()
File
"/local/mailman/venv/lib/python3.10/site-packages/django_q/cluster.py",
line 172, in start
self.spawn_cluster()
File
"/local/mailman/venv/lib/python3.10/site-packages/django_q/cluster.py",
line 248, in spawn_cluster
self.pusher = self.spawn_pusher()
File
"/local/mailman/venv/lib/python3.10/site-packages/django_q/cluster.py",
line 201, in spawn_pusher
return self.spawn_process(pusher, self.task_queue, self.event_out,
self.broker)
File
"/local/mailman/venv/lib/python3.10/site-packages/django_q/cluster.py",
line 197, in spawn_process
p.start()
File "/usr/lib/python3.10/multiprocessing/process.py", line 121, in start
self._popen = self._Popen(self)
File "/usr/lib/python3.10/multiprocessing/context.py", line 224, in _Popen
return _default_context.get_context().Process._Popen(process_obj)
File "/usr/lib/python3.10/multiprocessing/context.py", line 281, in _Popen
return Popen(process_obj)
File "/usr/lib/python3.10/multiprocessing/popen_fork.py", line 19, in
__init__
self._launch(process_obj)
File "/usr/lib/python3.10/multiprocessing/popen_fork.py", line 71, in
_launch
code = process_obj._bootstrap(parent_sentinel=child_r)
File "/usr/lib/python3.10/multiprocessing/process.py", line 314, in
_bootstrap
self.run()
File "/usr/lib/python3.10/multiprocessing/process.py", line 108, in run
self._target(*self._args, **self._kwargs)
File
"/local/mailman/venv/lib/python3.10/site-packages/django_q/cluster.py",
line 358, in pusher
logger.error(e, traceback.format_exc())
Message: BadSignature('Signature "48do9gGvueBxakX_a4uNmSwD7cs" does not
match')
Arguments: ('Traceback (most recent call last):\n File
"/local/mailman/venv/lib/python3.10/site-packages/django_q/cluster.py",
line 356, in pusher\n task = SignedPackage.loads(task[1])\n File
"/local/mailman/venv/lib/python3.10/sit
e-packages/django_q/signing.py", line 25, in loads\n return
signing.loads(\n File
"/local/mailman/venv/lib/python3.10/site-packages/django_q/core_signing.py",
line 35, in loads\n base64d = force_bytes(TimestampSigner(key, salt=sa
lt).unsign(s, max_age=max_age))\n File
"/local/mailman/venv/lib/python3.10/site-packages/django_q/core_signing.py",
line 70, in unsign\n result = super(TimestampSigner,
self).unsign(value)\n File "/local/mailman/venv/lib/python3.10
/site-packages/django_q/core_signing.py", line 55, in unsign\n raise
BadSignature(\'Signature "%s" does not match\' %
sig)\ndjango.core.signing.BadSignature: Signature
"48do9gGvueBxakX_a4uNmSwD7cs" does not match\n',)
I'm using uwsgi via apache:
(venv) mailman@new-mailman3 ~ (v3.1.1)> more
/etc/apache2/conf-enabled/mailman3.conf
Alias /mailman3/favicon.ico /local/mailman/web/static/favicon.ico
Alias /mailman/favicon.ico /local/mailman/web/static/favicon.ico
Alias /favicon.ico /local/mailman/web/static/favicon.ico
Alias /mailman3/static /local/mailman/web/static
Alias /mailman/static /local/mailman/web/static
Alias /static /local/mailman/web/static
<Directory "/local/mailman/web/static">
Require all granted
</Directory>
<IfModule mod_proxy_uwsgi.c>
ProxyPass /mailman3/favicon.ico !
ProxyPass /mailman/favicon.ico !
ProxyPass /favicon.ico !
ProxyPass /mailman3/static !
ProxyPass /mailman/static !
ProxyPass /static !
ProxyPass /mailman3
unix:/local/mailman/var/uwsgi.sock|uwsgi://localhost/
ProxyPass /mailman
unix:/local/mailman/var/uwsgi.sock|uwsgi://localhost/
#ProxyPass /mailman3 http://localhost:8000/ timeout=180
#ProxyPass /mailman http://localhost:8000/ timeout=180
#ProxyPass / http://localhost:8000/ timeout=180
</IfModule>
Best Regards,
Helio Loureiro
https://helio.loureiro.eng.br
https://github.com/helioloureiro
https://mastodon.social/@helioloureiro
On Fri, 16 Feb 2024 at 22:39, Mark Sapiro <mark(a)msapiro.net> wrote:
> On 2/16/24 07:12, Helio Loureiro wrote:
>
> > - start mailman3 and mailman-3web
> > - run mailman3-web migrate
>
> You should run mailman3-web migrate when mailman-3web is not running.
>
> > django.db.utils.OperationalError: (1050, "Table
> > 'hyperkitty_mailinglist_moderators' already exists")
> >
> > I tried to drop the table, but then it complained about another one. I
> > dropped all the complained tables and as result hypperkitty never
> > started. So I went back to see why the first error happened.
>
> The errors occurred because you had recently added tables in your
> database so they couldn't be added by the migrations. Dropping the
> tables was the correct thing to do.
>
> Did you ultimately successfully run all the migrations?
>
> When you say `hypperkitty never started`, what exactly does that mean?
> What happens when you try to access the archives? Can you access
> postorius? Are any errors logged in mailman3-web's log?
>
> --
> Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
> San Francisco Bay Area, California better use your sense - B. Dylan
>
> _______________________________________________
> 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/
> Archived at:
> https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message…
>
> This message sent to helio(a)loureiro.eng.br
>
2 years, 7 months
Re: Starting from scratch
by Mark Sapiro
On 04/09/2018 10:01 AM, Benjamin Ragheb wrote:
>
> The two alternatives I am weighing right now are:
>
> 1. Stay the course, and see if I can fix this by learning more about Python, Pip, Django and tinkering with the configuration.
>
> 2. Ride the bleeding edge, and install postorius and hyperkitty from git. (I'll probably stick with Mailman Core from Pip, since that seemed to work just fine.)
>
> Right now I'm leaning toward #2, because it means I'll be in a better position to patch things if I need to, and it seems like Mailman 3 is still rough enough that I will need to. Also, it looks like the master branches of both postorius and hyperkitty are now Python 3 compatible, which could save me from managing two different versions of Python.
>
> Which is the least crazy option?
If you are comfortable with 2), I think that's the better option. After
PyCon in May when we release 3.2 and the rest of the suite, you should
be able to install everything with pip and have it work. I'm not sure
what the issues are now with a pip install.
There is a 3rd option. See
<https://packages.debian.org/stretch-backports/mailman3-full>
--
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
8 years, 5 months