Search results for "Postorius" - Mailman-users

Re: Fresh installation mailman3-suite via "pipx" - any experiences yet?

by Stephen J. Turnbull

Mark Sapiro writes: > But postorius and hyperkitty are dependencies of mailmanweb so only Are they? I'm pretty sure that in my current project which has a pre-existing archiver they wish to keep using I only installed postorius, not hyperkitty. ... oops, HyperKitty *is* there. OK, need to uninstall that. That's actually a bit annoying, since mailmanweb is a friendlier interface for control of either of HyperKitty and Postorius than the underlying Django utilities even if you don't want the other and its unique dependencies (such as Whoosh). (Issue #32 created) OK, so your two-venv approach should actually work. I still don't think it's much of a win since to finish setup you still have to do a lot of work as root and a lot of work outside of pipx's control. Basically it saves one "python3 -m venv", at the cost of "pipx run" to run each program in its own venv. Note, it doesn't save me any venv activationss because I put that in the mailman user's shell .rc. Wikinaut asks: > Has anyone tried that already? Why not you? Steve

2 years, 3 months

Re: Splitting hosts: mta&core vs postorius

by Andrew Hodgson

Stephen J. Turnbull wrote: >Ruth Ivimey-Cook writes: > > On 21/06/2020 04:52, Mark Sapiro wrote: > > > Change that to greyarea-post > > Problem is, if I do that (which I did in the beginning), the core rest > service listens on localhost / 127.0.0.1 >I don't understand. I'm not in a position to test with Mailman itself right now, but the standalone gunicorn[1] does the right thing (takes an IP address and binds to the corresponding interface, or takes a domain name, resolves it to >the IP address, and binds that to the corresponding interface). It does not substitute localhost. Sorry not to reply to ruth on this before, my main experience of this issue was running in a Kubernetes cluster using Docker, using https://github.com/maxking/docker-mailman as the basis for the images. What follows is my own research on this issue and it may be completely wrong. Taking the default Mailman Core setting: [webservice] hostname: localhost This makes Mailman-Core listen on the loopback address (via name lookup) on the configured port for incoming REST requests. When it responds to these requests, it sends out in the response a self_link address which matches the [webservice] hostname Parameter. Connecting clients (such as Postorius) need to connect to Mailman-Core on the given hostname (eg http://localhost in the default case where Mailman Core and Web components are installed to the same machine. However if the [webservice] hostname: parameter is set to something like 0.0.0.0, then although you can direct Postorius (via DNS lookup or IP address) at the Mailman Core instance, it fails to work properly because the resulting response sent back from Mailman Core will include self_links pointing at 0.0.0.0 which will not be usable as a URL by the REST client. A fix for this issue is to set the [webservice] hostname parameter to a FQDN or IP address which can be resolved by the machine running the Web components, and as long as the base URL that Postorius tries to use for the Mailman Core access is the same as in the [webservice] hostname parameter, you are good to go. It appears that when specifying a FQDN in the [webservice] hostname parameter, that the system will look up the IP address for that host using the systems name resolution function. This has the side affect of potentially listening on the wrong interface (localhost) if the system hosts file is set such that the machine's FQDN points to 127.0.0.1. In my case my containers were behind CoreDNS and this wasn't an issue for me, but had I tried this for example on a Debian system I would have come against the same issue that Ruth has as it will automatically set the FQDN of the system to resolve to 127.0.0.1 by way of the Hosts file. Adding the network IP address of the system with the FQDN in the hosts file should fix this issue. > > IMO, the hostname parameter needs to be split up into a "what address > should the rest of the world use to address me" and separately "what > address(es) should I listen on". Multiple listen addresses enable > multihomed >hosts to get the right connectivity, too. >I'm not clear on what you're saying. An address is a rendezvous point; if you're not listening on the address that others are using, you won't meet. What good does it do to split them up? I agree with this, we need a setting for which interface for Gunicorn to listen on, and what Mailman Core sends out in the self_link attribute when responding to REST requests. Thanks. Andrew.

5 years, 10 months

Re: Hipperkitty failing to archive messages in a list

by Guillermo Hernandez (Oldno7)

On 5/1/22 21:50, Mark Sapiro wrote: First, thanks a lot Mark for your guidance. >> >> HINT: Configure the DEFAULT_AUTO_FIELD setting or the >> SocialAccountConfig.default_auto_field attribute to point to a >> subclass of AutoField, e.g. 'django.db.models.BigAutoField'. > > This is from Django >=3.2 can be fixed by adding > > DEFAULT_AUTO_FIELD = 'django.db.models.AutoField' > > to your settings. This has been done in HyperKitty's > example_project/settings.py for the not yet released 1.3.6 version. > > These warnings are only warnings, they aren't fatal. I thought so. I've added it in the settings.py file. In the last part of your suggestions you wrote: "I suggest you do pip install --upgrade hyperkitty mailman-hyperkitty and ensure it installs hyperkitty 1.3.5 and mailman-hyperkitty 1.2.0" But this is exactly what made me fall in this mess: I realized that the versions of hiperkitty and mailman-hiperkitty in that server were outdated.. and I tried update them separately, forgetting the saying "if it works, don't touch it" (si funciona, no lo toques). In my first message I listed the versions of all the items, but to refresh it, as they are now: (from pip list) ... gunicorn 20.1.0 HyperKitty 1.3.5 ... mailman 3.3.5 mailman-hyperkitty 1.2.0 mailmanclient 3.3.3 ... mistune 2.0.1 ... mod-wsgi 4.7.1 ... postorius 1.3.6 (end of pip list) I did the upgrade of all of it. The "migration" process output the same warning as before about to doing a "makemigration" (I did not this time) Thinking that the problem in the "migrate" and "makemigration" process could be that I touched the mistune/scanner.py to add escape and escape_html imports, I deleted that two lines. Then all went bad: the postorius list page didn't show anymore. The error.log form the apache server shows django.template.library.InvalidTemplateLibrary: Invalid template library specified. ImportError raised when trying to load 'hyperkitty.templatetags.decorate': cannot import name 'escape_html' from 'mistune.scanner' (/usr/local/lib/python3.7/site-packages/mistune/scanner.py) So I tried to put them back (but I had problems with, I believe, the __pychache__). I had to reinstall mistune and write back this lines that I found in a previous thread from William Oliver last 12/28/21 I've finally came back to administering the lists via postorius. I created a new list to do the tests without disturbing the rest. And now I am at the exact same point: No message is archived and the log shows: ERROR 2022-01-06 12:38:45,574 39059 hyperkitty.views.mailman The MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header. ERROR 2022-01-06 12:38:45,586 39059 hyperkitty.views.mailman The MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header. ERROR 2022-01-06 12:38:45,801 39059 hyperkitty.views.mailman The MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header. ERROR 2022-01-06 12:38:45,832 39059 hyperkitty.views.mailman The MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header. ERROR 2022-01-06 12:38:45,847 39059 hyperkitty.views.mailman The MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header. ERROR 2022-01-06 12:38:45,867 39059 hyperkitty.views.mailman The MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header. ERROR 2022-01-06 12:38:46,075 39059 hyperkitty.views.mailman The MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header. As this server has very low traffic, the emails are distributing well, and the only thing that fails is the archiving of new messages, I will wait until a more complete upgrading process is needed for mailman, postorius or hiperkitty. Thanks, again, for your support. P.S.: One thing that make me curious is the "mistune" package... I don't see it installed in the other servers that are working flawlessly with mailman3. > > ... >> Running a 'su -m mailman3 -c "python3 manage.py makemigrations" shows >> the same warning listed before and some new errors: >> >> *-*-*-*-*-*-* >> >> Migrations for 'postorius': >> /usr/local/lib/python3.7/site-packages/postorius/migrations/0017_alter_emailtemplate_name.py >> >> - Alter field name on emailtemplate >> Traceback (most recent call last): >> File "manage.py", line 10, in <module> >> execute_from_command_line(sys.argv) >> File >> "/usr/local/lib/python3.7/site-packages/django/core/management/__init__.py", >> line 419, in execute_from_command_line >> utility.execute() >> File >> "/usr/local/lib/python3.7/site-packages/django/core/management/__init__.py", >> line 413, in execute >> self.fetch_command(subcommand).run_from_argv(self.argv) >> File >> "/usr/local/lib/python3.7/site-packages/django/core/management/base.py", >> line 354, in run_from_argv >> self.execute(*args, **cmd_options) >> File >> "/usr/local/lib/python3.7/site-packages/django/core/management/base.py", >> line 398, in execute >> output = self.handle(*args, **options) >> File >> "/usr/local/lib/python3.7/site-packages/django/core/management/base.py", >> line 89, in wrapped >> res = handle_func(*args, **kwargs) >> File >> "/usr/local/lib/python3.7/site-packages/django/core/management/commands/makemigrations.py", >> line 190, in handle >> self.write_migration_files(changes) >> File >> "/usr/local/lib/python3.7/site-packages/django/core/management/commands/makemigrations.py", >> line 228, in write_migration_files >> with open(writer.path, "w", encoding='utf-8') as fh: >> PermissionError: [Errno 13] Permission denied: >> '/usr/local/lib/python3.7/site-packages/postorius/migrations/0017_alter_emailtemplate_name.py' >> >> >> *-*-*-*-*-*-* >> >> The file >> '/usr/local/lib/python3.7/site-packages/postorius/migrations/0017_alter_emailtemplate_name.py' >> does not exist at all > > > makemigrations is trying to create that migration and you don't have > permission to create the file. I don't know why it's trying to do > that. Postorius 1.3.6 has migrations through > 0016_auto_20210810_2157.py and shouldn't need more. To you have > modificationd to Postorius? > > >> Despite the error, I did a 'su -m mailman3 -c "python3 manage.py >> compress"' and the subsequent "django-admin compilemessages" in >> >> /usr/local/lib/python3.7/site-packages/postorius, ../hyperkitty and >> ../django_mailman3 >> >> And the log continues showing the same error when trying archive a >> new message. >> >> ERROR 2022-01-05 12:27:31,406 6988 hyperkitty.views.mailman The >> MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header. >> ERROR 2022-01-05 12:27:31,418 6988 hyperkitty.views.mailman The >> MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header. >> ERROR 2022-01-05 12:27:31,685 6988 hyperkitty.views.mailman The >> MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header. >> ERROR 2022-01-05 12:27:32,045 6988 hyperkitty.views.mailman The >> MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header. >> ERROR 2022-01-05 12:27:32,070 6988 hyperkitty.views.mailman The >> MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header. >> ERROR 2022-01-05 12:27:32,093 6988 hyperkitty.views.mailman The >> MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header. > > > These messages come from some HyperKitty version between commit > b415d29d6cc59b3270c35b03ba3313dd03450271 Mon Jun 21 00:11:48 2021 > -0700 and > commit c6272f3ef8375865382d0741d3d371a0dc41508a Fri Oct 8 06:32:06 > 2021 +0000 > > They do not come from HyperKitty 1.3.5 but from something later than > 1.3.4 which makes be think your mailman-hyperkitty version is not > 1.2.0 either. > > I suggest you do > > pip install --upgrade hyperkitty mailman-hyperkitty > > and ensure it installs hyperkitty 1.3.5 and mailman-hyperkitty 1.2.0 > > -- ___________________________________________ Mailman's content filtering has removed the following MIME parts from this message. Content-Type: image/png Name: firma-GHP-emails.png Replaced multipart/alternative part with first alternative.

4 years, 4 months

Re: Starting new thread in Postorius -> disappears

by Abhilash Raj

Hi Thor, On Tue, 2017-11-21 at 10:53 +0100, Thor Atle Rustad wrote: > I have had this working before, so I guess it's a simple setup error. > > When I send a message from the Postorius interface, it is neither sent out > or stored. I briefly see this message: "Your reply has been sent and is > being processed.", and then nothing happens. When you say nothing happens, you just mean that you don't see anything in the UI or you don't see anything in the logs? Logs for mailman-web are in /opt/mailman/web/logs/mailmanweb.log (on the host). > > I have installed maxking's docker-mailman and copied my old setup with > basic stuff like passwords and such. The only new thing is that I'm now > running in userspace by putting in /etc/subuid and subguid: > > mailman:10000:65536 This ideally shouldn't affect anything, I haven't tried running this way though. > > > and in /etc/docker/daemon.json: > > { > "userns-remap": "mailman" > } > > So I get the following ownership in /opt/mailman: > > > drwxrwsr-x 3 10100 10000 4096 nov. 21 09:00 core > drwx------ 19 10070 10000 4096 nov. 21 09:27 database > drwxr-sr-x 5 10100 10101 4096 nov. 21 09:24 web > > (I have created a user named mailman with uid 10100 so, in reality, it says > "mailman" there instead of 10100 but I guess that is irrelevant here) If would be interesting to see what processes are running inside each containers and who their owners are, in case this is at all relevant to the issue, which I am not so sure about. > _______________________________________________ > Mailman-users mailing list > mailman-users(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ -- thanks, Abhilash Raj

8 years, 5 months

Re: Splitting hosts: mta&core vs postorius

by Ruth Ivimey-Cook

> >> In referring to the ConnectionError from: >> >> 'ConnectionError(MaxRetryError("HTTPConnectionPool(host=\'0.0.0.0\', >> port=8870): Max retries exceeded with url: /3.1/domains/ch-bc.org.uk >> (Caused by NewConnectionError(\'<urllib3.connection.HTTPConnection >> object at 0x7f5416db8518>: Failed to establish a new connection: >> [Errno 111] Connection refused\',))",),)') >> >> if you reconstruct the url passed in it was presumably: >> >> "http://0.0.0.0:8870/3.1/domains/ch-bc.org.uk" > > I don't think so. I think it was > http://greyarea-post:8870/3.1/domains/ch-bc.org.uk and requests.request > couldn't resolve that to the correct IP. > > If you look at Mailman client > <https://gitlab.com/mailman/mailmanclient/-/blob/master/src/mailmanclient/re…> > you'll see it makes the URL from the baseurl passed to the instantiation > of the Connection class which occurs at > <https://gitlab.com/mailman/mailmanclient/-/blob/master/src/mailmanclient/cl…> > which in turn is called from Postorius at > <https://gitlab.com/mailman/postorius/-/blob/master/src/postorius/utils.py#L…> > which makes the baseurl argument from '%s/3.1' % > settings.MAILMAN_REST_API_URL. > I set up tcpdump looking at port 8870 traffic. This is what I saw (TCP ACK packets omitted): 02:10:44.099300 IP greyarea-web1.cam.ivimey.org.38690 > greyarea-post.cam.ivimey.org.8870: Flags [P.], seq 1:255, ack 1, win 502, options [nop,nop,TS val 77293118 ecr 279301477], length 254 E..2..@.@.XX.. C.. B.""..Z...l............. ..f>...eGET /3.1/domains HTTP/1.1 Host: greyarea-post.cam.ivimey.org:8870 User-Agent: GNU Mailman REST client v3.3.1 Accept-Encoding: gzip, deflate Accept: */* Connection: keep-alive Authorization: Basic cmVzdGFkbWluOj1ldWJocXA5cjgzcnZucWxKZWl1ZnY6YWI= Connect to greyarea-post with a URL like http://greyarea-post/3.1/domains 02:10:44.099748 IP greyarea-post.cam.ivimey.org.8870 > greyarea-web1.cam.ivimey.org.38690: Flags [.], ack 255, win 508, options [nop,nop,TS val 279301479 ecr 77293118], length 0 E..4.?@.@..... B.. C"..".l...Z......:...... ...g..f> 02:10:44.105704 IP greyarea-post.cam.ivimey.org.8870 > greyarea-web1.cam.ivimey.org.38690: Flags [P.], seq 1:154, ack 255, win 508, options [nop,nop,TS val 279301485 ecr 77293118], length 153 E....@@.@..... B.. C"..".l...Z......`...... ...m..f>HTTP/1.1 200 OK Server: gunicorn/20.0.4 Date: Sun, 21 Jun 2020 02:10:44 GMT Connection: close content-length: 299 content-type: application/json Reply from greyarea-post saying OK.... (more) 02:10:44.105753 IP greyarea-post.cam.ivimey.org.8870 > greyarea-web1.cam.ivimey.org.38690: Flags [P.], seq 154:453, ack 255, win 508, options [nop,nop,TS val 279301485 ecr 77293118], length 299 E.._.A@.@..... B.. C"..".l._.Z............. ...m..f>{"start": 0, "total_size": 1, "entries": [{"alias_domain": null, "description": null, "mail_host": "ch-bc.org.uk", "self_link": "http://0.0.0.0:8870/3.1/domains/ch-bc.org.uk", "http_etag": "\"5d474f0be89222e6122b6dc375a18ff01190419d\""}], "http_etag": "\"c6f15186189ff5cf5b67f2d06dcf4ea97ea447a9\""} 02:10:44.105757 IP greyarea-web1.cam.ivimey.org.38690 > greyarea-post.cam.ivimey.org.8870: Flags [.], ack 453, win 501, options [nop,nop,TS val 77293124 ecr 279301485], length 0 E..4..@.@.YT.. C.. B.""..Z...l............. ..fD...m ... the Body of reply, with the JSON text: { "start": 0, "total_size": 1, "entries": [ { "alias_domain": null, "description": null, "mail_host": "ch-bc.org.uk", "self_link": "http://0.0.0.0:8870/3.1/domains/ch-bc.org.uk", "http_etag": "\"5d474f0be89222e6122b6dc375a18ff01190419d\"" } ], "http_etag": "\"c6f15186189ff5cf5b67f2d06dcf4ea97ea447a9\"" }

5 years, 10 months

Re: mail host choices when creating a new list

by Abhilash Raj

On Tue, Oct 24, 2017, at 12:24 PM, Andrew Hodder wrote: > Abhilash, > I'm not sure what you're referring to, there's no "web hosts" in the > admin panel and I already added the "mail hosts" there (of the four > added, only the first one shows up in the postorius drop down). Ah! I mis-read your email. You need to add new domains in Postorius before you can create new lists using them. You are looking for '/postorius/domains/', add a new domain there, and then it will show up in the 'mail hosts' in create-new-list form. > > Sincerely, > > Andrew Hodder Systems Administrator Support Operations, Afilias E- > mail: drew(a)afilias.info Phone: +1 416.673.4164 Fax: +1 > 416.646.1541> > On Tue, Oct 24, 2017 at 3:08 PM, Abhilash Raj > <maxking(a)asynchronous.in> wrote:>> Hi Andrew, >> >> On Tue, Oct 24, 2017, at 11:58 AM, Andrew Hodder wrote: >> > Hi! >> > >> > So, I'm trying to create a new list and pick one of the other mail >> > domains we have configured (from the django admin panel), yet in >> > the "Create New List" page in postorius, I see only a single >> > option (the first domain we'd added/set as the default) in the drop- >> > down under "Mail Host". Am I missing somewhere else I need to add >> > alternative mail domains to? Thanks in advance! >> >> Yes, you can add new 'Web Hosts' from the Django's Admin console>> (admin/django_mailman3/maildomain/). Note that you need to be a >> superuser to do this. >> >> >> -- >> Abhilash Raj >> maxking(a)asynchronous.in -- Abhilash Raj maxking(a)asynchronous.in

8 years, 6 months

Re: restricting public lists per virtual domain

by David Newman

On 12/16/21 2:40 PM, Mark Sapiro wrote: > On 12/16/21 12:25 PM, David Newman wrote: >> Can lists set to be viewable on the index page be limited to the >> virtual domain they are a part of? >> > > > Have you set > > FILTER_VHOST = True > > in your Django settings? I had not, and this was the variable I was looking for. Thank you! This works for HyperKitty and works partially > for Postorius. For Postorius, it doesn't work if there are multiple > domains with different email hosts which have the visiting host as their > web host[1] but works otherwise. > > See https://gitlab.com/mailman/postorius/-/merge_requests/500 and > https://gitlab.com/mailman/postorius/-/issues/394 > > In your case, as long as the domains lists.dom1.tld and lists.dom2.tld > have different mail hosts, this should work. > > [1] An example of what doesn't work in Postorius is the following: > > Visit https://lists.example.com/mailman3/lists. If there are 2 domains > with web host lists.example.com, one of which has mail host example.com > and the other has mail host lists.example.com, all lists will be shown > regardless of domain. On the other hand, if all the domains with web > host lists.example.com have the same email host, say example.com, then > only lists with email host example.com will be shown. Awhile back Stephen Turnbull suggested a terminology guide that included an MM3-specific definition of FQDNs. Also in an MM3 context, I think it would be useful to distinguish between mail hosts and web hosts and domains (all in the general Internet sense) and mail domains and sites (in the MM3/Django/Postorious/Hyperkitty sense). Not sure I fully understand these distinctions yet, but I can take a crack at it. dn

4 years, 4 months

Re: AttributeError: 'MailingList' object has no attribute 'get_requests_count'

by Mark Sapiro

On 10/25/20 8:22 AM, Shashikanth Komandoor wrote: > Hi Team, > > I am currently running Mailman 3 with version 3.3.2rc2 and in > built postfix version 2.10.1-6 on RHEL 7.5 with PostgreSQL 11.9 version > with default values. As of now, we don't have any lists and just installed > software components only. > > After the installation and configuration, I have tried > creating the domains and lists. I was successful in creating them but when > I tried to login and browse the lists using LDAP authentication, I am > getting the "Mailman REST API not available. Restart Mailman core". > > I see the below trace in the mailmansuite.log. > > *Traceback (most recent call last): File > "/var/lib/mailman/venv3/lib64/python3.6/site-packages/mailmanclient/restbase/base.py", > line 119, in __getattr__ return self._get(name) File > "/var/lib/mailman/venv3/lib64/python3.6/site-packages/mailmanclient/restbase/base.py", > line 86, in _get raise KeyError(key)KeyError: 'get_requests_count ... > > I don't see any error messages in the mailman.log. And I > also executed a few curl commands in getting the details of the lists > created and list info which I got their results successfully. > > Could you please guide where exactly I am missing or do I > need to make any changes in my customizations ? I think the issue is your mailmanclient is too old. The version of Postorius you are running requires mailmanclient >3.3.1 which is only available from GitLab <https://gitlab.com/mailman/mailmanclient>. What version of Postorius is this? It appears to be >1.3.3. If you install Postorius from unreleased code on GitLab, you have to install all of mailman, mailmanclient and django-mailman3 as well. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 6 months

Re: only show mail domains from web host on web-host-url

by Abhilash Raj

> On Mar 19, 2021, at 6:38 AM, Jens Günther <jens.guenther(a)posteo.de> wrote: > > Thank you for your answer. I should have seen that in the Docs, but somehow missed it: https://docs.mailman3.org/en/new/prodsetup.html You seem to have landed on a very old version of the docs that I didn’t unfortunately knew was even available. I have disabled that page now. The settings are documented in https://docs.mailman3.org/en/latest/config-web.html > > I set it in the corresponding file, but unfortunately it doesn't work :-( I tried other setting to prove, that the file is used (ALLOWED_HOSTS works, changed here from '*' to 'localhost' and my example-domains, this works). It seems to be the same as this user describes (a while ago): https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/… > > How could I check, that the setting is used!? > > But maybe some additional information: > - I use the Debian installation on a stable buster, so mailman is version 3.2.1 > - I use apache2 as my web-server and use the given alias-conf-file > - Python is version 3.7.3 > - Postorius is Version 1.2.4 > - HyperKitty is version 1.2.2 > > -> In Django admin-Panel (/mailman3/admin/) I added 2 Websites test1.xyz.de and test2.xyz.de > -> In Postorius (/mailman3/postorius/domains/) I added 2 Domains as Mail Hosts test1.xyz.de and test2.xyz.de with the corresponding Web hosts as stated above > -> I added 1 list (/mailman3/postorius/lists/) for each Mail Domain as follows: test1(a)test1.xyz.de and test2(a)test2.xyz.de > -> then created a vhost in apache2 with SSL-cert and added the Domains in ALLOWED_HOSTS: test1.xyz.de and test2.xyz.de > -> When I go to the 2 Testdomains (corresponding web hosts), I see on each both lists for the different Mail domains > > What do I miss? Or where to investigate? > > Thank you in advance, best regards. > > By the way: what'S the difference in the 2 docs? https://docs.mailman3.org/en/latest/index.html and https://mailman.readthedocs.io/en/latest/README.html Mailman Suite consists of several individual projects including Mailman Core, Postorius (Web UI) and Hyperkitty (Archiver). The first URL is the landing page for the entire suite and should direct you to individual projects. The second one is the individual Mailman Core project. Historically, Core was the only project and hence claims the name “mailman” in most places. > > Am 18.03.21 um 21:52 schrieb Mark Sapiro: >> On 3/18/21 9:20 AM, jens.guenther(a)posteo.de wrote: >>> Is it possible, to only show publicly (if advertised) these lists on a certain url, that are corresponding to the web host the url I accessed mailman through? >> Set FILTER_VHOST = True in your settings_local.py or where ever you put >> your site Django settings. > _______________________________________________ > 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, 1 month

Mailman backend maintenance task

by Stephen J. Turnbull

Hi, Eugenio, I wrote this earlier but am in the middle of moving my office so my mail has been intermittent. I have been following your discussion with Abhilash, and he's definitely the expert, especially if you are using the containers he creates and distributes. But there's some information here he hasn't mentioned yet. Please consider the following discussion to be background that allows you to understand some of the considerations. I've only run the Mailman 3 suite with all three running constantly on the same host, so I have no experience with this kind of issue. eugenio.jordan(a)esa.int writes: > Our customer is currently using PostGRESQL as backend, and we would > like to perform some maintenance tasks, namely running vacuum full, > or at least trying to rebuild hyperkitty_email primary key related > index. We have been asked on the real impact of putting in place > such initiative. Though the latter is related to archiving, I > haven't found a way to stop just Hyperkitty or Django related > processes other than stopping Mailman's core, hence preventing > mails addressed to distribution lists from being delivered, could > you please confirm if I am correct? Mailman core can certainly run without either Postorius or HyperKitty. Controlling Mailman core (moderation, helping users) without Postorius is annoying, but it can be done. If you stop the HyperKitty process, what should happen, I believe, is that posts for archiving will accumulate in the 'archive' queue until HyperKitty is available again. It's been a while since I studied this so I could be completely wrong, but as I understand it HyperKitty and Postorius are not daemon processes. Rather, they are WSGI applications, which means they are subprocesses spawned by your webserver, and controlled by it. In order to keep them from running, you would reconfigure the webserver to not call those WSGI applications. How that is done is specific to the webserver and the WSGI module. If you are running from Docker containers, most likely, you can just stop their containers. The larger problem is that Mailman core uses a RDBMS. Normally both Django and Mailman are referring to the same RDBMS, PostgreSQL in your case. I'm not familiar with the vaccuum operation; if it requires taking the whole RDBMS down, and Mailman is running on that RDBMS, you're out of luck. Mailman can accept posts and queue them, but it can't deliver them to subscribers without access to the RDBMS tables. If it's just a matter of locking some tables while other are available, then it should work because the tables used by core and HyperKitty are disjoint as far as I know. (I think Postorius and HyperKitty both use Django's user tables for authorization, so at least for those tables both Postorius and HyperKitty will have to be down, but core can continue running because its database is completely separate.) > Regarding the former, as far as I have read, the "mappings" lists > -> addresses are stored just in the database, so if we run some > kind of procedure or task like vacuum which will lock exclusively > tables, or want anyway to have the database stopped for a cold > backup or whatever, Mailman willl not work, that is, again the > mails addressed to the distribution lists will not be > delivered. Will you please confirm this point, too? That depends on how "vacuum" works. If you can tell the RDBMS not to lock Mailman core's tables, it can continue to run. Definitely if the database is not running, Mailman will continue to receive and store the posts, but it won't be able to distribute mail to subscribers until its tables are available again. At that point the queued posts will be processed normally, except that if there's a large backlog, they won't go out in a quick burst, it may take a while. One possible worry, depending on how you are connected to the Internet, is that your provider may interpret the sudden burst of outgoing mail when Mailman comes back on line as spam or some other sort of mischief. Mailman has no way to throttle this: it feeds messages to the MTA until the MTA says "stop". Then it waits until the MTA is ready again. Regards, Steve

4 years, 8 months

Mailman-users search results for query "Postorius"