Re: Heads up: settings.ACCOUNT_AUTHENTICATION_METHOD is deprecated
by Washington Odhiambo
On Fri, Mar 6, 2026 at 10:25 AM Thomas Krichel <krichel(a)openlib.org> wrote:
>
> This issue is still there for me. I am starting a new installation from
> scratch, with the venv method in 3.13.
>
> (venv) root@darni ~ # mailman-web migrate
> System check identified some issues:
>
> WARNINGS:
> ?: settings.ACCOUNT_AUTHENTICATION_METHOD is deprecated, use:
> settings.ACCOUNT_LOGIN_METHODS = {'email', 'username'}
> ?: settings.ACCOUNT_EMAIL_REQUIRED is deprecated, use:
> settings.ACCOUNT_SIGNUP_FIELDS = ['email*', 'username*', 'password1*',
> 'password2*']
> Operations to perform:
> Apply all migrations: account, admin, auth, contenttypes,
> django_mailman3, django_q, hyperkitty, postorius, sessions, sites,
> socialaccount
> Running migrations:
> No migrations to apply.
>
> I have
>
> root@darni /etc/mailman3 # head -15 /etc/mailman3/settings.py
> # Mailman Web configuration file.
> # /etc/mailman3/settings.py
>
> # Get the default settings.
> from mailman_web.settings.base import *
> from mailman_web.settings.mailman import *
>
> # Settings below supplement or override the defaults.
> # see
> https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/U.
> ..
> del ACCOUNT_AUTHENTICATION_METHOD
> ACCOUNT_LOGIN_METHODS = {'email', 'username'}
> del ACCOUNT_EMAIL_REQUIRED
> ACCOUNT_SIGNUP_FIELDS = ['email*', 'username*', 'password1*', 'password2*']
>
>
> Which is what I believe Wikinaut suggested works for her/him. But the
> warning is
> still there.
>
> I added Marks suggestions to add verbiage in the actual codebase
>
> root@darni /etc/mailman3 # tail -17
> /usr/local/mailman/venv/lib/python3.13/site-packages/mailman_web/settings/mailman.py
> ### added by ToK
>
> #: Django Allauth
> #ACCOUNT_AUTHENTICATION_METHOD = "username_email"
> #ACCOUNT_EMAIL_REQUIRED = True
> #ACCOUNT_EMAIL_VERIFICATION = "mandatory"
> #ACCOUNT_UNIQUE_EMAIL = True
>
> ACCOUNT_LOGIN_METHODS = {'email', 'username'}
> ACCOUNT_SIGNUP_FIELDS = ['username*', 'email*', 'password1*',
> 'password2*']
> ACCOUNT_EMAIL_VERIFICATION = "mandatory"
> ACCOUNT_UNIQUE_EMAIL = True
> ACCOUNT_EMAIL_UNKNOWN_ACCOUNTS = False
>
> del ACCOUNT_EMAIL_REQUIRED
> ACCOUNT_SIGNUP_FIELDS = ['username*', 'email*', 'password1*', 'password2*']
>
> Restarted
>
> root@darni /etc/mailman3 # systemctl restart mailman3 ; systemctl restart
> mailmanweb
>
> Same old.
>
> (venv) root@darni ~ # mailman-web migrate
> System check identified some issues:
>
> WARNINGS:
> ?: settings.ACCOUNT_AUTHENTICATION_METHOD is deprecated, use:
> settings.ACCOUNT_LOGIN_METHODS = {'email', 'username'}
> ?: settings.ACCOUNT_EMAIL_REQUIRED is deprecated, use:
> settings.ACCOUNT_SIGNUP_FIELDS = ['email*', 'username*', 'password1*',
> 'password2*']
> Operations to perform:
> Apply all migrations: account, admin, auth, contenttypes,
> django_mailman3, django_q, hyperkitty, postorius, sessions, sites,
> socialaccount
> Running migrations:
> No migrations to apply.
>
> Maybe I missunderstood something.
>
Something was said about MM3 and Python-3.13. I just don't remember it
well, but there were some incompatibility issues.
Perhaps it's better you do an alt-install of Python-3.12 and use that env
until the issues are addressed?
--
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]
2 weeks, 5 days
Member name management by list owner
by mark＠suburbia.org.au
Bottom line up front: site admins can do some of the things below via https://example.com/mailman3/postorius/users thanks to https://gitlab.com/mailman/postorius/-/issues/403 - I am going to include my original post, in case it helps for visibility should others come up against this in future:
--
Continuing in my initiation in the MM2.1 -> MM3 migration. I will say that while the software overall seems good, and the support in here has been excellent. I don't recall a more frustrating experience migrating a service in a long time.
One of my list moderators runs a closed list for their non-profit organisation, whose demographic is on the more 'wise' side of life. As such, the organisation's committee pretty much handles all the list management for members, who receive a distribution list newsletter. They don't promote the ability to subscribe/unsubscribe/manage list settings to their membership as for some, replying to emails can seem complicated.
It's been seen, (and based on the thread at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/… appears to be expected) that once an email address is first associated with mailman3, that whatever that member's name is sticks, including if the name wasn't initially used. And, that if you want to change it, you need to have the member login to/created an account at https://example.com/mailman3/user-profile/.
E.g. if I as list owner/admin:
1) Add via mass subscription a new member whose email has never been seen by Mailman3 before
`Wrong Name <specificemail(a)example.com>`
2) Search members and see it listed as
`"Wrong Name" <email(a)example.com>`
3) Unsubscribe the member from the list
4) Add via mass subscription a same member with a new name
`Correct Name <specificemail(a)example.com>`
When I look at the members list it still shows
`"Wrong Name" <email(a)example.com>`
If I'm mistaken about any of the above or that does seem like a bug, feel free to let me know. Otherwise, is there any way, without expecting the members themselves to do it, for a site admin or list admin to change the name associated with an email address? I guess in order of preference, I'd like
1) list owner/admin to be able to modify list member name through web UI
2) site owner/admin to be able to modify list member name through web UI
3) list or site admin to be able to modify list member name through command line
4) direct editing of the mariaDB database. (And if this is the best option for now, if you can tell me the name of the db/table to look at it would be appreciated)
--
Back to post BLUF solution - I guess my next ask, since the site admin can modify any user's name - would it be possible for me to grant a list owner/admin the ability to change names of any user without giving them full site admin access, and perhaps add the `Manage` button to the list's members list for them?
1 year, 3 months
Re: Performance of member listing [was: How to remove a nonmember...]
by Abhilash Raj
On Fri, Apr 17, 2020, at 5:01 PM, Abhilash Raj wrote:
>
>
> On Fri, Apr 17, 2020, at 8:54 AM, skenny(a)scss.tcd.ie wrote:
> > Hi Steve, I replied to your personal email address earlier today. - I
> > guess it's no harm to add my reply to the thread here, so here goes:
> >
> > Hi Stephen,
> >
> > Thanks for your message. The documentation I was referring to is from
> > Gunicorn, specifically this:
> >
> > http://docs.gunicorn.org/en/latest/settings.html#timeout
> >
> > (I was led to it by Abhilash's reference in the thread).
>
> Did you also add the config file in mailman.cfg
>
> [webservice]
> # Configuration for webservice.
> configuration: /path/to/gunicorn.cfg
>
> This is needed to notify Mailman of the new configuration file that you
> added. And then format and options of the config file is the URL that
> you already mentioned above. This information should be documented
> somewhere, I'll create a bug report for that.
>
> >
> > As for the length of the list, I'm talking about in the region of 1,800 members.
> >
> > When I say "pretty slow", I mean that it takes about 2.5 minutes to
> > return the list of
> > members via the REST API.
Which database backend are you using? The performance would definitely vary with different database backend but 2.5minutes in my opinion is too slow, even for the slowest SQLite database backend.
I did some benchmarking and with a SQLite database, I created a MailingList with abour 2200 members and 2000 non-members.
In [18]: %time mlist.members
CPU times: user 19.9 ms, sys: 975 µs, total: 20.9 ms
Wall time: 9.59 s
In [19]: %time mlist.nonmembers
CPU times: user 16 ms, sys: 2.88 ms, total: 18.8 ms
Wall time: 7.33 s
I don't think the list you have should be taking 2.5 minutes at all unless there is something seriously wrong.
Note that the above numbers are without pagination. My paginated Postorius page load times for nonmembers page is (from Firefox console):
5 requests 213.87 KB / 41.76 KB transferred Finish: 1.20 s
> >
> > I'm not sure I understand your last paragraph - "paginated interface"
> > and "at the receiving end"
> > don't make much sense to me at present. I should add however that I am
> > pretty novice when
> > it comes to all of this (and Python programming too). It took me a
> > while to understand
> > the difference between accessing Mailman3 via the REST API versus
> > mailman shell - for example!
> >
> > Stephen
> > _______________________________________________
> > 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)
--
thanks,
Abhilash Raj (maxking)
5 years, 11 months
Re: Internal Server Error: /mailman/accounts/fedora/login/
by matthew＠alberti.us
Kilian,
It looks like someone (or a bot) is trying to login using Fedora as
the authentication plugin; but that plugin is not configured.
You probably want to disable/comment out the Fedora plugin
INSTALLED_APPS section in the settings_local.py file.
- Matt Alberti
-----Original Message-----
From: Kilian Kilger <kkilger(a)gmail.com>
Sent: Friday, September 17, 2021 12:24 PM
To: mailman-users(a)mailman3.org
Subject: [MM3-users] Internal Server Error: /mailman/accounts/fedora/login/
Hi mailing list,
I own a mailman box. I regularily (many times a day) get mail with an
internal server error. I am using Debian and the included mailman3-full
package. I guess someone tries to hack my instance. But I don't understand
why this leads to the internal server error.
I am also wondering why the request URL is /mailman/accounts/fedora/login,
as I am using Debian (understandable if the request happens via an outside
trigger). I have no clue about the internal workings of mailman though. I
use Debian 11 bullseye and thus version 3.3.3. I can trigger the internal
server error by myself by visiting the request URL. Despite these emails the
instance seems to work fine.
Best regards,
Kilian.
Internal Server Error: /mailman/accounts/fedora/login/
TypeError at /accounts/fedora/login/
_openid_consumer() missing 2 required positional arguments: 'provider' and
'endpoint'
Request Method: GET
Request URL:
<URL>/mailman/accounts/fedora/login/?process=login&next=/mailman/accounts/pa
ssword/reset/
Django Version: 2.2.24
Python Executable: /usr/bin/uwsgi-core
Python Version: 3.9.2
Python Path: ['.', '', '/usr/lib/python39.zip', '/usr/lib/python3.9',
'/usr/lib/python3.9/lib-dynload', '/usr/local/lib/python3.9/dist-packages',
'/usr/lib/python3/dist-packages', '/usr/lib/python3.9/dist-packages']
Server time: Fr, 17 Sep 2021 06:12:57 +0000 Installed Applications:
('hyperkitty',
'postorius',
'django_mailman3',
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.messages',
'django.contrib.staticfiles',
'rest_framework',
'django_gravatar',
'compressor',
'haystack',
'django_extensions',
'django_q',
'allauth',
'allauth.account',
'allauth.socialaccount',
'django_mailman3.lib.auth.fedora')
Installed Middleware:
('django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.middleware.locale.LocaleMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
'django.middleware.security.SecurityMiddleware',
'django_mailman3.middleware.TimezoneMiddleware',
'postorius.middleware.PostoriusMiddleware')
Traceback:
File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py" in
inner
34. response = get_response(request)
File "/usr/lib/python3/dist-packages/django/core/handlers/base.py" in
_get_response
115. response = self.process_exception_by_middleware(e,
request)
File "/usr/lib/python3/dist-packages/django/core/handlers/base.py" in
_get_response
113. response = wrapped_callback(request, *callback_args,
**callback_kwargs)
File "/usr/lib/python3/dist-packages/django/views/generic/base.py" in view
71. return self.dispatch(request, *args, **kwargs)
File "/usr/lib/python3/dist-packages/django/views/generic/base.py" in
dispatch
97. return handler(request, *args, **kwargs)
File
"/usr/lib/python3/dist-packages/django_mailman3/lib/auth/fedora/views.py"
in get
56. return self.post(request, *args, **kwargs)
File
"/usr/lib/python3/dist-packages/django_mailman3/lib/auth/fedora/views.py"
in post
67. client = _openid_consumer(request)
Exception Type: TypeError at /accounts/fedora/login/ Exception Value:
_openid_consumer() missing 2 required positional
arguments: 'provider' and 'endpoint'
Request information:
USER: AnonymousUser
_______________________________________________
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, 6 months
Re: Change the default value for the General Archive Policy
by Markus Grandpré
Dear Mr Sapiro,
many thanks for your reply. When I create a mailing list without an archive, I’ve noticed that the default value under
"Settings > Archiving > Archive policy" is always set to "Public archives". I was wondering if it's possible to change
the default to "Do not archive this list" instead.
Additionally, in an earlier email, you mentioned that a more convenient way to set default values would be introduced in
an upcoming version. Could you please let me know the current status of that development?
Many thanks in advance.
Best regards,
Markus
Am 6/23/25 um 19:53 schrieb Mark Sapiro:
> On 6/23/25 08:03, Markus Grandpré wrote:
>> Dear list,
>>
>> currently, when I create a new mailing list with MM3 the value for "Archive policy" is always set to "Public
>> archives". I'd like to change the default value for "Archive policy" to "Do not archive this list". How can I do this?
>> In Debian 12 I find in </usr/lib/python3/dist-packages/postorius/forms/list_forms.py>:
> ...
>> but have no idea how to change the settings here. Your help is very appreciated.
> Are you creating the list in Postorius. If so, you have a choice for list style. Currently those choices are:
> ```
> Announce only mailing list style.
> Ordinary discussion mailing list style.
> Discussion mailing list style with private archives.
> ```
> There is currently no style for a list without archives, but you can implement one. See the thread at https://
> lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/Q6QVDWCY… for hints on how to
> do this with a plugin.
>
> Alternatively, you can do it with a patch like:
> ```
> --- a/src/mailman/styles/default.py
> +++ b/src/mailman/styles/default.py
> @@ -18,6 +18,7 @@
> """Application of list styles to new and existing lists."""
>
> from mailman.core.i18n import _
> +from mailman.interfaces.archiver import ArchivePolicy
> from mailman.interfaces.styles import IStyle
> from mailman.styles.base import (
> Announcement,
> @@ -91,3 +92,25 @@ class PrivateDefaultStyle(
> Private.apply(self, mailing_list)
> Discussion.apply(self, mailing_list)
> Moderation.apply(self, mailing_list)
> +
> +
> +@public
> +@implementer(IStyle)
> +class PublicNoArchiveStyle(
> +
> + Identity, BasicOperation, Bounces, Public, Discussion, Moderation):
> +
> + """The legacy default style with no archives."""
> +
> + name = 'legacy-default-no-archive'
> + description = _('Ordinary discussion mailing list style with no archive.')
> +
> + def apply(self, mailing_list):
> + """See `IStyle`."""
> + Identity.apply(self, mailing_list)
> + BasicOperation.apply(self, mailing_list)
> + Bounces.apply(self, mailing_list)
> + Public.apply(self, mailing_list)
> + Discussion.apply(self, mailing_list)
> + Moderation.apply(self, mailing_list)
> + mailing_list.archive_policy = ArchivePolicy.never
> ```
> If you are creating lists from the command line `mailman create`, there is a --style-name option to specify the style.
>
--
Markus Grandpré
Universität Konstanz
Kommunikations-, Informations- und Medienzentrum (KIM)
Abteilung IT-Dienste Forschung, Lehre und Infrastruktur
Sachgebiet Diensteadministration
Tel: ++49 7531 88 4342
9 months
cannot bind to lmtp host address through lmtp port(OSError: [Errno 99] error while attempting to bind on address: cannot assign requested address)
by Paul Ssekamatte
i have successfully set up mailman3 instance by following the guide at https://gitlab.com/mailman/mailman-suite-doc/blob/master/source/install/vir… and from this mailing list.
my setup uses an alias domain i.e the mail server is different from the lists server. I have successfully created an alias domain and mailing list through Postorius but I keep getting this error in syslog.
OSError: [Errno 99] error while attempting to bind on address ('xxx.xx.xx.xx', 8024): cannot assign requested address.
Even when I change the port number, I still get the same error
Kindly assist.
here is my mailman.cfg config
[paths.here]
var_dir: /opt/mailman/mm/var
[mailman]
layout: here
site_owner: postmaster(a)mail.example.com
[database]
class: mailman.database.postgresql.PostgreSQLDatabase
url: postgres://mailman:#passwd@localhost/mailman
[archiver.prototype]
enable: yes
# For the HyperKitty archiver.
[archiver.hyperkitty]
class: mailman_hyperkitty.Archiver
enable: yes
configuration: /opt/mailman/mm/mailman-hyperkitty.cfg
[shell]
history_file: $var_dir/history.py
[mta]
verp_confirmations: yes
verp_personalized_deliveries: yes
verp_delivery_interval: 1
incoming: mailman.mta.postfix.LMTP
outgoing: mailman.mta.deliver.deliver
lmtp_host: mail.example.com
lmtp_port: 8024
smtp_host: mail.example.com
smtp_port: 25
configuration: python:mailman.config.postfix
recipient_delimiter = +
unknown_local_recipient_reject_code = 550
owner_request_special = no
POSTFIX_STYLE_VIRTUAL_DOMAINS= ['example.com']
/etc/mailman3/settings.py file is as follows
from mailman_web.settings.base import *
from mailman_web.settings.mailman import *
ADMINS = (
('Mailman Suite Admin', 'root@localhost'),
)
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'NAME': 'mailmanweb',
'USER': 'mailman',
# TODO: Replace this with the password.
'PASSWORD': 'passwd',
'HOST': 'localhost',
'PORT': '5432',
}
}
STATIC_ROOT = '/opt/mailman/web/static'
LOGGING['handlers']['file']['filename'] = '/opt/mailman/web/logs/mailmanweb.log'
ALLOWED_HOSTS = [
'localhost', 'lists.example.com', 'mail.example.com', # Archiving API from Mailman, keep it.
]
SITE_ID = 1
SECRET_KEY = 'key
MAILMAN_ARCHIVER_KEY = 'key
DEFAULT_FROM_EMAIL = 'postmaster(a)example.com'
SERVER_EMAIL = 'postmaster(a)example.com'
HAYSTACK_CONNECTIONS = {
'default': {
'ENGINE': 'haystack.backends.whoosh_backend.WhooshEngine',
'PATH': os.path.join(BASE_DIR, "fulltext_index"),
},
}
/etc/postfix/main.cf is as follows
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no
append_dot_mydomain = no
readme_directory = no
compatibility_level = 2
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydomain = example.com
myhostname = lists.example.com
mydestination = $myhostname, localhost.$mydomain, localhost
relayhost = mail.example.com
myorigin = $mydomain
mynetworks = 127.0.0.0/8, 10.0.0.0, 192.0.0.1, [::ffff:127.0.0.0]/104 [::1]/128
mynetworks_style = subnet
mailbox_size_limit = 4096000000
#message_size_limit = 2048000000
recipient_delimiter = +
inet_interfaces = all
#inet_protocols = all
inet_protocols = ipv4
unknown_local_recipient_reject_code = 550
owner_request_special = no
virtual_mailbox_domains = example.com
virtual_mailbox_base = /var/vmail
virtual_uid_maps = static:20000
virtual_gid_maps = static:20000
transport_maps = hash:/opt/mailman/mm/var/data/postfix_lmtp
local_recipient_maps = proxy:unix:passwd.byname $alias_maps
hash:/opt/mailman/mm/var/data/postfix_lmtp
relay_domains = hash:/opt/mailman/mm/var/data/postfix_domains
virtual_alias_maps = hash:/opt/mailman/mm/var/data/postfix_vmap
postfix domains as follows:
lists.example.com example.com
postfix lmtp as follows:
testlist(a)lists.example.com lmtp:[mail.example.com]:8024
testlist-bounces(a)lists.example.com lmtp:[mail.example.com]:8024
testlist-confirm(a)lists.example.com lmtp:[mail.example.com]:8024
postfix vmap as follows:
testlist(a)example.com nmutest(a)lists.example.com
testlist-bounces(a)example.com nmutest-bounces(a)lists.example.com
testlist-confirm(a)example.com nmutest-confirm(a)lists.example.com
3 years, 5 months
Re: Trouble Installing Mailman3
by Henry Hartley
> -----Original Message-----
> From: Stephen J. Turnbull <steve(a)turnbull.jp>
> Sent: Thursday, June 12, 2025 08:17
> Subject: [MM3-users] Re: Trouble Installing Mailman3
>
> Henry Hartley via Mailman-users writes:
>
> > This isn't doing a lot for my self-esteem.
>
> I don't think you need to worry about you. :-) There are dozens of moving parts
> involved, each of which sets its own requirements and is continuously being
> updated. And you're working in a virtual environment, which is a fragile hack.
> Works well if you treat it right, but does need care.
Thanks for your encouraging words.
> There are two ways those two messages can be consistent: that pip's version
> number parsing is buggy, or those aren't the same pip. The former explanation,
> while possible, is highly unlikely.
>
> One common explanation for this kind of conflict is that you did part of the
> installation with the venv active, and part without. I know you wrote that you
> are "running as the mailman user in venv", but just to double check, does "in"
> mean "current working directory is venv" or does it mean "venv is activated
> with '. bin/activate'" as well? You need to activate the venv to get all of the
> paths (especially to the "pip" and "python" commands) right.
Here's what I mean when I say I'm doing this "in venv"
I've become the mailman user: sudo su - mailman
The .bashrc for that user includes: source /opt/mailman/venv/bin/activate
The prompt has (venv) at the left end of it: (venv) mailman@wz-prd-tpmd-1:~$
All pip commands have been run in this state. I did first install setuptools with apt install python3-setuptools and that installed version 68.1.2-2ubuntu1.2.
Note that I'm still not sure the firewall is completely out of the picture, since I do have to include the --trusted-host and --proxy options. Some things install, though, so I think that's OK.
When I do this at the (venv) prompt, asking to install both setuptools and mailman-web:
pip install --proxy http://webproxyta.westat.com:3128 --trusted-host pypi.org setuptools mailman-web
The first line of the output is:
Requirement already satisfied: setuptools in ./venv/lib/python3.12/site-packages (80.9.0)
And that's followed by downloading (or using a cached version) of 11 items before I get the subprocess error.
> I took a look at a fairly recent install of django-haystack, and in the .dist-info it
> says the installer is 'pip' rather than 'pip3'. IMO this is bad practice, even today.
> One possible explanation is that somehow at an intermediate stage the install
> script is picking up a Python 2 pip, and IIRC Python 2 setuptools goes only to
> 58.x or 59.x.
> Or if you're in a Debian environment, I seem to recall the Debian Python 3
> environment does not provide setuptools at all (and deliberately makes it hard
> to install outside of a venv).
>
> Check if your venv bin directory has a pip executable (or symlink to the
> executable). If not, adding a symlink pip -> pip3 may help.
There is no Python2 on the system so I'm pretty sure it's not that. The pip being used seems to be the right one and pip and pip3 seem to be the same:
(venv) mailman@wz-prd-tpmd-1:~$ pwd
/opt/mailman
(venv) mailman@wz-prd-tpmd-1:~$ which pip
/opt/mailman/venv/bin/pip
(venv) mailman@wz-prd-tpmd-1:~$ which pip3
/opt/mailman/venv/bin/pip3
(venv) mailman@wz-prd-tpmd-1:~$ pip -V
pip 24.0 from /opt/mailman/venv/lib/python3.12/site-packages/pip (python 3.12)
(venv) mailman@wz-prd-tpmd-1:~$ pip3 -V
pip 24.0 from /opt/mailman/venv/lib/python3.12/site-packages/pip (python 3.12)
(venv) mailman@wz-prd-tpmd-1:~$ cmp venv/bin/pip venv/bin/pip3
(venv) mailman@wz-prd-tpmd-1:~$ pip cache purge
Files removed: 44
(venv) mailman@wz-prd-tpmd-1:~$ /opt/mailman/venv/bin/pip install --proxy http://webproxyta.westat.com:3128 --trusted-host pypi.org setuptools mailman-web
Requirement already satisfied: setuptools in ./venv/lib/python3.12/site-packages (80.9.0)
Collecting mailman-web
Downloading mailman_web-0.0.9-py3-none-any.whl.metadata (3.2 kB)
Collecting django<4.3,>=4.0 (from mailman-web)
Downloading django-4.2.23-py3-none-any.whl.metadata (4.2 kB)
Collecting hyperkitty (from mailman-web)
Downloading hyperkitty-1.3.12-py3-none-any.whl.metadata (3.6 kB)
Collecting postorius (from mailman-web)
Downloading postorius-1.3.13-py3-none-any.whl.metadata (2.9 kB)
Collecting whoosh (from mailman-web)
Downloading Whoosh-2.7.4-py2.py3-none-any.whl.metadata (3.1 kB)
Collecting asgiref<4,>=3.6.0 (from django<4.3,>=4.0->mailman-web)
Downloading asgiref-3.8.1-py3-none-any.whl.metadata (9.3 kB)
Collecting sqlparse>=0.3.1 (from django<4.3,>=4.0->mailman-web)
Downloading sqlparse-0.5.3-py3-none-any.whl.metadata (3.9 kB)
Collecting django-compressor>=1.3 (from hyperkitty->mailman-web)
Downloading django_compressor-4.5.1-py2.py3-none-any.whl.metadata (5.0 kB)
Collecting django-extensions>=1.3.7 (from hyperkitty->mailman-web)
Downloading django_extensions-4.1-py3-none-any.whl.metadata (6.1 kB)
Collecting django-gravatar2>=1.0.6 (from hyperkitty->mailman-web)
Downloading django_gravatar2-1.4.5-py2.py3-none-any.whl.metadata (4.3 kB)
Collecting django-haystack>=2.8.0 (from hyperkitty->mailman-web)
Downloading django_haystack-3.3.0.tar.gz (467 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 467.3/467.3 kB 22.3 MB/s eta 0:00:00
Installing build dependencies ... error
error: subprocess-exited-with-error
× pip subprocess to install build dependencies did not run successfully.
│ exit code: 1
╰─> [2 lines of output]
ERROR: Could not find a version that satisfies the requirement setuptools>=61.2 (from versions: none)
ERROR: No matching distribution found for setuptools>=61.2
[end of output]
note: This error originates from a subprocess, and is likely not a problem with pip.
error: subprocess-exited-with-error
× pip subprocess to install build dependencies did not run successfully.
│ exit code: 1
╰─> See above for output.
note: This error originates from a subprocess, and is likely not a problem with pip.
--
Henry
9 months, 1 week
Weird startup problem after upgrade
by Odhiambo Washington
I am facing an odd situation in which MM3 doesn't start successfully on
reboot, but I can start it manually.
This is a venv install.
This started after I did an upgrade (pip install --upgrade mailman
postorius hyperkitty mailman-hyperkitty) followed by the requisite
collectstatic|compress|compilemessages|migrate
post-update commands.
Secondly, it appears that the upgrade did NOT change the versions for the
upgraded components - postorius=1.3.6, hyperkitty=1.3.5,
Mailman Core Version=3.3.5. I was expecting the version to all bump up to
the latest.
Thanks in advance for any insights into what could be causing this.
wash@lists:~$ systemctl status mailman3
× mailman3.service - GNU Mailing List Manager
Loaded: loaded (/etc/systemd/system/mailman3.service; enabled; vendor
preset: enabled)
Active: failed (Result: timeout) since Fri 2022-12-02 18:58:13 EAT; 9s
ago
CPU: 25.241s
Dec 02 18:58:12 lists mailman[1637]: File
"/opt/mailman/mm/venv/lib/python3.10/site-packages/mailman/core/runner.py",
line 114, in signal_handler
Dec 02 18:58:12 lists mailman[1639]: for atexit_call in
reversed(_threading_atexits):
Dec 02 18:58:12 lists mailman[1639]: File
"/opt/mailman/mm/venv/lib/python3.10/site-packages/mailman/core/runner.py",
line 114, in signal_handler
Dec 02 18:58:12 lists mailman[1637]: raise RunnerInterrupt
Dec 02 18:58:12 lists mailman[1639]: raise RunnerInterrupt
Dec 02 18:58:12 lists mailman[1637]:
mailman.interfaces.runner.RunnerInterrupt:
Dec 02 18:58:12 lists mailman[1639]:
mailman.interfaces.runner.RunnerInterrupt:
Dec 02 18:58:13 lists systemd[1]: mailman3.service: Failed with result
'timeout'.
Dec 02 18:58:13 lists systemd[1]: Failed to start GNU Mailing List Manager.
Dec 02 18:58:13 lists systemd[1]: mailman3.service: Consumed 25.241s CPU
time.
root@lists:/home/wash# systemctl status mailman3
× mailman3.service - GNU Mailing List Manager
Loaded: loaded (/etc/systemd/system/mailman3.service; enabled; vendor
preset: enabled)
Active: *failed (Result: timeout) since Fri 2022-12-02 18:58:13 EAT;
53s ago*
CPU: 25.241s
Dec 02 18:58:12 lists mailman[1637]: File
"/opt/mailman/mm/venv/lib/python3.10/site-packages/mailman/core/runner.py",
line 114, in signal_handler
Dec 02 18:58:12 lists mailman[1639]: for atexit_call in
reversed(_threading_atexits):
Dec 02 18:58:12 lists mailman[1639]: File
"/opt/mailman/mm/venv/lib/python3.10/site-packages/mailman/core/runner.py",
line 114, in signal_handler
Dec 02 18:58:12 lists mailman[1637]: raise RunnerInterrupt
Dec 02 18:58:12 lists mailman[1639]: raise RunnerInterrupt
Dec 02 18:58:12 lists mailman[1637]:
mailman.interfaces.runner.RunnerInterrupt:
Dec 02 18:58:12 lists mailman[1639]:
mailman.interfaces.runner.RunnerInterrupt:
*Dec 02 18:58:13 lists systemd[1]: mailman3.service: Failed with result
'timeout'.Dec 02 18:58:13 lists systemd[1]: Failed to start GNU Mailing
List Manager.Dec 02 18:58:13 lists systemd[1]: mailman3.service: Consumed
25.241s CPU time.*
root@lists:/home/wash# cd /opt/mailman/mm/var/logs/
root@lists:/opt/mailman/mm/var/logs# ls -al
total 104948
drwxr-xr-x 2 mailman mailman 4096 Dec 2 18:56 .
drwxr-xr-x 12 mailman mailman 4096 Dec 2 18:58 ..
-rw-r--r-- 1 mailman mailman 7720631 Dec 2 18:52 access.log
-rw-rw---- 1 mailman mailman 1514 Nov 28 05:58 bounce.log
-rw-rw---- 1 mailman mailman 0 Aug 15 16:56 debug.log
-rw-r--r-- 1 mailman mailman 497 Dec 2 18:56 error.log
-rw-rw---- 1 mailman mailman 99339919 Dec 2 18:58 mailman.log
-rw-r--r-- 1 mailman mailman 0 Dec 2 18:53 mailmansuite.log
-rw-rw---- 1 mailman mailman 0 Aug 15 16:56 plugins.log
-rw-rw---- 1 mailman mailman 374961 Dec 2 18:56 smtp.log
root@lists:/opt/mailman/mm/var/logs# less error.log
root@lists:/opt/mailman/mm/var/logs# cd ../locks/
root@lists:/opt/mailman/mm/var/locks# ls -al
total 8
drwxr-xr-x 2 mailman mailman 4096 Dec 2 18:58 .
drwxr-xr-x 12 mailman mailman 4096 Dec 2 18:58 ..
root@lists:/opt/mailman/mm/var/locks# systemctl start mailman3
root@lists:/opt/mailman/mm/var/locks# systemctl status mailman3
● mailman3.service - GNU Mailing List Manager
Loaded: loaded (/etc/systemd/system/mailman3.service; enabled; vendor
preset: enabled)
Active: active (running) since Fri 2022-12-02 19:00:15 EAT; 11s ago
Process: 2395 ExecStart=/opt/mailman/mm/bin/mailman start (code=exited,
status=0/SUCCESS)
Main PID: 2397 (python3)
Tasks: 18 (limit: 4550)
Memory: 791.9M
CPU: 21.440s
CGroup: /system.slice/mailman3.service
├─2397 /opt/mailman/mm/venv/bin/python3
/opt/mailman/mm/venv/bin/master -C /opt/mailman/mm/mailman.cfg
├─2398 /opt/mailman/mm/venv/bin/python3
/opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/mailman.cfg
--runner=archive:0:1
├─2399 /opt/mailman/mm/venv/bin/python3
/opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/mailman.cfg
--runner=bounces:0:1
├─2400 /opt/mailman/mm/venv/bin/python3
/opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/mailman.cfg
--runner=command:0:1
├─2401 /opt/mailman/mm/venv/bin/python3
/opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/mailman.cfg
--runner=in:0:1
├─2402 /opt/mailman/mm/venv/bin/python3
/opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/mailman.cfg
--runner=lmtp:0:1
├─2403 /opt/mailman/mm/venv/bin/python3
/opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/mailman.cfg
--runner=nntp:0:1
├─2404 /opt/mailman/mm/venv/bin/python3
/opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/mailman.cfg
--runner=out:0:1
├─2405 /opt/mailman/mm/venv/bin/python3
/opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/mailman.cfg
--runner=pipeline:0:1
├─2406 /opt/mailman/mm/venv/bin/python3
/opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/mailman.cfg
--runner=rest:0:1
├─2407 /opt/mailman/mm/venv/bin/python3
/opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/mailman.cfg
--runner=retry:0:1
├─2408 /opt/mailman/mm/venv/bin/python3
/opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/mailman.cfg
--runner=task:0:1
├─2409 /opt/mailman/mm/venv/bin/python3
/opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/mailman.cfg
--runner=virgin:0:1
├─2410 /opt/mailman/mm/venv/bin/python3
/opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/mailman.cfg
--runner=digest:0:1
├─2423 /opt/mailman/mm/venv/bin/python3
/opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/mailman.cfg
--runner=rest:0:1
└─2424 /opt/mailman/mm/venv/bin/python3
/opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/mailman.cfg
--runner=rest:0:1
Dec 02 19:00:13 lists systemd[1]: Starting GNU Mailing List Manager...
Dec 02 19:00:14 lists mailman[2395]: Starting Mailman's master runner
Dec 02 19:00:14 lists mailman[2395]: Generating MTA alias maps
*Dec 02 19:00:14 lists systemd[1]: mailman3.service: Can't open PID file
/opt/mailman/mm/var/master.pid (yet?) after start: Operation not permitted*
Dec 02 19:00:15 lists systemd[1]: Started GNU Mailing List Manager.
--
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)
3 years, 3 months
Re: problems installing mailman3 under gentoo and upgrading mailman2 to mailman3
by John Covici
I don't think this reply got to the mailing list, so I am sending it
again, sorry if its a duplicate.
On Sat, 13 Mar 2021 00:33:58 -0500,
Mark Sapiro wrote:
>
> On 3/12/21 7:36 PM, John Covici wrote:
> > Hi. I am having a great deal of difficulty installing mailman3 using
> > gentoo and sendmail. Also, I want to upgrade my old mailman2 data to
> > mailman3.
> >
> > What I have done so far is to install the mailman3 packages from my
> > repository and got this:
> > django-mailman3 version 1.3.4, mailmanclient version 3.3.1, mailman
> > version 3.3.2 (apparently the core), postorius version 1.3.3 and
> > hyperkitty version 1.3.3. I also have mariadb and postgresql already installed.
>
>
> Are these gentoo packages? If so, I have no idea how they are
> configured.
Anyway I can tell, there was no configuration (we call them use flags)
they just seemed to install the files in what seems to be the correct
places.
>
>
> > Now trying to read your documentation, it seems it wants me to
> > reinstall some packages using pip in the home directory of the mailman
> > user in a python virtual environment, that was the first thing. But I
> > would like to avoid multiple package managers wherever possible --
> > gentoo is already a lot of maintainance without dealing with pip's
> > maintainance. The binaries also seem to be different from my gentoo packages.
>
>
> Our documantation generally covers installing from source. If you are
> installing gentoo packages, you should be looking at gentoo docs and
> going to gentoo for help.
>
> We recommend installing Mailman and the web components in a virtualenv,
> but it is not a requirement. We also suggest that postgresql is a better
> choice than MariaDB.
>
I sort of am installing from source, gentoo installs from source. No
one on the gentoo users mailing list seems to be able to help me,
except to tell me to use a different mailing list mechanism called
mlmmj.
>
> > So, how do I proceed with getting mailman3 up and working, configuring
> > the database, configs, etc and I guess after doing that upgrading
> > mailman2 and getting sendmail to interface properly with mailman3?
>
> Importing lists from Mailman 2 is done with the `mailman import21`
> command. See
> <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/commands/d…>.
> Importing archives is done with the Django management
> `hyperkitty_import` command. See
> <https://docs.mailman3.org/projects/hyperkitty/en/latest/install.html#import…>
>
> For sendmail, see
> <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/mta.h…>
Thanks.
--
Your life is like a penny. You're going to lose it. The question is:
How do
you spend it?
John Covici wb2una
covici(a)ccs.covici.com
--
Your life is like a penny. You're going to lose it. The question is:
How do
you spend it?
John Covici wb2una
covici(a)ccs.covici.com
5 years
Re: Problems with New MM3 Installation
by Mark Sapiro
On 5/11/21 7:46 PM, Jeff wrote:
>
> I really appreciate your assistance. New messages are now being archived as expected, but I still have a few small remaining issues to work out with my MM3 installation:
>
> 1) some emails that arrived before I got the archive working are still sitting in:
>
> /usr/local/mailman3/mm/var/archives/prototype/[listname]@[domain]/new
>
> Strangely this includes at least one email that was archived. Should this directly be cleared as messages are archived? Is there a way to force it to be cleared?
/usr/local/mailman3/mm/var/archives/prototype/[listname]@[domain] is a
collection of messages in maildir format. This is how the prototype
archiver stores messages. This has nothing to do with HyperKitty. It is
a separate archiver. If you don't want messages to be stored there, you
can disable the prototype archiver for the list by unchecking prototype
in Postorius -> Settings -> Archiving -> Active archivers or disable it
entirely for the installation by setting
```
[archiver.prototype]
enable: no
```
in mailman.cfg
> 2) Some messages that arrived while I was having other problems with the setup have been stored in:
>
> /usr/local/mailman3/mm/var/queue/shunt
>
> What should I do to get these messages processed?
Assuming the issues that caused them to be shunted have been fixed, just
run the command
```
mailman unshunt
```
> 3) Similar to above, some messages are in:
>
> /usr/local/mailman3/mm/var/queue/bad
>
> How can I get these messages processed?
First examine the messages with
```
mailman qfile /usr/local/mailman3/mm/var/queue/bad/<file>
```
To be sure you want them. Also examine mailman.log for the times they
were stored in the `bad` queue. You are looking for 'Skipping and
preserving unparseable message: <file>' and/or 'SHUNTING FAILED,
preserving original entry: <file> messages and you want to determine
which runner preserved the message. There may be a 'whichq' entry in the
message's metadata in which case, that's the answer.
Once you have determined the queue, you can just move the .psv file from
the bad queue to the appropriate queue, renaming it from .psv to .pck in
the process.
> 4 Modified the template for “list:admin:action:post” through Postorious and emails that arrived after that were put in the “shunt” queue. I traced this problem to POSTORIUS_TEMPLATE_BASE_URL. By default, it is set to "http://localhost:8000 <http://localhost:8000/>” which is where uwsgi is listening. However, uwsigi is listening for uwsgi:/ not http://. Should I change POSTORIUS_TEMPLATE_BASE_URL to “uwsgi://localhost:8000 <uwsgi://localhost:8000>” or keep http but make it something else?
I know little about uwsgi. setting it to `uwsgi://localhost:8000` might
work. You could also set it to the base URL that a user would use to
access the web UI, e.g. `https://example.com` and that would presumably
be proxied to uwsgi. For example, on the server for this list we have
```
POSTORIUS_TEMPLATE_BASE_URL = 'https://lists.mailman3.org'
```
which gets proxied to gunicorn, but the idea is the same.
--
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
4 years, 10 months