Search results for "Postorius" - Mailman-users

Re: [EXT] - moving lists to another server

by Bryan Kartzman

Wow, thanks for the very thorough response, Steve. I should have started by saying that when we built the current production server, we cloned it off the test server and we were thinking now to move the data onto another clone of the old test server. So, yes we would have to apply all the changes we made since we cloned the current production server, but everything else as far as the OS is concerned should be comparable (webserver, MTA, Mailman core, Django, Hyperkitty, Postorius). That's why I was just asking about the "data" aspects of mailman/hyperkitty/postorius. What would I have to move to replicate all the lists on the current production server to a new clone of the original test server once we've applied any changes we made to production server since the clone. ________________________________ From: Stephen J. Turnbull <turnbull.stephen.fw(a)u.tsukuba.ac.jp> Sent: Tuesday, November 7, 2023 1:07 PM To: Bryan Kartzman <bryan.kartzman(a)yu.edu> Cc: mailman-users(a)mailman3.org <mailman-users(a)mailman3.org> Subject: [EXT] - [MM3-users] moving lists to another server **External Email** bryan.kartzman(a)yu.edu writes: > I have both my mailman lists and django config in postgres > databases. These are Mailman 3 lists? What Django config? Do you mean Postorius and HyperKitty? Do you intend to use Postorius and HyperKitty on the new server? > If I want to move my lists to another server that is running > mailman 3, aside from copying the databases to the other server, Do you mean the other server is already actively distributing Mailman list traffic, managing users and archives? Or is it fresh instance? > what other things (perhaps all files under /var/lib/mailman3?, etc) > would I need to bring over to the other server? That's going to vary depending on the way your existing server is set up. A Mailman 3 instance is a complex system of cooperating applications. Assuming you have not patched or added any Python code, typical configuration and customizations include 1. Your webserver (Apache, nginx are most common) needs configuration to handle WSGI applications and may need modules enabled or installed for the WSGI server. This is usually installed as an OS distro package, and the configurations will live in /etc/apache2 or similar for another webserver. Depending on other content served by the two hosts you may have to edit the configuration on the new host rather than copy it from the old one. 2. The WSGI server is typically a separate application, although there is an Apache module for this. Gunicorn is a Python application usually installed via pip. I like to keep its Django configuration, which I call gunicorn.conf.py, in /etc/mailman3. (Mailman core also uses gunicorn, but that is transparent to you, it should not need custom configuration.) uwsgi is a C or C++ application normally supplied as a distro package. Don't know where it keeps its config files but since it's a distro package my first guess is /etc/uwsgi. 3. Your MTA, usually Postfix or Exim4, maybe Sendmail or qmail needs to be configured to route mail to Mailman, and apply any milters, signatures, and perhaps anti-yahoo configurations such as ARC. 4. Your database server, usually PostgreSQL or MySQL. 5. Mailman core has a single configuration file mailman.cfg, which I keep in /etc/mailman3. It also has a crontab, which in Debian- derived systems typically lives in the file /etc/cron.d/mailman3. Note that this could be implmented as a systemd timer, but I don't know if any distros do that. 6. Django, Postorius, and HyperKitty together constitute the mailman-web subsystem. I strongly recommend you use the mailmanweb Python package to manage Django and its applications. In any case I am not familiar with other organizations of those packages, so I'm going to assume it. If you are not using mailmanweb, you will need to be careful because most subpackages in the Django subsystem name their configuration files settings.py, urls.py, and views.py just like top-level, and distinguish them by using Python's attribute notation (eg, postorius.urls). a. Django application configuration for Postorius and HyperKitty goes in settings.py, which I put in /etc/mailman3. b. Django site configuration for Postorius and HyperKitty goes in urls.py (the routing configuration mapping URLs to views) and views.py (mapping views to Python code). I put these in /etc/mailmn3. c. Full-text indexing for HyperKitty. Default is Whoosh (a Python application) whose configuration goes in Django's settings.py. I prefer Xapian, which requires a separate application (Debian and Ubuntu have packages), but the needed configuration can be done in the top-level settings.py. 7. Template customization. If you have any customized templates for Mailman's email or Django's views, you'll need to copy and move them too. I haven't customized email, but Django's page templates can be kept separately with a path variable set in settings.py. I put them in a hierarchy under /etc/mailman3/templates. Maybe Mailman core has a similar setting? 8. Transient files. Aside from code and configuration, everything in Django is in the RDBMS, there are be no random files strewn around as far as I know. Mailman core is another matter. You can hope that all Mailman transient files are in its "var" hierarchy. $var_dir (the setting in mailman.cfg or inherited from schema.cfg) is the root of this hierarchy. I set var_dir=/opt/mailman/var, I think Mark may use var_dir=/opt/mailman/mm/var. I would guess that FHS-conformant distros would likely use var_dir=/var/lib/mailman3. a. The queue directories $var_dir/queue/* should be empty. Shut down the incoming mail and let mailman run until it's clear. (Normally takes < 5 seconds.) The exceptions are the shunt and bad queues, which are messages that Mailman doesn't know what to do with. With the venv active, run "mailman unshunt" to attempt to clear the shunt queue. Move anything that's left in shunt as well as any .bak or .tmp files into the bad queue for later treatment. These can be copied to the bad queue in the new instance. Use "mailman qfile <file>" to examine them to see if they can be deleted. b. I think the only stuff that ends up in the $var_dir/lists/* directories are digests being built for later distribution. Use the usual tools to send them off or copy them over to the new instance. c. There should be nothing in $var_dir/archives/hyperkitty/spool, which is temporary storage for messages to be archived. That is, it should get cleared up by the few seconds while incoming mail is stopped and outgoing messages are being processed. If there's anything still there, stash it away for later examination using "mailman qfile". (Don't put it in queue/bad or queue/archive though, this is a different process from the normal pipeline.) I think that's about it. Steve

2 years, 2 months

Re: Core, Hyperkitty and Postorius releases

by Odhiambo Washington

On Sat, May 15, 2021 at 1:08 AM Guillermo Hernandez (Oldno7) via Mailman-users <mailman-users(a)mailman3.org> wrote: > > On 14/5/21 23:52, Odhiambo Washington wrote: > >> Which OS are you using? > > FreeBSD. > > > > > As Mark pointed, you probably have installed the textproc/sassc port (or > package). I'ts an equivalent for sass. Do the config as advised. > > I have mailman3 installed and running smoothly in a pair of 12.2 RELEASE > FBSD servers. > > There is a thread about this installations that can help: > https://forums.freebsd.org/threads/mailman-3.61050/post-488128 > <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/> I will look into this. I know FreeBSD has a mailam3 port, but I have mailman2 in production and the port installs to /usr/local/mailman so I have to be careful - install mailman3 in /opt, then plan on hosing mailan2 and moving mailman3 to it's place after migration. It's not simple. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v "^$|^.*#" :-)

4 years, 8 months

Re: Postorius confirmation mails shown in uwsgi-error.log but not sent

by Abhilash Raj

Do you have something like this[1] in your settings.py file? [1]: https://gitlab.com/mailman/mailman-suite/-/blob/master/mailman-suite_projec… `EMAIL_BACKEND = 'django.core.mail.backends.console.EmailBackend'` `This is a dummy email backend which will basically only print the email to stdout, which seems to happen in your uwsgi-error.log. If you do, please comment it out and see if that solves your issue.` `Abhilash` On Sat, Mar 28, 2020, at 5:38 PM, Ralph Seichter wrote: > * Mark Sapiro: > > > What is the complete log message from uwsgi-error.log? > > I'll attach a typical log file to this message. It shows startup > messages followed by a recorded confirmation email. User name and > domain are obfuscated, but other than that the log is unchanged. > > -Ralph > > > _______________________________________________ > 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/ > > > *Attachments:* > * uwsgi-error.log -- thanks, Abhilash Raj (maxking)

5 years, 9 months

Re: Postorius no connection to REST API

by Abhilash Raj

> On Aug 18, 2021, at 6:44 AM, Richard Rosner <rrosner5(a)gmail.com> wrote: > > Abhilash Raj wrote: >> is the config to talk uwsgi protocol and you want to configure Web server to Proxy using the same protocol. You can find that in the uwsgi docs here: https://uwsgi-docs.readthedocs.io/en/latest/Apache.html You probably need an apache module to speak uwsgi, the docs should have the details. >> Notice the URL is uwsgi:// instead of http://. >> Other way is to configure uWSGI to speak HTTP, which can be done by replacing "uwsgi-socket" by "http-socket” in the uwsgi.ini configuration. This might be the easiest for you to try, do make sure to restart the mailman-web service after making the change in uwsgi.ini. > > Thanks, that already helped quite a bit. The website is now loading again, but unfortunately not much else. The site still shows no Connection to REST API. Is your mailman core systemd service up and running? Have you modified the default host:port for Core in mailman.cfg? -- thanks, Abhilash Raj (maxking)

4 years, 5 months

Re: Internal Server Error: /mailman3/postorius/lists/.../held_messages - humanize: where to put?

by Mark Sapiro

On 8/25/25 12:42, Flo via Mailman-users wrote: > Hi, > > I have setup in Debian Trixie mailman3-full and came that far, that I > have created a mailing list. I can sent emails to the members. Your primary support resource for the Debian package is Debian. See https://wiki.list.org/x/12812344 > However when I send from an email which is non-member the message is > held. If I want to accept this message as list admin, I get: > > `An error occurred while processing your request.` > > And I get an email: > > `Internal Server Error: /mailman3/postorius/.../held_messages > > TemplateSyntaxError at /postorius/lists/.../held_messages > 'humanize' is not a registered tag library. Must be one of: You need to add 'django.contrib.humanize' to the INSTALLED_APPS list in settings.py. If you Debian packages don't do this, it should definitely be reported to Debian. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 months, 4 weeks

Mailman Core 3.3.1rc1 release

by Abhilash Raj

Hey Everyone, I have just released Mailman Core 3.3.1rc1. The final release is scheduled for next week, 17th April. This release includes support for bounce processing, which had been lacking in Mailman 3 until now. So, after upgrading to this release, you will notice bounce related notifications from Mailman 3 being sent out to list owners if the list has bounce processing enabled (which, most list do by default). Postorius changes for new bounce processing options are coming out soon, I would like the current head to bake in a little longer since it went through bootstrap 4 upgrade recently. Expect it to be out in about a month. If your users would really care about bounce processing being enabled and not being able to tune threshold and notification parameters in the web interface, you might want to wait for Postorius's next release before upgrading. It also exposes all the remaining attributes of MailingList via REST API, so Postorius can expose them in the Web Interface. This should finally make all attributes of a MailingList manageable via Web Interface, without having to access command line interface. There has also been a whole lot of bug fixes. A full list of changes can be found at: https://mailman.readthedocs.io/en/latest/src/mailman/docs/NEWS.html#rc1 The release is available via PyPI: https://pypi.org/project/mailman/3.3.1rc1/ To install this release via pip, you can run: $ pip install --upgrade --pre mailman Note the `--pre` flag because this is a pre-release. If you can, I encourage you to try this out with your environment and report any major breakage to us. We have been running this code on the server hosting this list, so it has already seen some testing, but it is always nice to have some more. If there aren't any major breaking changes reported, the final release will be identical to this one. -- thanks, Abhilash Raj (maxking)

5 years, 9 months

Re: Customizing Look and Feel?

by Mark Sapiro

On 12/27/18 7:42 PM, Joel Lord wrote: > Is it possible to customize the look at feel of the web interface at > all? I have some lists that really require that subscription requests > include full name, to make the workload on the moderators, well, > workable in keeping a closed list tight. I've found where the "Your > name (optional)" text is in list_forms.py, but modifying that strikes me > as a poor plan. > > Changing that text would be lovely. Actually making that field required > would be seriously awesome. > > Is this possible in the current code base (3.2.0) without doing > ill-advised things modifying source code? None of this is really possible in Postorius without modifying source code. However, Postorius is just an example of a web list management UI. While it is non-trivial, it is possible to build your own web UI that either communicates directly with Mailman core's REST API or communicates via MailmanClient. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years

Re: Unsubscribe Notifications Clarification

by Abhilash Raj

On Wed, Sep 2, 2020, at 7:32 AM, Brian Carpenter wrote: > I am trying to understand how Mailman 3 handles unsubscribe > notifications. From my testing I see the following behavior: > > 1. If list member sends email to listname-leave@listname, an > unsubscribe notification is sent to both list owner and list member if > list settings have them enabled. > > 2. If list list member is a registered user of Postorius and he uses > Postorius to unsubscribe, then no notification is sent out to either > list owner or list member, even if list settings has unsubscribe > notifications enabled. > > Is this correct? This is a bug in Core, for which I have opened https://gitlab.com/mailman/mailman/-/issues/759 It seems like the Unsubscriptions via the API do not follow the right codepath and just unsubscribe the user. It also does not seem to take the unsubscription policy into account. > 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 Raj (maxking)

5 years, 4 months

Re: Finding a user to delete them

by Brian Carpenter

On 3/14/20 5:03 AM, Stephen J. Turnbull wrote: > The bundled administrative interface*is* Postorius. The Mailman > shell is basically a quick hack (sorry Abhilash; if you want to call > it a masterwork and say the speed of development is testimony to your > skills, I won't deny it;-) to give more convenient access to > internals to experienced Mailman hackers. More administrative > features is something we plan to work on, but the Mailman project will > focus on Postorius for the forseeable future. I do think List Admins would want an interface to help "manage" a user account on behalf of a user then what is currently available in Postorius. I see this come up with my Mailman 2 clients frequently. For instance, a mm2 list member asked their list admin to subscribe them to a list topic to limit the amount of messages they receive. The list admin was new and open up a ticket to find out how they do that in which I replied showing them how they as a list admin, can go in and change options on behalf of a list member. I don't see this functionality built into Mailman 3 nowhere near the extent that Mailman 2 has. Last night a Mailman 3 client wanted to know how they can add a real name to a list member. I said you can't, not as list admin. I directed them to instead of unsubscribe the member and mass subscribe them so they can include a real name along with the email address of the list member. > For alternatives to Postorius and the Mailman shell, Brian Carpenter > (follow Allan's subthread) is working on a new management UI (using > PHP), and I believe there's a working node.js API "out there > somewhere". Please be very considerate of Brian's time; he and EMWD > constitute a bulwark of the Mailman ecosystem and will be even busier > with the UI project. But do pass on your suggestions to him as well > as to us, he's indicated he's open to that. There were some very good suggestions that were brought out in this thread and I had already passed them on to my developer. My approach with Affinity is definite leaning very heavy on the needs of list admins atm. -- 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, 10 months

Re: SUBSCRIBE_FORM_SECRET in MM3?

by Mark Sapiro

On 1/30/20 1:50 AM, Gila Halpern wrote: > I've been looking into ways to prevent spam on my company's list, and one thing I came across was the SUBSCRIBE_FORM_SECRET option in the Mailman configuration, which embeds a CSRF token into the form, and prevents it from being submitted until five seconds after it renders, to keep bots from subscribing. Unfortunately, the information I found pertained to Mailman 2. Does this option exist in MM3 as well, or is there a similar option? This feature in MM 2.1 is not very effective. On mail.python.org, this feature as well as reCAPTCHA is enabled (e.g. <https://mail.python.org/mailman/listinfo/mailman-users>) and we still get periodic attacks of robotic subscribes that get around these measures. To answer your question, no, this does not exist in Postorius which is an entirely different, Django based web UI. Django may have some protections built in; I'm not sure about that, but there's nothing in Postorius itself like this MM 2.1 feature. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 11 months

Mailman-users search results for query "Postorius"