Search results for "Postorius" - Mailman-users

Re: About to Install MM3 -- Seeking clarification

by Onyeibo Oku

On Thu, 8 Dec 2022 17:27:13 +0100 Onyeibo Oku <onyeibo(a)schemefusion.com> wrote: > [Reviving this thread]. > > I abandoned the hyperkitty setup for a while and returned to it again > today. I made progress. It turns out that I needed the > uwsgi-logger-file rpm package and It wasn't installed with the uwsgi > server. I adapted the settings also, since I was using Emperor mode > (recall that there are other Django projects on the box). Currently, > mailman, uwsgi and nginx are all running. They all seem to be happy > until I assess the mailman-web home URL (e.g. http://my.server.com) > > The outcome: > "502 Bad Gateway" > > Nothing shows in the logs except at /var/log/nginx/error.log: > > 2022/12/08 15:35:10 [error] 5879#5879: *7 upstream prematurely closed > connection while reading response header from upstream, client: > 105.113.33.89, server: my.server.com, request: "GET /favicon.ico > HTTP/1.1", upstream: "http://127.0.0.1:8000/favicon.ico", host: > "my.server.com", referrer: "https://my.server.com/". > > Something seems to be wrong between uwsgi and mailman, but I don't > know where to look. > > Regards Onyeibo Happy New Year to all the Mailman People here (nice rhyme). I pulled the plugs on uwsgi and installed Gunicorn. Gunicorn gave more mileage but something is still not right. When I visit the mailmanweb home with a browser, I see the following: "Server Error. An error occurred while processing your request." Mailmanweb and mailman3 services are running. I perused the log file at /opt/mailman/web/logs/mailmanweb.log and found the following: raise MailmanConnectionError( mailmanclient.restbase.connection.MailmanConnectionError: ('Could not connect to Mailman API: ', 'ConnectionError(MaxRetryError("HTTPConnectionPool(host=\'localhost\', port=8001): Max retries exceeded with url: /3.1/lists?advertised=true&count=0&page=1 (Caused by NewConnectionError(\'<urllib3.connection.HTTPConnection object at 0x7f7f4b128c40>: Failed to establish a new connection: [Errno 111] 0x7f7f4b128c40>Connection refused\'))"))') During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/opt/mailman/venv/lib64/python3.10/site-packages/django/core/handlers/exception.py", line 55, in inner response = get_response(request) File "/opt/mailman/venv/lib64/python3.10/site-packages/django/core/handlers/base.py", line 199, in _get_response response = self.process_exception_by_middleware(e, request) File "/opt/mailman/venv/lib64/python3.10/site-packages/django/core/handlers/base.py", line 362, in process_exception_by_middleware response = middleware_method(request, exception) File "/opt/mailman/venv/lib64/python3.10/site-packages/postorius/middleware.py", line 48, in process_exception return utils.render_api_error(request) File "/opt/mailman/venv/lib64/python3.10/site-packages/postorius/utils.py", line 36, in render_api_error return render(request, 'postorius/errors/generic.html', File "/opt/mailman/venv/lib64/python3.10/site-packages/django/shortcuts.py", line 24, in render content = loader.render_to_string(template_name, context, request, using=using) File "/opt/mailman/venv/lib64/python3.10/site-packages/django/template/loader.py", line 62, in render_to_string return template.render(context, request) File "/opt/mailman/venv/lib64/python3.10/site-packages/django/template/backends/django.py", line 62, in render return self.template.render(context) File "/opt/mailman/venv/lib64/python3.10/site-packages/django/template/base.py", line 173, in render with context.bind_template(self): File "/usr/lib64/python3.10/contextlib.py", line 135, in __enter__ return next(self.gen) File "/opt/mailman/venv/lib64/python3.10/site-packages/django/template/context.py", line 254, in bind_template updates.update(processor(self.request)) File "/opt/mailman/venv/lib64/python3.10/site-packages/django_mailman3/context_processors.py", line 32, in common context["site_name"] = get_current_site(request).name File "/opt/mailman/venv/lib64/python3.10/site-packages/django/contrib/sites/shortcuts.py", line 16, in get_current_site return Site.objects.get_current(request) File "/opt/mailman/venv/lib64/python3.10/site-packages/django/contrib/sites/models.py", line 59, in get_current return self._get_site_by_id(site_id) File "/opt/mailman/venv/lib64/python3.10/site-packages/django/contrib/sites/models.py", line 30, in _get_site_by_id site = self.get(pk=site_id) File "/opt/mailman/venv/lib64/python3.10/site-packages/django/db/models/manager.py", line 85, in manager_method return getattr(self.get_queryset(), name)(*args, **kwargs) File "/opt/mailman/venv/lib64/python3.10/site-packages/django/db/models/query.py", line 650, in get raise self.model.DoesNotExist( django.contrib.sites.models.Site.DoesNotExist: Site matching query does not exist. Can someone point me in the right direction please? Regards Onyeibo

3 years, 5 months

Re: Postorius is not working (throws "Error 500" suddenly after changing POSTORIUS_TEMPLATE_BASE_URL and changing back)

by Stephen J. Turnbull

Wikinaut writes: > I fully understand. Need to look up how to smoothly backup the > mailman3 settings and list databases in order to make that move > with losing stuff... (kinda "mailman3 backup all" and mailman3 > restore all" :-) One piece of generic Python advice: don't mix OS packages and pip (except for Python itself). Always use a venv if you need to use pip for packages that aren't in your OS distro. (Of course it's possible to do so in many cases if you *really* know what you're doing, but it's almost never worth the pain.) All of the site configuration data should be in /etc/mailman3 (except for a few template files in $var_dir/templates), and all of the domain, list configuration, and archive data is in the RDBMS (usually PostgreSQL or MySQL). The RDMBS should be backed up regularly according to its procedures, but that's completely out of scope for Mailman.[1] The RDBMS should "just work" with exactly the same Mailman-side configuration as Debian.[2] As I think Odhiambo mentioned, the Mailman side of the site configuration also does not change (for example, the RDBMS URL and authentication). What you do want to change is the file system configuration. Except for /etc/mailman3, it should be completely different -- as with pip'ing packages, you don't want to share files across a local venv and the OS version of the same package. It just leads to pain. I think among the developers the preferred root = /opt/mailman (or /opt/mailman3) for Mailman's directory hierarchy. This will be populated with subdirectories when you run `mailman info` (or start Mailman) the first time. The directories relevant to configuration are all under $root/var, and you inform Mailman about this by setting `var_dir` in mailman.cfg. If there are other file and directory configurations in mailman.cfg, they need to changed from the Debian values (probably /var/lib/mailman3/...). You may do fine by simply deleting all other directory configurations and let Mailman decide where to put them relative to the `var_dir`, You will need to fix the setting for STATIC_ROOT (I think that's the name, if not search for "static") in settings.py, and maybe in mailman-web.cfg. While it's not necessary (and may be a little inconvenient), I recommend changing the root for Mailman's log files from the Debian value (probably /var/log/mailman3) to the Mailman default of $root/var/logs, and similarly for the Django logs in settings.py. Non-Mailman settings I think you will need to change the settings for your MTA (usually Postfix or Exim4) so that it will recognize Mailman lists and route them to Mailman correctly. There will probably be mailman-related files in /etc/$MTA/conf.d (or something like that). You can edit them directly, but I recommend changing the name (paranoia so that dpkg doesn't overwrite them). The only thing I can think of for the webserver (Apache?) is the location of the static directory. I think Debian uses uwsgi by default so you may need to adjust its configuration too. I think you need to fix logrotate's configuration in /etc/logrotate.d. Not sure how many mailman-related config files are in there. I think you mentioned systemd .service files. If so that doesn't make sense to me -- Debian should provide those. You need to make sure those are disabled or deleted so that Debian Mailman services don't start on reboot. This is automatic if you delete the Debian packages, of course, but not for any files you created yourself. Probably the Debian .service files will work, but you need to make sure they refer to the venv Mailman (using the full path to the `mailman` utility in the venv's bin directory will work, and similarly for `mailman-web`). systemd does not configure the /opt hierarchy in it search path by default. I put the mailman, qcluster, and gunicorn (if you use that instead of uwsgi) .service files in /usr/local/lib/systemd/system, and that works for me. Flotsam and jetsam If you have run Mailman with any success at all, you may find some stuff in Debian's $var_dir/queue/* directories or in its $var_dir/lists/* directories. The queue/* directories contain incoming messages at various stages of processing, and the lists/* directories contain files containing multiple messages that are scheduled to be sent out as digests. You can read the queue files with `mailman qfile /path/to/queue/file.pck`, and the digests are just text files. That way you can check if there's anything important in them. If not, you can just delete them. If there is, you can just copy them to the same place in the venv $var_dir as they were in Debian's $var_dir, but you may want to ask here first before doing that. It's best to let Mailman run until all the queues are cleared (except maybe bad and shunt, but if those have any files in them you need to intervene anyway). Afterword I'm sure this sounds complicated, but in fact it's a pretty short list. When you get there we'll help you. Footnotes: [1] But not for this list. You may as well ask here, somebody probably will tell you the basics quickly. But for troubleshooting, go the the RDBMS's own channels. [2] In fact, it is possible to keep the Debian installation, copy the the mailman.cfg somewhere, edit it, stop Debian Mailman, and start up the venv Mailman. I don't recommend this -- the point is that the venv and the databases are that isolated from the rest of the system.

2 years, 8 months

Re: Importing config and archives only partially succeeded?

by Eric Broens

Thanks for your prompt reply.To import the config and archives I ran the commands as outlined in Migrating from Mailman 2.1 to Mailman 3 — Mailman Suite 3.3 documentation : mailman import21 foo-list(a)example.com /path/to/mailman2/foo-list/config.pck python manage.py hyperkitty_import -l foo-list(a)example.com $var_prefix/archives/private/foo-list.mbox/foo-list.mbox After running these commands the archives became available for most of the mailinglists. I didn't run the Django admin command with arguments "update_index_one_list" to build the indices for each mailinglist seperately. After everything was imported, and I noticed that the mails were not shown in the archives for half of the mailinglists, I ran "manage.py update_index" to index the mails for all mailinglists.This command is still running for hours.Since it builds the search index, I don't expect that this would make the mails available on the webpage. Best regards,Eric On Sunday, December 13, 2020, 12:12:46 AM GMT+1, Mark Sapiro <mark(a)msapiro.net> wrote: On 12/12/20 2:33 PM, Eric Broens via Mailman-users wrote: > Today I have migrated about 30 mailinglists from mailman 2.1 to mailman 3.3.2 & Hyperkitty 1.3.3. > Although no error responses were given when importing the 2.1 pck files, and neither for importing the archives, for about half of the mailinglists the hyperkitty webpage doesn't show any subscribers, nor archived emails. > The imported members and other settings are correctly shown in the postorius page. > Is there anything that I can verify why the archive is not shown on the hyperkitty page?The hyperkitty_email database table does contain the emails. Did you specify --no-sync-mailman when you ran hyperkitty_import? If so did you run the django sync_mailman job when you finished importing? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan _______________________________________________ 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, 6 months

Re: Setting for archiving multi email domains?

by Duane Raymond

Thanks! So - I've documented what I did below. Now that I am getting bouces, I got an email that said "The response from the remote server was: 550 5.1.1 <test(a)emaildomainA.com>: Recipient address rejected: User unknown in virtual alias table" Specifically to some ot the questions above: > What do you mean by "set"? That the list has archiving enabled? Yes. I meant that archiving had been enabled for the test(a)emaildomainA.com test list. Shunting error: I think the shunting error is a distraction if it is caused by not having a recipient. Early tests to the test list had me as an administrator, but not as a member - so this would have caused that. Once I added myself (before I sent the original message in this thread), the result (not sending the message to the list using a 'virtual' domain and not archiving it) continued. Virtual Domains: So based on the Postfix virtual domain documentation and the Mailman3 specific "Unusual Postfix configuration' section, I added the following to my postfix main.cf file: virtual_alias_domains = emaillistA.com emaillistB.com virtual_alias_maps = hash:/opt/mailman/mm/var/data/postfix_vmap and removed those domains from the 'mydestination' setting. I then created the postfix_vmap file and added to it: emaillistA.com DOMAIN # emaillistB.com DOMAIN ...then ran postmap with the path and reloaded postfix. On testing I also noticed that a previous counce was to emaildomainC.com - an alias for emaildomainA.com I had originally setup in the Postorius domain setup and then removed. I guessed that it was still in the postfix config, so I double checked in the MM generated postfix_domains file and ran postmap /path-to/postfix_domains and reloaded postfix again...and sent another test message.... This then generated the error email at the top from my email client (gmail). ...but the end result is no email sent and thus the reason there is no archive.... Any further suggestions? I can supply other log messages and configuration options if it helps. Duane

5 years, 3 months

Re: Template path

by Seth Seeger

> On Sep 19, 2020, at 3:02 PM, Abhilash Raj <maxking(a)asynchronous.in> wrote: > > Are you using the provided docker-compose file or are you using something else like Kubernetes to deploy the container images? I am using the provided docker-compose file. > It seems like your mailman-core container isn't able to talk to Postorius on the default dns name, mailman-web, in the provided docker-compose file. These dns names are setup by default if you are using the docker-compose.yaml provided with the repo, but would otherwise needs either changing the value of POSTORIUS_TEMPLATES_BASE_URL or manually setting up the mailman-web DNS in the `/etc/host` of the mailman-core container. Telnet isn’t included in the container, so I tested with curl: $ sudo docker exec -it -u mailman mailman-core bash bash-5.0$ grep mailman-web /etc/hosts bash-5.0$ curl http://mailman-web:8000 bash-5.0$ mailman-web does not seem to be in /etc/hosts of mailman-core, but it does resolve and port 8000 is reachable. (I tested with a bad hostname and a different port and did get error messages.) Is there a URL I can pull that will show that it’s working properly? My original (slightly censored) docker-compose.yaml file is below. Thanks, Seth version: '2' services: mailman-core: image: maxking/mailman-core:latest container_name: mailman-core hostname: mailman-core restart: always volumes: - /opt/mailman/core:/opt/mailman/ #stop_grace_period: 30s links: - database:database depends_on: - database environment: - DATABASE_URL=postgres://xxx:xxx@database/mailmandb - DATABASE_TYPE=postgres - DATABASE_CLASS=mailman.database.postgresql.PostgreSQLDatabase - HYPERKITTY_API_KEY=xxxxxx networks: mailman: ipv4_address: 172.19.199.2 mailman-web: image: maxking/mailman-web:latest container_name: mailman-web hostname: mailman-web restart: always depends_on: - database links: - mailman-core:mailman-core - database:database volumes: - /opt/mailman/web:/opt/mailman-web-data environment: - DATABASE_TYPE=postgres - DATABASE_URL=postgres://xxx:xxx@database/mailmandb - HYPERKITTY_API_KEY=xxxx - SERVE_FROM_DOMAIN=lists.example.com - DJANGO_ALLOWED_HOSTS=lists.example2.com - MAILMAN_ADMIN_USER=xxx - MAILMAN_ADMIN_EMAIL=xxx@xxxx - SECRET_KEY=xxxxxx networks: mailman: ipv4_address: 172.19.199.3 database: environment: POSTGRES_DB: mailmandb POSTGRES_USER: xxx POSTGRES_PASSWORD: xxx restart: always image: postgres:9.6-alpine volumes: - /opt/mailman/database:/var/lib/postgresql/data networks: mailman: ipv4_address: 172.19.199.4 networks: mailman: driver: bridge ipam: driver: default config: - subnet: 172.19.199.0/24

5 years, 9 months

Re: getting all registered users and their lists

by Mark Sapiro

On 1/26/22 00:16, IOhannes m zmoelnig wrote: > > hi, > > TL;DR > is there a scriptable way to get all users that have registered in my > mailman3 (3.2.1) instance and which lists they are subscribed to (if any)? It's in Postorius >= 1.3.6 > longer version: > > we are running Mailman3-3.2.1 as shipped with Debian/buster (i know that > this is not the newest version; at this point, please refrain from > asking me to upgrade my Debian installation or even to switch to a venv > installation of mailman3: i'll eventually do that but right now i've gt > a problem to solve :-)) See above. ... > for this i would like to get a listing of all users that are not > subscribed to any mailinglist. > i would also like to query, when a given user has signed up (so i can > reduce the number of false positives) > > how would i do that? > ideally i would rather not work on an SQL level. You can do this in mailman shell ``` $ bin/mailman shell Welcome to the GNU Mailman shell Use commit() to commit changes. Use abort() to discard changes since the last commit. Exit with ctrl+D does an implicit commit() but exit() does not. >>> um = getUtility(IUserManager) >>> for usr in um.users: ... if len(list(usr.memberships.members)) > 0: ... continue ... adr = usr.addresses[0] ... print(f'Name: {adr.display_name}, Email: {adr.email}, Created: {usr.created_on}') ... ``` Or to skip older ones ``` >>> from datetime import datetime >>> um = getUtility(IUserManager) >>> for usr in um.users: ... if len(list(usr.memberships.members)) > 0: ... continue ... if usr.created_on < datetime(2022, 1, 1): ... continue ... adr = usr.addresses[0] ... print(f'Name: {adr.display_name}, Email: {adr.email}, Created: {usr.created_on}') ... ``` -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 4 months

Re: Programmatic Creation of Users

by Mark Sapiro

On 7/30/22 05:25, jciesla(a)techsupportme.com wrote: > > After a lot of research I now understand that what I am doing in the Core Shell is creating a User entity which has one or more email addresses as well as one or more roles and preferences that exist at the global level. This user entity can Subscribe to zero or more lists. If I am incorrect in the summation please let me know! Almost correct. A User does have preferences but does not have roles. Roles are associated with list memberships, not users. > Assuming that the previous information is correct that brings us to my current dilemma. Specifically, the User entity can Subscribe and interact with lists using the email commands, but they can't Login using the Postorius web interface. If I understand correctly the reason that they can't login is that the underlying Django system does not recognize their account because the account that was created in Core isn't accessible by Django. Instead the user needs to create a Django-specific account at which point the information from Core becomes available in the user's web UI. The simple view is that Django users and Mailman Users are unrelated. Either can exist without the other. They only tie together if they have the same email address. That is the only connection between them. > If that is in fact accurate then I want to take the next logical leap: is it possible to programmatically create an account in Django that is tied to the account that was created in Core? See the script at https://www.msapiro.net/scripts/clean_users.py. This is an example that deals with Django users and Mailman Users and deletes some Django users. See https://docs.djangoproject.com/en/4.0/topics/db/queries/#creating-objects for information about creating objects. Also see the UserManager class in django/contrib/auth/models.py -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 10 months

Re: Python 3.13 compatibility

by Stephen J. Turnbull

Thomas Ward via Mailman-users writes: > Would it be preferred to have a section for "Install from Git > Master" or a "Install development branch" section under > Installation that addresses this?� If so I can work to edit the > site docs to make such sections. I appreciate the thought, but I don't think it's useful in the general audience documentation. Installing from HEAD is always risky, especially for people using LTS distributions. The Django situation is always fraught. Putting that recipe as is in the developer docs also doesn't make that much sense to me, as developers are expected to have full clones of the components they're working on. On the other hand something that points at the dev's local repos of the Mailman Suite components does make a lot of sense to me. Then you can add a note that "if you're only interested in some of the components, you can automatically get HEAD installations by substituting "https://gitlab.com/mailman/" for your "/path/to/local/repos/" in the `pip` commands for the rest. That makes sense to me because it means you don't have to keep a local mailmanclient clone up-to-date just to work on Postorius. And exercise for the reader: you can get your buddy's django-mailman3 hacks the same way. What do y'all think? Oh, yeah, probably ought to check the requirements.txt DAG to order the pip commands so that you're not overwriting PyPI versions with git master HEAD versions all the time. Steve > On 2026-03-30 07:39, Thomas Krichel wrote: > > pip install git+https://gitlab.com/mailman/mailman@master git+https://gitlab.com/mailman/mailmanclient@master git+https://gitlab.com/mailman/mailman-hyperkitty@master git+https://gitlab.com/mailman/hyperkitty@master git+https://gitlab.com/mailman/django-mailman3@master git+https://gitlab.com/mailman/postorius@master git+https://gitlab.com/mailman/mailman-web@master -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

2 months, 3 weeks

Re: Add domain to Mailman, can't create list with that new domain

by Odhiambo Washington

On Thu, Oct 17, 2024 at 5:32 PM Andy Matthews <andy.matthews(a)zaxiom.com> wrote: > I'm testing locally to try and support additional domains. > > I can add new mailing lists with a domain: announce-123(a)mydomain.com > I can't add a new mailing list with an alternate domain: > announce-123(a)testing.com > > Following the documentation for domains I'm able to successfully add the > new domain (locally) with the following steps: > > https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/model/docs… > > 1. Shell into the mailman server > 2. Shell into the mailman Python environment: mailman shell > 3. Add a new mailing list. > from mailman.interfaces.domain import IDomainManager > from zope.component import getUtility > manager = getUtility(IDomainManager) > manager.add('testing.com') > show_domains() # with method from the above documentation URL > <Domain testing.com> > <Domain mydomain.com> > > But then when I run a cURL command (from the mailman server) to add a list > with that new domain I get an error: > $ curl -k -u restadmin:restpass -X POST -H "Content-Type: > application/json" --data '{"fqdn_listname": "new-list(a)testing.com"}' > https://0.0.0.0:8001/3.1/lists > {"title": "400 Bad Request", "description": "Domain does not exist: > testing.com"} > > Am I doing something wrong, or missing a step? If not, how do I add > support for additional domains such that I can provide mailing list support > for that domain? > I am not sure I understand your question. Do you use Postorius and you can't add new domains from there? -- 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, 8 months

Affinity Mailman Is Now Beta

by Brian Carpenter

Dear Mailman Admins and Users, Affinity Mailman is our new admin interface for Mailman 3 and we intend to use it to replace Postorius. It has been under development for about 3 months now and it recently reached beta. Calling For Beta Testers Now that Affinity is in beta, we are looking for list admins to help us beta test it. We are interested in getting some feedback and feature requests from beta users. If you are interested in helping us test out Affinity and get a sneak peek of the future of Mailman administration, then email me at brian_carpenter(a)emwd.com <mailto:brian_carpenter@emwd.com?subject=Affinity%20Beta&body=I%20am%20interested%20in%20Beta%20Testing%20Affinity> and I will begin the process of setting you up with an Affinity Mailman admin account and provide 2 test lists to use for beta testing purposes. While I am at it: Empathy Is Now Under Development "So what in the world is Empathy? I mean really - first Affinity and now Empathy?" That is correct. We figured if we are going to replace the default admin UI (Postorius) for Mailman 3, we might as well replace the default forum/archive UI (Hyperkitty) for Mailman 3. With Empathy, we are bringing a beautiful and user-friendly experience for those who wish to use Mailman 3 as a modern forum. We want Empathy to bring a true community like approach to the use of Mailman 3 via a browser. It will supplement the mailing list feature of Mailman 3 with an easy to use online forum. So Mailman 3 users will get the best of both worlds: a modern mailing list app AND a modern forum app. Empathy can also be used to display your list threads (archives) in an easy-to-read manner, and those threads can be categorized by tags and will be searchable. -- 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/

6 years

Mailman-users search results for query "Postorius"