Re: Mailmanweb RAM Usage
by Odhiambo Washington
On Sat, Oct 11, 2025 at 5:10 PM Stephen J. Turnbull <steve(a)turnbull.jp>
wrote:
> Odhiambo Washington via Mailman-users writes:
>
> > Using the uwsgi.ini from the virtualenv method documentation,
> > mailmanweb is constantly using 2GB RAM on my server.
>
> Do you mean only HyperKitty + Postorius? That seems like a lot. My
> experience is that even on an insanely heavily loaded server (20k+
> lists) the whole suite uses about 2.0G. Since on that server, Mailman
> core was forking 22 processes at ~83MB each (very little shared, not
> sure the technical reason for that, maybe the Python heap just can't
> be shared?), core was taking up about 1.8G. HyperKitty and Postorius
> took a little more (I don't recall exactly, maybe 250MB?)
>
Yes, just Hyperkitty+Postorius: Please see https://imgur.com/a/LPAY69N
It represents what I see daily when I run btop.It's always around 2GB, but
rarely do I see above.
I only have 1 major active mailing list on this server. There are other
inactive ones.
The main ML has been active since 2005. I migrated it to MM3 from MM2.1.39.
> My more standard setup (that one had like 2 IN queue slices and 8 OUT
> queue slices) I ran Mailman suite + PostgreSQL (dedicated to Mailman)
> + Postfix + nginx (also mostly dedicated to Mailman) + Cyrus IMAPd in
> a nominal 2GB Digital Ocean droplet. It didn't run "comfortably",
> adding any serious load that chewed up 100s of MB RAM would get things
> OOM-killed, but 2GB total (including kernel and all) was barely enough
> for that system in normal situations.
>
> > My database (MariaDB) size is 2GB.
>
> Do you mean in memory or on disk? Either way that should have ~0
> effect on the size of the Mailman core and web processes.
>
My MM3 database size on disk.
> > Is this expected?
>
> Depends on if you mean exactly what you said ("mailmanweb"). If so,
> no, I would expect mailmanweb (only) to run in 500MB easily and
> probably be OK in 250MB. If you mean "when I start Mailman and
> mailmanweb, memory usage jumps by about 2GB", then yes, that's what
> I'd expect.
>
In my case, the ~2GB RAM consumption by the uwsgi process is a constant.
--
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]
8 months, 1 week
Re: Converting non-members to members
by Abhilash Raj
On Tue, Dec 18, 2018, at 2:55 AM, Alan So wrote:
> Postorius is not currently exposing non-members management. Our Mailman
> 2 users are currently using accept_these_nonmembers,
> hold_these_nonmembers and reject_these_nonmembers. We know that
> mailman import21 will change these to nonmembers entries in Mailman 3.
> Since list owners will still want to manage them, we tend to move all
> of them to members and turn off delivery status for them.
I have been (slowly) working on exposing non-member management in
Postorius (Mailman's web ui). I am hoping to complete it soon, but there
is not clear ETA for it yet. I hope that it will be done soon.
> However, we met some difficulties when we try to develop using mailman
> client.
Can you also please share the snippet of code you used for the these operations
below so that we can help you fix them?
> 1) If those non-members addresses already exist as members, we will
> encounter error when we subscribe for them: urllib.error.HTTPError:
> HTTP Error 409: b'Member already subscribed'
Do you expect something else here?
Any response with non-2XX status code is raised as HTTP Error in MailmanClient.
> 2) We cannot change the moderation_action: urllib.error.HTTPError: HTTP
> Error 400: b'Cannot convert parameters: moderation_action'
I'd need to see the code fr this one, not sure what value did you pass here.
You should be able to do:
>>> member1.moderation_action = 'hold'
>>> member1.save()
Allowed values should be:
- hold
- reject
- discard
- accept
- defer = 4
> 3) We cannot change the preference: urllib.error.HTTPError: HTTP Error
> 400: b'Cannot convert parameters: delivery_status'
This is again depends on what you are passing as value for the parameter.
Allowed values are:
- enabled
- by_user (disabled by user)
- by_bounces (disabled due to bounces)
- by_moderator (disabled due to moderator)
- unknown (disabled for unknown reason
>
> Are there any better ways to enable the list owners to manage those
> previously configured nonmembers' addresses through the web?
I am working on adding the support in the web ui, so yes, there will be
better ways to manage those in future.
> Otherwise, we probably need to have some manual effort to overcome the
> above three issues. We know that we can always do the above manually
> but we got a lot of lists to migrate to Mailman 3.
> _______________________________________________
> 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)
7 years, 6 months
Re: Docker Support Sucks
by Brian Carpenter
On 7/21/20 8:55 PM, Mark Sapiro wrote:
> On 7/21/20 5:40 PM, Brian Carpenter wrote:
>
> Abhilash (@maxking) is one person and he has a $DayJob. We're all doing
> the best we can.
Well, I still need support.
> This is not a Docker issue per se. It is a consequence of upgrading
> Mailman core to 3.3.1+ and processing many old, stale, previously
> unprocessed bounces. See
> <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/…>
I am not worried about the bounce issues at this point. I am just trying
to get a membership list exported for a client.
>
>> So, I want to totally move away from the use of Docker (mainly because I have found it buggy and the support is simply lacking) and install Mailman 3 for this client from source. However I need to get an export of their list members. But of course, I can't. Rest API times out and I don't know how to apply the instructions I was given to fix it and I don't have days to way for one. So please help.
>>
>> I increased the gunicorn workers to 4, hoping that would allow me to do the CSV export. No. So was given these instructions:
>>
>> ###
>> The issues seems to be due to timeout not due to high load. You want to increase the timeout for gunicorn and you can do that by specifying a gunicorn.ini config file:
>>
>> [webservice]
>> configuration: /path/to/gunicorn.cfg
>>
>> and then in the gunicorn.cfg you can add
>>
>> [gunicorn]
>> timeout = 90
>> graceful_timeout = 30
>> ###
>>
>> I applied the above changes to /opt/mailman/core/mailman-extra.cfg and created the gunicorn.cfg file. Restarted the docker container (mailman-core) and no access to Postorius due to no REST api.
>>
>> After restarting docker-mailman, I can't access Postorius due to the following error:
>>
>> ERROR 2020-07-20 20:16:27,351 15 postorius Mailman REST API not available
> Is Mailman core running? If not, whats in core's mailman.log as to why not?
It looks like but no error message in mailman.log. However I noted that
the gunicorn process did not start.
This is with the configuration line enabled in mailman-extra.cfg:
# docker-compose restart mailman-core
Restarting mailman-core ... done
[root@nicu-net docker-mailman]# tail -f
/opt/mailman/core/var/logs/mailman.log
Jul 22 01:25:17 2020 (22) in runner caught SIGTERM. Stopping.
Jul 22 01:25:17 2020 (25) out runner caught SIGTERM. Stopping.
Jul 22 01:25:17 2020 (25) out runner exiting.
Jul 22 01:25:17 2020 (21) command runner exiting.
Jul 22 01:25:17 2020 (22) in runner exiting.
Jul 22 01:25:17 2020 (24) nntp runner caught SIGTERM. Stopping.
Jul 22 01:25:17 2020 (24) nntp runner exiting.
[2020-07-22 01:25:19 +0000] [27] [INFO] Shutting down: Master
Jul 22 01:25:21 2020 (1) Master stopped
Jul 22 01:25:26 2020 (1) Master started
Jul 22 01:25:44 2020 (27) rest runner started.
Jul 22 01:25:44 2020 (26) pipeline runner started.
Jul 22 01:25:44 2020 (20) bounces runner started.
Jul 22 01:25:45 2020 (22) in runner started.
Jul 22 01:25:45 2020 (28) retry runner started.
Jul 22 01:25:46 2020 (29) virgin runner started.
Jul 22 01:25:46 2020 (25) out runner started.
Jul 22 01:25:46 2020 (23) lmtp runner started.
Jul 22 01:25:46 2020 (24) nntp runner started.
Jul 22 01:25:47 2020 (30) digest runner started.
Jul 22 01:25:47 2020 (19) archive runner started.
Jul 22 01:25:47 2020 (21) command runner started.
This is with the configuration line disabled in mailman-extra.cfg:
# docker-compose restart mailman-core
Restarting mailman-core ... done
[root@nicu-net docker-mailman]# tail -f
/opt/mailman/core/var/logs/mailman.log
Jul 22 01:27:49 2020 (1) Master stopped
Jul 22 01:27:53 2020 (1) Master started
Jul 22 01:28:10 2020 (30) digest runner started.
Jul 22 01:28:10 2020 (29) virgin runner started.
Jul 22 01:28:10 2020 (24) nntp runner started.
Jul 22 01:28:10 2020 (25) out runner started.
Jul 22 01:28:10 2020 (22) in runner started.
Jul 22 01:28:11 2020 (28) retry runner started.
Jul 22 01:28:11 2020 (27) rest runner started.
[2020-07-22 01:28:11 +0000] [27] [INFO] Starting gunicorn 19.9.0
[2020-07-22 01:28:11 +0000] [27] [INFO] Listening at:
http://172.19.199.2:8001 (27)
[2020-07-22 01:28:11 +0000] [27] [INFO] Using worker: sync
[2020-07-22 01:28:11 +0000] [32] [INFO] Booting worker with pid: 32
[2020-07-22 01:28:11 +0000] [33] [INFO] Booting worker with pid: 33
[2020-07-22 01:28:11 +0000] [34] [INFO] Booting worker with pid: 34
[2020-07-22 01:28:11 +0000] [35] [INFO] Booting worker with pid: 35
Jul 22 01:28:11 2020 (19) archive runner started.
Jul 22 01:28:11 2020 (21) command runner started.
Jul 22 01:28:12 2020 (23) lmtp runner started.
Jul 22 01:28:12 2020 (20) bounces runner started.
Jul 22 01:28:12 2020 (26) pipeline runner started.
--
Please let me know if you need further assistance.
Thank you for your business. We appreciate our clients.
Brian Carpenter
EMWD.com
--
EMWD's Knowledgebase:
https://clientarea.emwd.com/index.php/knowledgebase
EMWD's Community Forums
http://discourse.emwd.com/
5 years, 11 months
Re: Core, Hyperkitty and Postorius releases
by Odhiambo Washington
On Sat, May 15, 2021 at 12:24 AM Abhilash Raj <maxking(a)asynchronous.in>
wrote:
>
>
> On Fri, May 14, 2021, at 2:16 PM, Odhiambo Washington wrote:
> > On Sat, May 15, 2021 at 12:01 AM Mark Sapiro <mark(a)msapiro.net> wrote:
> >
> > > On 5/14/21 1:54 PM, Odhiambo Washington wrote:
> > > >
> > > > /usr/local/include/sass
> > > >
> > > > That is the only thing found that is in the base system.
> > >
> > > And that's the one you want. What is it's mode?
> > >
> >
> > root@gw:/usr/home/wash # ls -al /usr/local/include/sass
> > total 104
> > drwxr-xr-x 2 root wheel 512 Apr 16 16:49 .
> > drwxr-xr-x 176 root wheel 10240 Apr 19 18:05 ..
> > -rw-r--r-- 1 root wheel 2369 Apr 8 11:08 base.h
> > -rw-r--r-- 1 root wheel 10742 Apr 8 11:08 context.h
> > -rw-r--r-- 1 root wheel 6632 Apr 8 11:08 functions.h
> > -rw-r--r-- 1 root wheel 6489 Apr 8 11:08 values.h
> > -rw-r--r-- 1 root wheel 198 Apr 8 11:08 version.h
> >
> > I imagined I needed an executable.
>
> This sounds like a result of you running `pip3 install sass`, probably
> with sudo
> which failed mid-way due to the exception you posted above.
>
Closer to the truth! It failed. I was running this from within the
virtualenv.
> Which OS are you using?
FreeBSD.
> On debian/ubuntu, you can install:
>
> sudo apt install sassc
>
Do I need to install sassc in the base OS or in the virtualenv?
> I am not exactly sure how it got removed during your upgrade
> to the new version of Mailman since it shouldn't affect your system
> packages.
>
The funny part is my MM3 used to run. Mark took so much hand-holding for me
to get it running.
Then one day I used the update process and things got hosed.
The happy part is that I had not put any production lists on MM3 as I
hadn't developed the confidence of managing it.
Did you install Mailman initially using system packages or instructions
> provided at [1]?
>
> [1]:
> https://docs.mailman3.org/en/latest/install/virtualenv.html#virtualenv-inst…
No. I relied on
https://wiki.list.org/DOC/Mailman%203%20installation%20experience. This is
way back!
Your new link is recent, no?
--
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", egrep -v "^$|^.*#" :-)
5 years, 1 month
Re: remove website example.com via django interface
by Odhiambo Washington
On Wed, Mar 26, 2025 at 6:09 PM Alexander Inzinger-Zrock via Mailman-users <
mailman-users(a)mailman3.org> wrote:
> remove website 'example.com' via django interface
> or
> "how to rush jourself off your feet"
>
>
> **Disclaimer: don't try this at home**
>
>
> in believe to replace the display of 'example.com' in the
> postorius-webinterface i logged into django-interface, under 'website'
> (very bottom of the left menu) i added my new website and then deleted
> 'example.com'.
>
> Result: i can't access my webinterfaces any more, neither django nor
> postorius.
>
>
> Questions:
>
> 1. Does somebody know about the correct approach to change the displayed
> url in the postorius-webinterface?
>
The displayed URL should be the one you configured in Nginx or Apache.
example.com is usually SITE_ID=1.
It's possible to rename it in Django admin UI to whatever you want - like
mywebsite.name
> 2. does somebody perhaps know how to revert those removal via CLI or
> other ways?
>
```
SQL: select * from django_site;
```
Whatever ID shows for the one you created, stick that ID to settings.py and
restart mailmanweb.
--
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
In an Internet failure case, the #1 suspect is a constant: DNS.
"Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)
[How to ask smart questions:
http://www.catb.org/~esr/faqs/smart-questions.html]
1 year, 2 months
Re: Fwd: Re: Removing a mail addresses and users
by Brian Carpenter
Allan Hansen wrote:
> 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.
Mark said it well. The problem is not with core (which I love very much). The issue you are having is with the decision to use Django. With Affinity, I believe we are using Mailman 3 core to it's (almost) full potential. For instance, the server owner (site admin in Postorius terms) can delete a user with one button and that user is really gone. You can immediately register again with Affinity using the same email and you will have no problems re-registering. If the deleted user was subscribed to multiple lists and were not unsubscribed, then those lists will be waiting for him if/when he re-registers. So our decision to go with a new admin U.I. for Mailman 3 core, imo, has been a great decision. Mailman core is wonderful.
One improvement we made is a user can delete their Affinity account but still remain subscribed. They also have the choice to unsubscribe from all their lists at the time of account deletion as well.
6 years
Re: hello, Discussion on how to subscribe to the mailing list
by 朱超
At 2023-01-17 15:56:35, "Stephen J. Turnbull" <stephenjturnbull(a)gmail.com> wrote:
>Mark Sapiro writes:
>
> > On 1/16/23 18:55, 朱超 wrote:
> > > Hi, When I subscribe the email list in Subscription Policy is
> > > confirm, Some problems happen in here:
> > > 1.Some mail mua reject send the confirm the message, because the
> > > length of recipient is too long. for exmaple:
> > > requirements-confirm+9605556e0b35a5da280c1de0d34a3e6f770f8ea5@domain,
> > > and the mail mua reject to modify about this.
> >
> > The default English template says in part:
> >
> > Before you can start using GNU Mailman at this site, you must first
> > confirm that this is your email address. You can do this by replying to
> > this message.
> >
> > Or you should include the following line -- and only the following
> > line -- in a message to $request_email:
> >
> > confirm $token
> >
> > I.e. It gives an alternative method if `reply` doesn't work. You can
> > provide a custom version of this template with different wording if you
> > think you can improve it.
>
>The problem is the reply address, though. Changing the template to
>suggest only the "confirm $token" in body method doesn't help people
>who hit R expecting that should work, especially since many "user
>fiendly" (misspelling intentional) MUAs don't display the address.
>Avoiding that requires code changes, I guess?
Yes, You got it. It is too cumbersome to ask the user to write a reply email for email confirmation.
>
> > > 2.It is inconvenient for users to use. Many people will
> > > mistakenly think that after clicking the subscribe button, it
> > > will be successful, and they will not process the email.
>
> > step, you can set Subscription Policy to Open, but then anyone can
> > maliciously subscribe third parties to the list.
>
>*Please* do not do this if your server is exposed to the Internet.
>There are bots that search for such servers, and sell lists of them to
>people who want to DOS mailboxes. You may find yourself banned across
>the Internet.
>
Yes.For service security, we will not set the Subscription Policy to open
>The only real alternative to confirmation is approval by moderators.
>I believe Mailman 3 offers that alternative as Mailman 2 did, can't
>check at the moment.
>
> > > Regarding the discussion on the subscription method of the
> > > mailing list, should we consider optimizing the subscription
> > > method of the mailing list, for example:
> > > 1. use the method of sending a verification code to subscribe by
> > > email,When you receive the verification code sent by the
> > > mailing list and fill it in again, you can subscribe
> > > successfully。
> >
> > How is this different from the present method.
>
>Just wording. I think they are thinking of the "invite" option that
>was provided in Mailman 2 mass subscribe (again, I think Mailman 3
>retains it but I never ever used it so I don't recall for sure). But
>it doesn't make sense for a user-initiated interaction.
>
> > If you want, you can make
> > a custom template and include something like:
> >
> > Alternatively, you can confirm by going to the URL
> >
> > https://www.example.com/mailman3/lists/$list_id/confirm/?token=$token
>
>If I understand the OP's PoV correctly, I think I would change the
>list information page to say "Send a personal invitation to join the
>list to [email address here]. If you aren't a subscriber, you can
>invite yourself." And change the word "confirm" in the confirmation
>template to "subscribe".
Why do you need to modify the mailman-core service, I suggest we should modify the code of the postorius, We can refer to postorius to reset the user password process,
Detail, through the postorius to send email to user, and user click the url in email to confirm subscribe the email,Currently I have achieved it this way。
> > We don't include that in the default template because Mailman core
> > doesn't know if you even have a web UI or how to access it if you
> > do.
>
>We should fix that, at least if the web interface is Postorius
>(wishlist, assigned to me):
>https://gitlab.com/mailman/mailman/-/issues/1055
>
>@mark
>https://gitlab.com/mailman/mailman/-/issues/901
>Maybe we can close this? I'm not sure why it was left open since
>there's no action proposed for Mailman improvement.
>
> > > 2. use the email to send a connection to confirm the
> > > subscription,People click the link to be redirected to a
> > > confirmation page to subscribe to the email。
> >
> > See above.
>
>Indeed, AFAICS almost everything the OP is suggesting amounts to an
>identical procedure as far as the Mailman server is concerned, it's
>just described to the subscriber differently. The one exception is
>the suggestion to eliminate the confirmation step, and while that is
>supported, it's quite likely to cause problems for third parties and
>eventually for the Mailman site unless you have an alternative ground
>source of truth such as an employee database.
>
>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/
>Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message…
>
>This message sent to tom_toworld(a)163.com
3 years, 5 months
[MM3-users]New Mailman 3 users list
by Mark Sapiro
I'm happy to announce a new list for Mailman 3 users and others
interested in Mailman 3. This list is running on a new Mailman 3
installation at lists.mailman3.org.
The list's posting address is <mailman-users(a)mailman3.org>.
The list's info page is
<https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/>
and its archives are at
<https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/>.
The top level Postorius page is <https://lists.mailman3.org/mailman3/>
and the HyperKitty archiver is at <https://lists.mailman3.org/archives/>.
You can subscribe by email by sending a blank message to
<mailman-users-join(a)mailman3.org> and responding to the resulting
confirmation request. You can also subscribe by going to the info page
at
<https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/>,
logging in and subscribing.
Log in offers three options. There are Google and Facebook OAuth2 login
links on the log in page to log in with a Google or Facebook account,
and there is a 'Login by email' link to login via Persona with any
address you register and confirm with Persona.
This is a new installation of Mailman 3 so there are still kinks to work
out, and any issues can be discussed on the list or reported to the
trackers at <https://gitlab.com/mailman/postorius/issues>,
<https://gitlab.com/mailman/hyperkitty/issues> or
<https://gitlab.com/mailman/mailman/issues> as appropriate.
Enjoy!
--
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
10 years, 2 months
Re: Avoiding non-members to be saved.
by Mark Sapiro
On 8/7/21 4:55 AM, Stephen J. Turnbull wrote:
> 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).
Moderation in MM 3 works as follows:
Is poster address a member. If so apply the member's moderation action, else
Does poster address appear or match a pattern in the legacy
(accept|hold|reject|discard)_these_nonmembers (first match in that
order). If so, apply the appropriate action, else
If the poster address is not a non-member, add it as a nonmember and
apply the default nonmember moderation.
> > 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 import21 process imports *_these_nonmembers by adding any regexps to
the corresponding MM 3 *_these_nonmembers and adding any addresses as
nonmembers with the appropriate moderation action.
> > 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.
This is the way MM 3 works. The only reason *_these_nonmembers exists in
MM 3 is to support the legacy regexps from MM 2.1. For non-regexp
addresses the address is a nonmember with the appropriate moderation
action.
I actually find this convenient. When a nonmember posts spam to a list
and that spam is held, I discard the spam in Postorius and at the same
time set the nonmember's moderation action to discard so I never see any
more from that address. Also, when someone who I recognize as a list
member posts from an alternate nonmember address, I can accept that post
and set the nonmember address moderation action to default processing.
> 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.
As I note above, nonmembers and members alike have a moderation action
which can be any of Hold, Reject (with notice), Discard (no notice),
Accept (without any further checks), Default Processing (continue with
additioal checks) or the list's default action for (non)members.
--
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
Re: error changed after restart
by Guillermo Hernandez (Oldno7)
On 7/2/21 19:04, Abhilash Raj wrote:
>
> On Sun, Feb 7, 2021, at 1:07 AM, Guillermo Hernandez (Oldno7) via Mailman-users wrote:
>> On 6/2/21 21:19, Abhilash Raj wrote:
>>>
>>> On Sat, Feb 6, 2021 at 19:44, Guillermo Hernandez (Oldno7) via
>>> Mailman-users <mailman-users(a)mailman3.org> wrote:
>>>> On 6/2/21 18:08, Abhilash Raj wrote:
>>>>
>>>> On Sat, Feb 6, 2021, at 3:04 AM, Guillermo Hernandez (Oldno7) via
>>>> Mailman-users wrote:
>>>>
>>>> I restarted de server and the error changed. Now the log
>>>> shows "KeyError: 'subscription_mode'":
>>>>
>>>> Did you also restart Mailman Core after the upgrade?
>>>>
>>>> Yes, indeed: I stopped mailman core and all the processes related.
>>>> Did the upgrades. Started all again. Find the errors in the web user
>>>> interface. Stopped all again. Looked for errors in the log. Restarted
>>>> the complete server. Found the second error that this second mail is
>>>> about to. It happens when, in the main page that shows all the lists
>>>> you click to see one of them. It seems to me that it has been
>>>> database structure changes in django that the upgrade is not aware...
>>>> but it's a very long shot from my side.
>>> `subscription_mode` was added in Mailman Core 3.3.2 and it is actually
>>> a derived atrribute and not stored in Database. Mailman's API should be
>>> returning this attribute for each Member, but for some reason it seems
>>> to me like it isn't doing that even though do have Mailman 3.3.3 running
>>> like you said.
>>> If you have Curl installed, can you send me the output of:
>>> $ curl -u <user>:<pass> http://localhost:8001/3.1/members?count=5&page=1
>> This is the output you asked for (it's the same you can see when you try
>> to interact with one list):
>>
>> /usr/local/mailman3 # curl -u XXXXXX:XXXXXX
>> http://localhost:8001/3.1/members?count=5&page=1
>> /usr/local/mailman3 # <html>
>> <head>
>> <title>Internal Server Error</title>
>> </head>
>> <body>
>> <h1><p>Internal Server Error</p></h1>
>>
>> </body>
>> </html>
>>
>> No log entry has been produced...
> This is weird, if you have working Core, then there should be *some* json returned
> from the above command. Do you have the Gunicorn running?
I have the uwsgi approach running...
> What is the
> output of `ps -ef | grep mailman`?
none
but if I do an ps ax | grep mailman it shows
/usr/local/mailman3 # ps ax | grep mailman
26803 - IsJ 0:00.87 /usr/local/bin/python3.7 /usr/local/bin/master
--force -C /usr/local/mailman3/var/et
26834 - SJ 0:07.57 /usr/local/bin/python3.7 /usr/local/bin/runner -C
/usr/local/mailman3/var/etc/mailma
26835 - IJ 0:05.84 /usr/local/bin/python3.7 /usr/local/bin/runner -C
/usr/local/mailman3/var/etc/mailma
26836 - SJ 0:07.16 /usr/local/bin/python3.7 /usr/local/bin/runner -C
/usr/local/mailman3/var/etc/mailma
26837 - SJ 0:08.74 /usr/local/bin/python3.7 /usr/local/bin/runner -C
/usr/local/mailman3/var/etc/mailma
26838 - SJ 0:03.16 /usr/local/bin/python3.7 /usr/local/bin/runner -C
/usr/local/mailman3/var/etc/mailma
26839 - SJ 0:07.07 /usr/local/bin/python3.7 /usr/local/bin/runner -C
/usr/local/mailman3/var/etc/mailma
26840 - SJ 0:08.12 /usr/local/bin/python3.7 /usr/local/bin/runner -C
/usr/local/mailman3/var/etc/mailma
26841 - SJ 0:09.07 /usr/local/bin/python3.7 /usr/local/bin/runner -C
/usr/local/mailman3/var/etc/mailma
26842 - SJ 0:07.45 /usr/local/bin/python3.7 /usr/local/bin/runner -C
/usr/local/mailman3/var/etc/mailma
26843 - IJ 0:00.95 /usr/local/bin/python3.7 /usr/local/bin/runner -C
/usr/local/mailman3/var/etc/mailma
26844 - SJ 0:07.27 /usr/local/bin/python3.7 /usr/local/bin/runner -C
/usr/local/mailman3/var/etc/mailma
26845 - SJ 0:07.69 /usr/local/bin/python3.7 /usr/local/bin/runner -C
/usr/local/mailman3/var/etc/mailma
26859 - IJ 0:01.01 /usr/local/bin/python3.7 /usr/local/bin/runner -C
/usr/local/mailman3/var/etc/mailma
26860 - IJ 0:05.75 /usr/local/bin/python3.7 /usr/local/bin/runner -C
/usr/local/mailman3/var/etc/mailma
50153 - IsJ 0:00.16 /usr/local/bin/uwsgi --ini
/usr/local/mailman3/uwsgi.ini
50481 2 S+J 0:00.00 grep mailman
26808 1 SJ 0:02.09 /usr/local/bin/uwsgi --ini
/usr/local/mailman3/uwsgi.ini
26832 1 IJ 0:00.00 /usr/local/bin/uwsgi --ini
/usr/local/mailman3/uwsgi.ini
> Are you able to run `mailman members` command to list the members of a list?
Yes. All the commands are working as expected.
> Also, how did you actually install Mailman?
Using pip. Here is a detailled post of how I did put all together:
https://forums.FreeBSD.org/threads/mailman-3.61050/post-488128
Thanks for your support
>
> Abhilash.
>
>> TIA.
>>
>>
>>
>>
>>> It should ideally return an output that looks something like shown
>>> here[1]. You
>>> can put the username/password of Core's API server in the above command.
>>> [1]:
>>> https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/…
>>>
>>> Abhilash
>>>> I'm using sqlite as django database and mysql for mailman.
>>>>
>>>> ERROR 2021-02-06 11:47:49,015 26798 django.request Internal
>>>> Server Error:
>>>> /mailman3/mailman3/lists/name_and_domain.of.the.list
>>>> Traceback (most recent call last): File
>>>> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py",
>>>> line 119, in __getattr__ return self._get(name) File
>>>> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py",
>>>> line 86, in _get raise KeyError(key) KeyError:
>>>> 'subscription_mode' During handling of the above exception,
>>>> another exception occurred: Traceback (most recent call
>>>> last): File
>>>> "/usr/local/lib/python3.7/site-packages/django/core/handlers/exception.py",
>>>> line 34, in inner response = get_response(request) File
>>>> "/usr/local/lib/python3.7/site-packages/django/core/handlers/base.py",
>>>> line 115, in _get_response response =
>>>> self.process_exception_by_middleware(e, request) File
>>>> "/usr/local/lib/python3.7/site-packages/django/core/handlers/base.py",
>>>> line 113, in _get_response response =
>>>> wrapped_callback(request, *callback_args, **callback_kwargs)
>>>> File
>>>> "/usr/local/lib/python3.7/site-packages/django/views/generic/base.py",
>>>> line 71, in view return self.dispatch(request, *args,
>>>> **kwargs) File
>>>> "/usr/local/lib/python3.7/site-packages/postorius/views/generic.py",
>>>> line 74, in dispatch return super(MailingListView,
>>>> self).dispatch(request, *args, **kwargs) File
>>>> "/usr/local/lib/python3.7/site-packages/django/views/generic/base.py",
>>>> line 97, in dispatch return handler(request, *args,
>>>> **kwargs) File
>>>> "/usr/local/lib/python3.7/site-packages/postorius/views/list.py",
>>>> line 295, in get member.subscription_mode == File
>>>> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py",
>>>> line 124, in __getattr__ self.__class__.__name__, name))
>>>> AttributeError: 'Member' object has no attribute
>>>> 'subscription_mode' *********************** some info about
>>>> the installed versions via pip list: pip list | grep django
>>>> django-allauth 0.44.0
>>>> django-appconf 1.0.4
>>>> django-compressor 2.4
>>>> django-extensions 3.1.0
>>>> django-gravatar2 1.4.4
>>>> django-haystack 3.0
>>>> django-mailman3 1.3.5
>>>> django-picklefield 3.0.1
>>>> django-q 1.3.4
>>>> djangorestframework 3.12.2 pip list | grep mailman
>>>> django-mailman3 1.3.5
>>>> mailman 3.3.3
>>>> mailman-hyperkitty 1.1.0
>>>> mailmanclient 3.3.2 pip list | grep postorius
>>>> postorius 1.3.4 On 6/2/21 11:12,
>>>> Guillermo Hernandez (Oldno7) via Mailman-users wrote:
>>>>
>>>> I've just upgrade mailman 3 installation following Mr.
>>>> Sapiro advice: did a pip install --upgrade
>>>> django-mailman3 hyperkitty mailman mailmanclient
>>>> mailman-hyperkitty postorius I did a "python3 manage.py
>>>> migrate" after, too. And all seemed to run well. All the
>>>> lists showed in postorius via web, but when I try to
>>>> accesss into one of them the browser shows an error. In
>>>> the log you can see: *-*-*-*-*-*-* Traceback (most recent
>>>> call last): File
>>>> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py",
>>>> line 119, in __getattr__ return self._get(name)
>>>> File
>>>> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py",
>>>> line 86, in _get raise KeyError(key) KeyError:
>>>> 'get_requests_count' .. (And after all the traceback
>>>> lines) AttributeError: 'MailingList' object has no
>>>> attribute 'get_requests_count' *-*-*-*-*-*-*-* The lists
>>>> seem to be distributing messeages well.. but I cannot
>>>> acces via web administration (django/postorius) Can
>>>> anyone point me in the right direction to solve this,
>>>> please? _______________________________________________
>>>> Mailman-users mailing list -- mailman-users(a)mailman3.org
>>>> <mailto:mailman-users@mailman3.org> To unsubscribe send
>>>> an email to mailman-users-leave(a)mailman3.org
>>>> <mailto:mailman-users-leave@mailman3.org>
>>>> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
>>>> <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3org/>
>>>>
>>>>
>>>> _______________________________________________ Mailman-users
>>>> mailing list -- mailman-users(a)mailman3.org
>>>> <mailto:mailman-users@mailman3.org> To unsubscribe send an
>>>> email to mailman-users-leave(a)mailman3.org
>>>> <mailto:mailman-users-leave@mailman3.org>
>>>> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
>>>> <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3org/>
>>>>
>>>>
>>>> _______________________________________________ Mailman-users mailing
>>>> list -- mailman-users(a)mailman3.org
>>>> <mailto:mailman-users@mailman3.org> To unsubscribe send an email to
>>>> mailman-users-leave(a)mailman3.org
>>>> <mailto:mailman-users-leave@mailman3.org>
>>>> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
>>>> <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3org/>
>>
>> _______________________________________________
>> 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/
>>
5 years, 4 months