Search results for "Postorius" - Mailman-users

Re: MM3 not starting afte an upgrade -addendum

by Gelpi Andrea

the last problem was due to the VHOST parameter. I had to remove it to hace postorius run. Is anything changed since two month aggo when I applied some pathces? Thanks and regards -- AG Il 24/07/20 10:13, Gelpi Andrea ha scritto: > > > Il 23/07/20 23:05, Mark Sapiro ha scritto: >> On 7/23/20 4:35 AM, Gelpi Andrea wrote: >>> Hi, >>> to day in a Debian system I upgraded some packages. >>> >>> After the MM3 doesn't start anymore. > > . . . > >>> Jul 23 13:29:39 posta mailman3[2608]: os.kill(pid, 0) >>> Jul 23 13:29:39 posta mailman3[2608]: PermissionError: [Errno 1] >>> Operation not permitted >> >> >> I think you have a stale lock issue and the master is trying to >> determine if the process that set it still exists. >> >> Remove Mailman's var/locks/master.lck* >> > > Thanks Mark, now MM3 star but postorius is not working. > > The web pagge return: An error occurred while processing your request. > > I receive an email with: > ... > Exception Type: KeyError at /postorius/lists/ > Exception Value: 'file' > Request information: > USER: AnonymousUser > > GET: No GET data > > POST: No POST data > > FILES: No FILES data > > COOKIES: No cookie data > > Is that related to Django id setting or there is a passphrase mismach > some where? > > How can I check? > > > -- Gelpi ing. Andrea ************************************************** I documenti vitali dimostreranno la loro vitalitˆ spostandosi spontaneamente da dove li avevate lasciati a dove non riuscirete a trovarli. **************************************************

5 years, 10 months

Re: Approve an email

by Eggert Ehmke

Not sure about Fedora, but there seem to be some issues with distribution specific packages. Many users have got good results with the virtualenv installation described here: https://docs.mailman3.org/en/latest/install/virtualenv.html this description is Debian/Ubuntu related, but should work for Fedora too. In the end you get a system that is much more up to date and you get support here in the mm3-users list. My mailman3 runs in venv on Debian. Hope that helps. Am Montag, 26. Dezember 2022, 21:08:46 CET schrieb Lars Bjørndal: > Hi, list! > > I'm on Fedora 36 with the packages mailman3-3.3.4-6.fc36.noarch and > postorius-1.3.6-2.fc36.noarch installed. with the command > > sudo -u mailman mailman3 create <listname> > > I was able to create a list. > > I'm not able to find out how to setup and configure the postorius > package. There's no mailman-web command. > > Hyperkitty will not installed du to a dependency conflict, but I dont > need archiving for the list. > > Here comes my quesitons: > > - What's the easiest way to approve an email sent to the list? > > - How can I configure the list to accept messages also from non members? > > - How can I setup postorius to work on Fedora? I have django-admin, but > I'm not sure where to go. > > Thanks in advance, Lars > _______________________________________________ > 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 > /ZDUDQA57QRLF7QD4KPFIZBC6ZIF2FAVP/ > > This message sent to eggert(a)eehmke.de

3 years, 5 months

Re: Upgrading packages

by Mark Sapiro

On 10/13/22 03:49, Eggert Ehmke wrote: > > pip install --upgrade git+https://gitlab.com/mailman/hyperkitty@master > > I noticed that mistune-2.0.0rc1 was upgraded to mistune-2.0.4. > > All packages were upgraded fine. I applied the patch to > venv/lib/python3.9/site-packages/hyperkitty/lib/renderer.py It shouldn't have been necessary to apply any patch. The head of the GitLab hyperkitty master branch is already compatible with mistune 2.0.4 > to change the mistune import line. When I run now > mailman-web migrate > I get: > *CommandError: Conflicting migrations detected; multiple leaf nodes in the migration > graph: (0017_auto_20220628_1132, 0018_alter_emailtemplate_language in postorius).* > *To fix them run 'python manage.py makemigrations --merge'* > > However, when I run the suggested command as: > $ python ./venv/lib/python3.9/site-packages/mailman_web/manage.py makemigrations -- > merge > No conflicts detected to merge. There's something strange here. If you look at the migrations at the head of the gitlab branch at https://gitlab.com/mailman/postorius/-/tree/master/src/postorius/migrations, you'll see that migration 17 is named 0017_alter_emailtemplate_language.py, not 0017_auto_20220628_1132. I suggest comparing the content of your postorius/migrations/ directory with the GitLab head and resolving any differences. > Can I just ignore this behavior? At the moment, I don't dare to carry out these steps on my > production system. Would be nice to shed some light on this. I'm guessing at some point you installed something which required you to manually make this migration and that produced this conflict. Do you have both 0017_alter_emailtemplate_language.py and 0017_auto_20220628_1132 in your postorius/migrations/ directory? If so, probably just removing 0017_auto_20220628_1132 will fix this? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 8 months

Postorius extremely slow on some of the mailinglists

by Stephen J. Turnbull

Eric Broens via Mailman-users writes: > Mainly "GET /3.1/lists/<mailing_list>@<domain>/requests HTTP/1.1" > takes a long time. The only thing I can think of is that something weird is happening with requests (held messages) on those lists. The runner is waiting on the database server, and eventually timing out, I think. I believe you will find the corresponding messages under $var_dir/messages (var_dir is usually set in mailman.cfg, if not I believe it defaults to /usr/local/mailman3/var). Unfortunately I don't know how to link those entries to the messages in that directory tree. You can "grep -ri '^list-id:.*<your.list.id>$' messages" for held posts via the problem list if you have list ID on (that's the default for recent Mailman) and if that's not going to work you could use "grep -rF 'your(a)list.id' messages" for a less precise search. It's not a good idea to delete them from the file system (I think Mailman is robust to that but I'm not sure). However, if one looks like spam you could try working at a slightly lower level than Postorius by using mailmanclient directly. See https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/…. If that doesn't work (for example listing the requests for a list times out the same way in mailmanclient), you could try directly querying the database server to see what's going on. The check for an unusual number of requests that might be an attack is to connect to the database server with its command line utility. I'm not on CLI terms with MySQL but for PostgreSQL it's $ su - mailman $ psql mailman=> select mailing_list_id, count(mailing_list_id) from _request group by mailing_list_id; mailman=> select id, list_id from mailinglist; and you can append " where id = $mailing_list_id" to the second to the second one to find the List-Id for a specific mailing list. That's just plain SQL including the count function as far as I know, so should work in any backend that Mailman can use. If you're handy with SQL you could do all that with a join but I'm not. ;-) > Any idea why this happens and how it can be solved? Aside from a really astonishingly large number of pending requests (as tested above with count()), perhaps there's something in the requests themselves. If there aren't literally thousands of requests for a problem list you can list them with mailman=> select key, mailing_list_id from _request; Look for odd characters in the key field. One oddity that I'mm pretty sure is not a problem is something of the form "\r\n <message-id>" (my instance lists those fine). There's a bug in Exchange (IIRC) which sometimes includes invalid characters (specifically "[" and "]") in message IDs which I believe we worked around only quite recently, although I don't recall if it affected APIs for requests. Control characters and non-ASCII might also cause trouble, If your database server is MySQL, is it set up to handle the full range of Unicode (I think the option is utf8mbcs)? Lacking that is known to cause problems when headers and maybe body contain emoticons or other extended Unicode characters. Again I don't recall if crashing the REST runner is a known symptom. If none of the above works, there's always the "hit it with a hammmer" approach. Have you tried restarting both Postorius and Mailman? How about restarting the database server? How about all three? As a last resort, it's probably possible to delete the requests from the filesystem and the database by hand. But I don't want to think about that unless absolutely necessary. Steve

1 year, 4 months

Re: Postorius endless loading on Sign in / Register then "Internal Server Error"

by Mark Sapiro

On 6/10/20 10:55 AM, Jacob Bargery wrote: > So I couldn't find a schema.cfg file but but when checking mailman-web.py and mailman.cfg they both have the same password. Albeit not the restpass but a much longer random password. I was able to connect using both telnet options. > > For reference the instructions I followed for installing this (up to the SSL cert) were here: https://docs.google.com/document/d/1xIcSsoNFp2nHi7r4eQys00s9a0k2sHhu1V5Plan… See <https://wiki.list.org/x/12812344 The next step is to try this in `django-admin shell` from mailmanclient.restbase.connection import Connection from django.conf import settings url = settings.MAILMAN_REST_API_URL user = settings.MAILMAN_REST_API_USER pwd = settings.MAILMAN_REST_API_PASS conn = Connection(url, user, pwd) conn.call('3.1/lists') That should return `<Response [200]>` and a bunch of json. What happens in your case? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years

Re: clean_users.py

by Mark Sapiro

On 12/8/25 07:37, Christian Stalberg via Mailman-users wrote: > I just ran the clean_users.py script and it removed user email addresses > from Django. I can still find these addresses however using Postorius which > show > > Subscriptions > User has no subscriptions. > Ownerships > User has no ownerships. > > Why are they still listed then? How can I purge my system of all instances > of unsubscribed registrants please? Postorius is showing you Mailman users. If you ran the clean_users.py script with default settings, it only removed Django users. To delete Mailman users with no subscriptions or ownerships, you have to set DELETE_MAILMAN_USER = True As it says, # Set True to delete Mailman users that have no memberships with any role. # Set False to not delete Mailman users. You can change the setting for DELETE_MAILMAN_USER to True and run it again and it will delete those Mailman users. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 months, 2 weeks

Re: Default values for lists in Mailman 3

by Markus Grandpré

Thank you very much for your answer. Best regards, Markus Am 19.09.24 um 22:03 schrieb Mark Sapiro: > On 9/19/24 05:46, Markus Grandpré wrote: >> Dear list, >> >> I would like to activate the invitation setting for all lists as >> default. In Mailman 2.1 I have done this in the file </etc/mailman/ >> mm_cfg.py>: >> >> >> DEFAULT_SUBSCRIBE_OR_INVITE = Yes >> >> >> How can I do this in Mailman 3? > > There is a draft merge request at https://gitlab.com/mailman/ > postorius/-/merge_requests/930 which implements a framework for setting > Postorius defaults and creates a setting to set the default for pre- > verified on the mass subscription page. Once merged, this can easily be > extended to provide a default for Invitation. > > In the mean time, you can only do this by patching src/postorius/forms/ > list_forms.py like > ``` > --- a/src/postorius/forms/list_forms.py > +++ b/src/postorius/forms/list_forms.py > @@ -1283,7 +1283,7 @@ class ListMassSubscription(forms.Form): > > invitation = forms.BooleanField( > label=_('Invitation'), > - initial=False, > + initial=True, > required=False, > help_text=_( > 'If checked, the other checkboxes are ignored and the > users will ' > ``` >> Can I also transfer other default values like: >> >> ... >> DEFAULT_SERVER_LANGUAGE = 'en' >> DEFAULT_SEND_REMINDERS = 1 >> DEFAULT_SUBSCRIBE_OR_INVITE = Yes >> DEFAULT_PRIVATE_ROSTER = 2 >> DEFAULT_ARCHIVE = Off >> DEFAULT_ARCHIVE_PRIVATE = 1 >> ... >> >> from the very same configuration file to Mailman 3? Is there a >> documentation of the default values for lists in Mailman 3? > > This is done by creating a list style with the desired defaults. See > https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/styles/ > docs/styles.html for documentation of styles and see https://gitlab.com/ > mailman/example-mailman-plugin for an example of creating a plugin in > Mailman core to make a persistent style. > > There is no specific doc for the list settings. You need to look at > https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/styles/ > base.py for the various settings and https://gitlab.com/mailman/ > mailman/-/blob/master/src/mailman/styles/default.py to see which default > classes are applied for various styles. > -- Markus Ludwig Grandpré Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung und Lehre, B803, Tel: ++49 7531 88 4342

1 year, 9 months

Re: Social signup?

by Mark Sapiro

On 3/15/23 05:08, Duane Raymond wrote: > > I'll jump over to the developers list when I start this (I'm about to > travel for a week to run an annual event in Oxford - so the far removed > from programming)...but which chatGPT suggested so far was > > 1. Extending postorius/signups.html with a loop to get the configured > social login providers PLUS adding a csrf_token field to the form > 2. Modifying postorius/views.py (which doesn't seem to exist but there > is a postorius/views folder) - so perhaps this is views/urls.py This is not what you want to do for this. The changes need to be in django-mailman3, not postorius. I have attached a patch which might work for you. I think it is good, but some of the wording is stuff that may not be appropriate. See what you think. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 3 months

Re: Core, Hyperkitty and Postorius releases

by Odhiambo Washington

On Fri, May 14, 2021 at 7:04 PM Mark Sapiro <mark(a)msapiro.net> wrote: > On 5/14/21 5:02 AM, Odhiambo Washington wrote: > > On Fri, May 14, 2021 at 2:52 PM Jeff Steele <jeff(a)steele.com> wrote: > > > >> > >> > >> On May 14, 2021, at 7:49 AM, Odhiambo Washington <odhiambo(a)gmail.com> > >> wrote: > >> > >> /bin/sh: sass: Permission denied* > >> > >> > >> > >> Did you check the permissions on your sass binary? > >> > > > > My mailman installed in /opt/mailman/mm > > > > find /opt/mailman/ -type f -name sass > > > > yielded nothing! > > > > Try `which sass` > root@gw:/usr/home/wash # su mailman3 (venv) [mailman3@gw /usr/home/wash]$ which sass (venv) [mailman3@gw /usr/home/wash]$ There is no sass. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v "^$|^.*#" :-)

5 years, 1 month

Re: Splitting hosts: mta&core vs postorius

by samuel.d.darwin＠gmail.com

The current implementation of [webservice] hostname is confusing and difficult to work with. It's not uncommon on a Linux server to have the following in the /etc/hosts file so that the machine resolves it's own name. This is not connected to mailman at all, it could just be general practice. /etc/hosts: 127.0.1.1 mailman.example.com mailman However, if you have that in place, and then this mailman config file. /etc/mailman/mailman.cfg [webservice] hostname: mailman.example.com port: 8001 mailman-core will only listen on localhost. Maybe you don't want that. It shouldn't be necessary to play games with /etc/hosts because the problem could be resolved this way: [webservice] hostname: mailman.example.com bind_to: 0.0.0.0 port: 8001 or [webservice] hostname: mailman.example.com listen: 0.0.0.0 port: 8001 Then any outgoing api messages or other communications would reference the so-called hostname, which remote clients would use, "mailman.example.com" . If the "listen" or "bind_to" field is absent, fall-back to the current behavior.

2 years, 5 months

Mailman-users search results for query "Postorius"