Search results for "Postorius" - Mailman-users

Re: Held messages: Long time waiating for response of the Mailman API

by Stephan Krinetzki

Mark Sapiro wrote: > On 1/24/22 15:06, Mark Sapiro wrote: > > On 1/18/22 06:24, Stephan Krinetzki wrote: > > Hello, > > We are using Mailman 3.3.5 with Hyperkitty 1.3.5. Mailman 3 is > > installed in a venv and deployed using Apache and uwsgi. This works > > quite well so far, only withheld messages cause us a problem: If we > > try to approve them via Postorius, the message is delivered to the > > list immediately, but the success message in Postorius takes a long > > time - on average the process hangs for three minutes until the > > message is no longer displayed. We have already adjusted the timeout > > in gunicorn.cfg, but this does not improve the situation. Are there > > any tips on how we can speed up the REST API? Or is it even a > > configuration error? > > There are two steps in handling the POST for a held message. The first > > step is accepting, rejecting or discarding the message. This is > > happening immediately. > > The second step is handling the poster's moderation action based on the > > choice from the Set member moderation dropdown in the view of the held > > message. This is processed by the code at > > https://gitlab.com/mailman/postorius/-/blob/master/src/postorius/views/list…. > > If no selection has been made, the default value POSTed for > > moderation_choice is no-action and that code is skipped. If it is one > > of the choices Hold for moderation, Reject (with notification), > > Discard (no notification), Accept immediately (bypass other rules) > > or Default processing that is processed. So presumably a selection has > > been made and processing is stuck on getting the member or setting the > > member's moderation action. > > Possibly the logs of your database manager will have information. > > Some additional info. > By gunicorn.cfg, do you mean the file at mailman/config/gunicorn.cfg? If > you are using gunicorn as a wsgi server, that is separate from the > gunicorn serving the REST API and its config doesn't affect the REST > API. The relevant config is mailman/config/gunicorn.cfg?. > Also, I doubt the issue is with the REST API per se, but rather it is in > Mailman core's processing of the particular endpoint and if that is > slow, it is most likely some kind of database issue. Hi Mark, yes, we are using a local copy of the gunicorn.cfg. It is in the home directory of our mailman3 instance (like the mailman.cfg, same directory). We will now look into the postgresql database - maybe there is an index missing or something like that. Thank you for help.

3 years, 4 months

Re: Listing/Exporting member list error: Mailman REST API not available. Please start Mailman core.

by Daniel Armengod

Can confirm the problem is reproducible on mailman 3.3.0 installed via PIP. Postorius hangs on exporting CSV subscribers [1] (~6k in this case), with error "Mailman REST API not available. Please start Mailman core" (which is otherwise running fine). mailman3.log also shows WORKER TIMEOUT log entry, exactly the same as OP's message. > You can add a new |gunicorn.cfg| next to your |mailman.cfg| and add > the additional options. For further reference if anyone reads this thread, see [2]. I had to look that up to figure out where the file name "gunicorn.cfg" came from. It's not immediately obvious to the reader why a file named "guincorn.cfg" should be specially interpreted by mailman3. The suggested fix - increasing timeout of worker process - did work perfectly for me. Thanks :) Regards, Daniel [1] http://www.<redacted>.org/postorius/lists/<redacted>/csv_view/ [2] https://mailman.readthedocs.io/en/latest/src/mailman/runners/docs/rest.html…

5 years, 4 months

Re: How to store additional information about lists?

by Stephen J. Turnbull

Andreas Barth writes: > Not sure if this is the right approach, or if it wouldn't be more > appropriate to "just" replace the dependency on allauth in postorius, > and do all the magic in the frontend only (because that's where people > actually subscribe). If it's purely a matter of managing subscriptions by individual users, that's the path of least resistance, I think. I would not be surprised if there are things you don't actually need, but you'd need to implement so that Postorius doesn't blow up if some IMember feature you haven't implemented gets accessed. If in the future you might have an external personnel database with other stuff in it, and you want Mailman automatically synced to that, then IMember now might make sense to avoid technical debt in the future. But I don't know enough about IMember or your use case at the moment to make a useful recommendation. Steve

4 years

Re: Upgrading other python packages than the mailman ones in a venv results in dependency conflicts

by Odhiambo Washington

On Mon, Dec 16, 2024 at 1:39 PM Ulf R. <ulf.rapphahn(a)offis.de> wrote: > 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 > Correct! > May be yes and I have to ignore the rest? ;-) > Yes. Let them pull their own versions of dependencies. -- 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]

6 months

Re: Template's encoding setup

by Mark Sapiro

On 9/15/19 3:33 AM, Ugnius S wrote: > > This noticed only on HTML text messages. If message comes in HTML the > header does not add extra <enter> new line, new paragraph > and footer as well. For example if message body has no additional, list's > decorated message looks next: > > TEST HEADER > _____________________Hello, > > text text text, pictures, text > > regards > Ugnius____________________ > TEST FOOTER > > I have tried to add more empty lines in "The footer for a regular > (non-digest) message.", but mailman removes these empty lines. > Work around is put dot "." and then several empty lines. The stripping of leading whitespace from templates created in Postorius is <https://gitlab.com/mailman/postorius/issues/301> to be fixed by <https://gitlab.com/mailman/postorius/merge_requests/434> > Mark, I have found Your post about HTML headers and footers: > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/… > YES, that works good, I have tested it, but only in cases if message comes > in HTML. If sender sends plain text message, > mailman adds footer with all HTML code: > > <BR>__________________<BR> > <B> LIST NAME </B> > > Could it be possible that decorate.py would recognise message and if it > has HTML text body, then just would add header/footer and if not (if > message body is plain text) , then would strip header/footer "html to plain > text" may removing html code from it? As it says in the post you reference: message and digest footers and headers are always added either to a MIME text/plain message body or as separate MIME text/plain parts. HTML tags will just be displayed as plain text and will not be rendered as HTML. Also see <https://wiki.list.org/x/4030707>. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 9 months

Postorius Suggestion: Give owner a view of all users of all owned lists

by Stephen J. Turnbull

Andreas Vetter writes: > it would be real great if owners that own several lists, but are > not superusers, can see all users of all *their* lists and manage > them. A down-"selected" version of the superusers view. > Would that be possible? Possible, yes. I don't know how to do it well enough to add to our distribution. Note that owners can't actually manage users -- that really does need to be a superuser. Owners can manage subscriptions to the lists they own. So first we'd want to create a new "Subscriptions" item for the top menu; the "Users" item isn't appropriate. I'm not sure who that item should be visible to. Most likely only owners, because individuals already have ways to see all their subscriptions, and it's not obvious they would want the same presentation as your superowners. Then you'd iterate over the logged-in owner's lists and collect all of the subscriptions. I guess you'd want them to be organized by address rather than by list. By User is out, I think -- owners can't normally see Users, and I'm unhappy abou the privacy implications of being able to correlate nole(a)alset.com with head(a)dodgy.gov in general, although I realize it's not a problem in your setting. Without a more complete specification of what your users need, and the presentation they'd want to see, I personally am unwilling to go farther than those comments. Maybe one of the other devs feels differently. Also, "domain owner" is way under-implemented currently. For the hierarchical situation you outline, all the problems go away for domain owners. Of course then you'd need to split out lists by domain, but to me that's a small cost to preserve sanity in the structure. Steve

3 months, 1 week

Re: Moderate mails from owner

by Abhilash Raj

On Thu, Mar 21, 2019, at 8:47 AM, Malcolm Austen wrote: > On Wed, 20 Mar 2019 18:42:10 -0000, Mark Sapiro <mark(a)msapiro.net> wrote: > > > However, this is apparently not relevant because both the Member and > > Non-Member actions are Hold. Thus, the post should be held unless it has > > an Approved: header with the list's moderator_password attribute if > > there is one, or it matches a Header filter rule with an accept action. > > At the risk of getting this really wrong - I have only limited MM3 > knowledge - I will ask what is, I fancy, a closely related question ... > > My only experience of MM3 is with Ancestry's 'RootsWeb' installation. From > the emails I can see a header "X-Mailman-Version: 3.1.0" but I can't find > anything to identify Postorius which is the only interface I have to the > system. > > From symptoms seen and described by others, I have deduced that the > Postorius admin-per-user moderation options of "Default processing" and > "List default" mean that a user may be set (by default on the rootsweb > system!) to use the system default moderation settings rather than the > list default settings. "Default Processing" means the default pipeline defined in List > Settings > Alter Messages > 'Pipeline' ( in the bottom). This pipeline is system wide and is defined in source code, so it can't be customized by site administrator. > > Are my deductions correct? And if so, could this be the explanation of the > issue detailed in this thread? > > Apologies if I'm barking up entirely the wrong tree, Malcolm. > > -- > Malcolm Austen <malcolm.austen(a)weald.org.uk> > _______________________________________________ > Mailman-users mailing list -- mailman-users(a)mailman3.org > To unsubscribe send an email to mailman-users-leave(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > -- thanks, Abhilash Raj (maxking)

6 years, 2 months

Re: Chinese characters in list name shows question mark (?)

by Franklin Weng

Franklin Weng 於 2019/10/24 上午8:05 寫道: > Hi Mark, > > Thanks for your reply. > > Mark Sapiro 於 2019/10/24 上午6:10 寫道: >>> Is there any other setting I should look at? >> The list's preferred_language setting (Postorius -> Settings -> List >> Identity -> Preferred Language. The list welcome message is encoded in >> Mailman's character set for the list's preferred_language. If this is >> English (USA), the character set is us-ascii. If it is set to Chinese >> (Taiwan), the character set is utf-8, and it should work. > However in my settings -> List Identity page I didn't see Preferred > Language option. > > https://nextcloud.slat.org/index.php/s/45tGaE7ALgAFQFK > > What may be possible wrong that I couldn't see Preferred Language > settings in the web interface? I got it. It is implemented in postorius 1.2.5 but my Debian buster contains 1.2.4-1 for now. Franklin

5 years, 7 months

Re: Changelog and/or Release Notes

by Brian Carpenter

On 11/28/19 1:12 PM, Abhilash Raj wrote: > > On Thu, Nov 28, 2019, at 10:08 AM, Brian Carpenter wrote: >> Now that I am using Mailman 3.3, where can I find the release notes >> and/or changelog for core, postorius and hyperkitty under Mailman 3.3? > Each individual projects maintain their own change logs: > > https://hyperkitty.readthedocs.io/en/latest/news.html#id1 > https://postorius.readthedocs.io/en/latest/news.html#id1 > https://mailman.readthedocs.io/en/latest/src/mailman/docs/NEWS.html#tom-saw… > > >> Thanks! >> Brian >> _______________________________________________ >> 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 and for all of your hard work maintaining those docker containers! -- 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, 6 months

Re: Postorius fails to show list because of a large message being held

by Mark Sapiro

On 7/14/20 3:54 AM, Brian Carpenter wrote: > On 7/14/20 6:49 AM, Gilles Filippini wrote: >> Mailman Core logs: >> [2020-07-14 10:41:21 +0000] [36] [CRITICAL] WORKER TIMEOUT (pid:49) >> [2020-07-14 10:41:21 +0000] [49] [INFO] Worker exiting (pid: 49) >> [2020-07-14 10:41:22 +0000] [50] [INFO] Booting worker with pid: 50 > > I am pretty sure that timeout is related to gunicorn. If it is, then > increasing the worker out timeout setting for gunicorn should work. You > tend to get such errors when doing an export of a large membership > roster. This is the first time I have seen it related to a held message. It seems weird that a gunicorn worker would run for more that the default 30 seconds because of a 23MB message, but I think Brian is correct. > I have this in my setup: > > mailman.cfg: > > [webservice] > configuration: /opt/mailman/mm/gunicorn.cfg > > gunicorn.cfg: > > [gunicorn] > workers = 4 > timeout = 900 > > You will need to restart gunicorn after adjusting the timeout setting. It's confusing, but after adjusting that setting, you need to restart Mailman core, not gunicorn. If you are running a gunicorn service, that is what is providing WSGI support for Django (Postorius and/or HyperKitty). You may be using gunicorn for this or uWSGI or Apache mod_wsgi, but is any case, that is not the gunicorn we are considering here. Regardless of what you use to provide WSGI support for Django, Mailman core uses gunicorn to support the REST API, and that is the gunicorn affected by the settings in the gunicorn.cfg pointed to by [webservice] configuration: /opt/mailman/mm/gunicorn.cfg If, with the above configuration, you do `ps -fwwA|grep runner=rest` you will see something like: mailman 20582 20561 0 01:21 ? 00:00:16 /opt/mailman/mm/venv/bin/python /opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/deployment/mailman.cfg --runner=rest:0:1 mailman 20722 20582 0 01:21 ? 00:01:19 /opt/mailman/mm/venv/bin/python /opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/deployment/mailman.cfg --runner=rest:0:1 mailman 20725 20582 0 01:21 ? 00:01:18 /opt/mailman/mm/venv/bin/python /opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/deployment/mailman.cfg --runner=rest:0:1 mailman 20726 20582 0 01:21 ? 00:01:18 /opt/mailman/mm/venv/bin/python /opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/deployment/mailman.cfg --runner=rest:0:1 mailman 20727 20582 0 01:21 ? 00:01:50 /opt/mailman/mm/venv/bin/python /opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/deployment/mailman.cfg --runner=rest:0:1 The first of these, pid 20582, is Mailman's actual REST runner. The other 4 with parent pid 20582 are the 4 gunicorn worker processes forked from the REST runner. It's the REST runner or Mailman core that needs to be restarted to pick up that change. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 11 months

Mailman-users search results for query "Postorius"