Search results for "Postorius" - Mailman-users

Re: Trying to configure a list (hosted)

by Abhilash Raj

On Sat, Aug 31, 2019, at 7:05 PM, paul(a)arenson.org wrote: > Thank you for the very quick response, Abhilash Raj. Being non > technical (and therefore opting for hosted Mailman 3), I can partly > understand your kind response. > > 1) I can understand that I cannot disable the different ways to sign up. > > 2) I am still struggling to understand the difference between the two > web choices as shown here. > > WAY # 1 TO GET AN ACCOUNT > https://list.tokyoprogressive.org/accounts/signup/?next=%2Fpostorius%2Flist… > > VS > > WAY # 2 YOU CAN GET AN ACCOUNT WITHOUT SIGNING UP > at the bottom of > https://list.tokyoprogressive.org/postorius/lists/discuss.list.tokyoprogres… > > (I was under the impression making only WAY #1 allows one to post, but > are you saying that the bottom option also allows one to post, but only > by email?) That's right. Mailman is a mailing list manager and is primarily based around discussions using Emails. You can subscribe to mailing lists and send email to the list address, which then gets distributed to all the members. All the emails sent to the mailing lists are also archived usually in an archiver. The official archiver, a.k.a the one supported by us, also additionally supports posting to the mailing list via the Web interface. If anyone wants to use the web ui to post, they need to have an account and need to verify that they own the email address they are signing up with. Then, anything they post is sent as an email, on their behalf, to the mailing list and that's how you can get 2 ways to post. You don't need any account on the web interface if all you want is to post through email. > If I am confused, I know my users will also be confused. I think I > understand I can qualify their subscription in the ways you suggest: > "Confirm where all users would have to confirm their subscription using > an email sent to them. Optionally, you can also enable moderation where > each subscription needs explicit approval too." > > So to put it simply: > > 1) I want to make it a discussion list. Not available to people who are > not signed up? It is slightly confusing, but let's separate sign-up into two terms and let me know if that is still confusing, "sign up to web interface", "subscribe to mailing list". - sign up to web interface: This is optional. This allows you, as an administrator to operate the mailing list and it's configuration. A user can sign up to the web interface and manage all the subscriptions they have, and also subscribe to mailing lists. - subscribe to mailing list: This is a user participating in a Mailing List. For this, they don't necessarily need to sign up via web interface as there are other ways to subscribe to a mailing list, like anonymous subscribe (which is your #2 above). Once they are subscribed, they are called "subscribers". Users will always have to "subscribe" before they can participate on a mailing list. There is currently no way to mandate "sign up on the web interface" for all "subscribers". > > 2) This is dependent on all having access to the archives so they can > see what they are responding to If the archives are set to be private, only the "subscribers" can view the archives. > > 3) What settings do I make to insure that all who sign up via WAY #1 > can see the archives and post. You have to set the archives to be private and that's all. You can do that from: List -> Settings -> Archiving Options on that page should be self-explanatory > > 4) What settings do I make to insure that all who sign up via way #2 > can do the same? They will receive emails and will be able to reply to them. If they want to post via the web interface, they will have to create an account and sign up, same as #1. > > Last, in my account settings what is the difference between a member > and a non member? "non-members" are people Mailman remembers who interacted with a MailingList in past. For example, I can ask an list owner to let my post through, without actually subscribing(because I don't want to get all the emails, just send a single email) by allowing me to be a "non-member" who is allowed to post. > > Thanks and sorry I was not clear the first time. > _______________________________________________ > Mailman-users mailing list -- mailman-users(a)mailman3.org > To unsubscribe send an email to mailman-users-leave(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > -- thanks, Abhilash Raj (maxking)

6 years, 4 months

Re: Hyperkitty CPU usage

by Alain Kohli

Well, I understand that it might take a while, but the process is running for over 200h now, I doubt it can really take _that_ long if everything is working properly. Especially because the rebuild_index command is only taking a few hours at most, doesn't that essentially do the same? We have ~700k messages in ~300 mailing lists in case that helps you estimate how long it could take. I can take a look at alternative backends, though. On 5/7/19 4:32 PM, Abhilash Raj wrote: > On Sat, Apr 27, 2019, at 6:22 PM, Alain Kohli wrote: >> I'm running a custom image which is based on an older version of the one >> here: https://github.com/maxking/docker-mailman. I attached it below. >> But I separated postorius and hyperkitty, so hyperkitty is running in >> its own container. I'm deploying the image with a plain 'docker run' >> behind nginx. I made fulltext_index persistent now, but it didn't get >> populated with anything yet. I don't really have an error traceback >> because there is never an error thrown. The only thing with some content >> is uwsgi-error.log, which you can find below. I'm also still getting the >> "A string literal cannot contain NUL (0x00) characters." messages. I >> also noticed that it takes incredibly long for the webinterface to load >> (several minutes) even though there doesn't seem to be any process >> consuming notable resources apart from the minutely job. >> >> Funnily enough, I have the exact same image deployed on a second server >> as well for testing. On that one everything works fine. The only >> difference is that on the problematic one I have a lot more mailing >> lists/archives and that I imported them from mailman2. Could something >> have gone wrong during the import? I used the regular hyperkitty_import >> command. > Yes, this is because `whoosh`, the library set by default to run fulltext > indexing is a pure python implementation and quite slow in busy lists. > > We do support more backends though, see [1] for a list of all the supported > search backends. Something like Xapian(C++) or Elasticsearch/Solr(Java) > should be much better in terms of performance. > > [1]: https://django-haystack.readthedocs.io/en/master/backend_support.html > >> uwsgi-error.log: >> >> *** Starting uWSGI 2.0.18 (64bit) on [Sat Apr 27 22:50:17 2019] *** >> compiled with version: 6.4.0 on 27 April 2019 22:48:42 >> os: Linux-4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) >> nodename: hyperkitty.docker >> machine: x86_64 >> clock source: unix >> detected number of CPU cores: 4 >> current working directory: /home/hyperkitty >> detected binary path: /usr/local/bin/uwsgi >> !!! no internal routing support, rebuild with pcre support !!! >> setgid() to 82 >> setuid() to 82 >> chdir() to /home/hyperkitty >> your memory page size is 4096 bytes >> detected max file descriptor number: 1048576 >> lock engine: pthread robust mutexes >> thunder lock: disabled (you can enable it with --thunder-lock) >> uwsgi socket 0 bound to TCP address 0.0.0.0:8081 fd 8 >> uwsgi socket 1 bound to TCP address 0.0.0.0:8080 fd 9 >> Python version: 3.6.8 (default, Jan 30 2019, 23:54:38) [GCC 6.4.0] >> Python main interpreter initialized at 0x55dfaa41c980 >> python threads support enabled >> your server socket listen backlog is limited to 100 connections >> your mercy for graceful operations on workers is 60 seconds >> [uwsgi-cron] command "./manage.py runjobs minutely" registered as >> cron task >> [uwsgi-cron] command "./manage.py runjobs quarter_hourly" registered >> as cron task >> [uwsgi-cron] command "./manage.py runjobs hourly" registered as cron >> task >> [uwsgi-cron] command "./manage.py runjobs daily" registered as cron task >> [uwsgi-cron] command "./manage.py runjobs monthly" registered as >> cron task >> [uwsgi-cron] command "./manage.py runjobs weekly" registered as cron >> task >> [uwsgi-cron] command "./manage.py runjobs yearly" registered as cron >> task >> mapped 208576 bytes (203 KB) for 4 cores >> *** Operational MODE: threaded *** >> WSGI app 0 (mountpoint='') ready in 1 seconds on interpreter >> 0x55dfaa41c980 pid: 1 (default app) >> *** uWSGI is running in multiple interpreter mode *** >> spawned uWSGI master process (pid: 1) >> spawned uWSGI worker 1 (pid: 40, cores: 4) >> Sat Apr 27 22:50:18 2019 - [uwsgi-cron] running "./manage.py runjobs >> minutely" (pid 45) >> [uwsgi-daemons] spawning "./manage.py qcluster" (uid: 82 gid: 82) >> 22:50:21 [Q] INFO Q Cluster-47 starting. >> 22:50:21 [Q] INFO Process-1:1 ready for work at 59 >> 22:50:21 [Q] INFO Process-1:2 ready for work at 60 >> 22:50:21 [Q] INFO Process-1:3 ready for work at 61 >> 22:50:21 [Q] INFO Process-1:4 ready for work at 62 >> 22:50:21 [Q] INFO Process-1:5 monitoring at 63 >> 22:50:21 [Q] INFO Process-1 guarding cluster at 58 >> 22:50:21 [Q] INFO Process-1:6 pushing tasks at 64 >> 22:50:21 [Q] INFO Q Cluster-47 running. >> 22:59:31 [Q] INFO Enqueued 3403 >> 22:59:31 [Q] INFO Process-1:1 processing [update_from_mailman] >> 22:59:33 [Q] INFO Processed [update_from_mailman] >> Sat Apr 27 23:00:00 2019 - [uwsgi-cron] running "./manage.py runjobs >> quarter_hourly" (pid 73) >> Sat Apr 27 23:00:00 2019 - [uwsgi-cron] running "./manage.py runjobs >> hourly" (pid 74) >> [uwsgi-cron] command "./manage.py runjobs quarter_hourly" running >> with pid 73 exited after 64 second(s) >> 23:01:28 [Q] INFO Enqueued 3404 >> 23:01:29 [Q] INFO Process-1:2 processing >> [rebuild_mailinglist_cache_recent] >> [uwsgi-cron] command "./manage.py runjobs hourly" running with pid >> 74 exited after 91 second(s) >> Sat Apr 27 23:01:36 2019 - uwsgi_response_write_body_do(): Broken >> pipe [core/writer.c line 341] during GET / (212.203.58.154) >> OSError: write error >> 23:01:36 [Q] INFO Processed [rebuild_mailinglist_cache_recent] >> Sat Apr 27 23:15:00 2019 - [uwsgi-cron] running "./manage.py runjobs >> quarter_hourly" (pid 88) >> [uwsgi-cron] command "./manage.py runjobs quarter_hourly" running >> with pid 88 exited after 4 second(s) >> 23:28:24 [Q] INFO Enqueued 3405 >> 23:28:24 [Q] INFO Process-1:3 processing [update_from_mailman] >> 23:28:25 [Q] INFO Processed [update_from_mailman] >> Sat Apr 27 23:30:00 2019 - [uwsgi-cron] running "./manage.py runjobs >> quarter_hourly" (pid 96) >> [uwsgi-cron] command "./manage.py runjobs quarter_hourly" running >> with pid 96 exited after 4 second(s) >> 23:44:40 [Q] INFO Enqueued 3406 >> 23:44:40 [Q] INFO Process-1:4 processing [update_from_mailman] >> 23:44:41 [Q] INFO Processed [update_from_mailman] >> Sat Apr 27 23:45:00 2019 - [uwsgi-cron] running "./manage.py runjobs >> quarter_hourly" (pid 104) >> [uwsgi-cron] command "./manage.py runjobs quarter_hourly" running >> with pid 104 exited after 4 second(s) >> Sun Apr 28 00:00:00 2019 - [uwsgi-cron] running "./manage.py runjobs >> quarter_hourly" (pid 113) >> Sun Apr 28 00:00:00 2019 - [uwsgi-cron] running "./manage.py runjobs >> hourly" (pid 114) >> Sun Apr 28 00:00:00 2019 - [uwsgi-cron] running "./manage.py runjobs >> daily" (pid 115) >> Sun Apr 28 00:00:00 2019 - [uwsgi-cron] running "./manage.py runjobs >> weekly" (pid 116) >> [uwsgi-cron] command "./manage.py runjobs quarter_hourly" running >> with pid 113 exited after 55 second(s) >> [uwsgi-cron] command "./manage.py runjobs weekly" running with pid >> 116 exited after 55 second(s) >> 00:01:36 [Q] INFO Enqueued 3407 >> 00:01:36 [Q] INFO Process-1:1 processing >> [rebuild_mailinglist_cache_recent] >> [uwsgi-cron] command "./manage.py runjobs hourly" running with pid >> 114 exited after 99 second(s) >> 00:01:50 [Q] INFO Processed [rebuild_mailinglist_cache_recent] >> 00:04:52 [Q] INFO Enqueued 3408 >> 00:04:52 [Q] INFO Process-1:2 processing [update_from_mailman] >> 00:04:54 [Q] INFO Processed [update_from_mailman] >> >> Dockerfile: >> >> FROM python:3.6-alpine3.7 # Add startup script to container COPY >> assets/docker-entrypoint.sh /usr/local/bin/ # Install packages and >> dependencies for hyperkitty and add user for executing apps. # It's >> important that the user has the UID/GID 82 so nginx can access the >> files. RUN set -ex \&& apk add --no-cache --virtual .build-deps gcc >> libc-dev linux-headers git \postgresql-dev \&& apk add --no-cache >> --virtual .mailman-rundeps bash sassc mailcap \postgresql-client >> curl \&& pip install -U django==2.2 \&& pip install >> git+https://gitlab.com/eestec/mailmanclient >> >> \git+https://gitlab.com/mailman/hyperkitty@c9fa4d4bfc295438d3e01cd93090064d004cf44d >> \git+https://gitlab.com/eestec/django-mailman3 \whoosh \uwsgi >> \psycopg2 \dj-database-url \typing \&& apk del .build-deps \&& >> addgroup -S -g 82 hyperkitty \&& adduser -S -u 82 -G hyperkitty >> hyperkitty \&& chmod u+x /usr/local/bin/docker-entrypoint.sh# Add >> needed files for uwsgi server + settings for django COPY >> assets/__init__.py /home/hyperkittyCOPY assets/manage.py >> /home/hyperkittyCOPY assets/urls.py /home/hyperkittyCOPY >> assets/wsgi.py /home/hyperkittyCOPY assets/uwsgi.ini >> /home/hyperkittyCOPY assets/settings.py /home/hyperkitty# Change >> ownership for uwsgi+django files and set execution rights for >> management script RUN chown -R hyperkitty /home/hyperkitty && chmod >> u+x /home/hyperkitty/manage.py# Make sure we are in the correct >> working dir WORKDIR /home/hyperkittyEXPOSE 8080 8081# Use stop >> signal for uwsgi server STOPSIGNAL SIGINTENTRYPOINT >> ["docker-entrypoint.sh"]CMD ["uwsgi", "--ini", >> "/home/hyperkitty/uwsgi.ini"] >> >> On 4/27/19 7:58 PM, Abhilash Raj wrote: >>> On Sat, Apr 27, 2019, at 9:40 AM, Alain Kohli wrote: >>>> I have run "python manage.py rebuild_index" before, doesn't that do >>>> clear_index as well? Apart from that, I run hyperkitty in a docker >>>> container and didn't know fulltext_index should be persistent, so that >>>> got deleted after every version update for sure. >>> Which images are you using and how are you deploying them? >>> >>> You should persist fulltext_index, yes, and possibly logs if you need >>> them for debugging later. >>> >>> Can you paste the entire error traceback? >>> >>>> On 4/26/19 10:18 PM, Mark Sapiro wrote: >>>>> On 4/26/19 11:14 AM, Alain Kohli wrote: >>>>>> I see loads of "A string literal cannot contain NUL (0x00) characters." >>>>>> messages, but I haven't found missing messages in the archives yet. Not >>>>>> sure how that could be related, though. Apart from that I don't see >>>>>> anything unusual. The other jobs (quarter_hourly, hourly, etc.) seem to >>>>>> run and finish normally. >>>>> Did you upgrade from a Python 2.7 version of HyperKitty to a Python 3 >>>>> version? The Haystack/Whoosh search engine databases are not compatible >>>>> between the two and "A string literal cannot contain NUL (0x00) >>>>> characters." is the symptom. >>>>> >>>>> You need to run 'python manage.py clear_index' or just remove all the >>>>> files from the directory defined as 'PATH' under HAYSTACK_CONNECTIONS in >>>>> your settings file (normally 'fulltext_index' in the same directory that >>>>> contains your settings.py. >>>>> >>>> _______________________________________________ >>>> 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/ >>>> >> _______________________________________________ >> 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/ >>

6 years, 8 months

Re: config incoming email in my domain cpanel

by tlhackque

You've said you're working with labbrands.com. labbrands.com has address 192.185.51.89 mail.labbrands.com has address 192.185.51.89 www.labbrands.com is an alias for labbrands.com. telnet proves that Exim is running on that IP address. Either you're running it, or hostgator is redirecting the SMTP ports. You added: lists.labbrands.com has address 190.145.27.66 Presumably that's a different machine. So that now needs an MX record, and a firewall routing. And the SPF records ... and spam and virus filters, and all the other stuff you need to setup an independent, public-facing smtp server. But at least you won't have to relay. Good luck. On 03-Aug-17 16:55, Rafael Mora wrote: > El jue., 3 ago. 2017 a las 15:49, tlhackque via Mailman-users (< > mailman-users(a)mailman3.org>) escribió: > >> I think you're confused. >> >> You already have mail.labbrands.com set up as the MX record for >> labbrands.com. And it has an A record with the same address as your >> webserver. >> > I'm working with the hostgator mailserver, we are not running a local > mailserver. > > As suggested I added an A record like this: > [image: image.png] > > Is it correct? is it redirecting to my Ip so I can redirect it to my > postfix/mm3 server? > > >> So if you're getting e-mail on that domain, there's another e-mail >> server running on that IP address. You can't have 2 servers on port >> 25. In that case, as has been noted before, you'll need to setup a >> relay in that server, not a firewall redirect. Depending on your MTA, >> you would need to relay to your internal server. And make sure your >> firewall setup allows your MTA to do this. >> >> We can see it's EXIM: >> >> telnet mail.labbrands.com 25 >> Trying 192.185.51.89... >> Connected to mail.labbrands.com (192.185.51.89). >> Escape character is '^]'. >> help >> 220-gator4137.hostgator.com ESMTP Exim 4.87 #1 Thu, 03 Aug 2017 15:47:48 >> -0500 >> 220-We do not authorize the use of this system to transport unsolicited, >> 220 and/or bulk e-mail. >> 214-Commands supported: >> 214 AUTH STARTTLS HELO EHLO MAIL RCPT DATA NOOP QUIT RSET HELP >> quit >> 221 gator4137.hostgator.com closing connection >> Connection closed by foreign host. >> >> Or, consolidate all your e-mail to one server - which is a lot easier to >> manage unless you have a really big operation. Postfix is probably the >> right choice, but requires more setup. >> >> Although Mailman3 configuration is not well documented (as you've >> discovered), you may want to get help from someone with more general >> network and mail experience. You're now into territory that is, as >> Simon indicated, not Mailman-specific. >> >> On 03-Aug-17 16:28, Rafael Mora wrote: >>> El jue., 3 ago. 2017 a las 15:26, Mark Sapiro (<mark(a)msapiro.net>) >> escribió: >>>> On 08/03/2017 01:22 PM, Rafael Mora wrote: >>>>> El jue., 3 ago. 2017 a las 15:18, Mark Sapiro (<mark(a)msapiro.net>) >>>> escribió: >>>>>> You need to forward port 25 for SMTP mail delivery and if you want the >>>>>> web UI (Postorius and HyperKitty) accessible from the outside, port 80 >>>>>> for http and/or port 443 for https >>>>>> < >>>>>> >> https://www.iana.org/assignments/service-names-port-numbers/service-names-p… >>>>>>> . >>>>> I mean for incoming mail redirected from my hostgator hosting, because >>>> when >>>>> I suscribe an email address MM3 sends a confirmation email, so I have >> to >>>>> reply to be suscribed to the list. >>>> As I said, for mail delivery you need to forward port 25 to the Mailman >>>> server. >>>> >>> Ok so I'll redirect in my zentyal firewall the port 25 to my local >> centos7 >>> with postfix and MM3 with IP 192.168.1.42. Thanks Mark. >>> >>> >>>> -- >>>> 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 >>>> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ >>>> >> -- >> This communication may not represent my employer's views, >> if any, on the matters discussed. >> >> _______________________________________________ >> Mailman-users mailing list >> mailman-users(a)mailman3.org >> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ >> -- This communication may not represent my employer's views, if any, on the matters discussed.

8 years, 5 months

Migration from old server to new server failed

by Helio Loureiro

Hi, So we tried to the migration following the steps: - stop mailman in the old machine (v3.1.1 from ubuntu packages) - dump DB mailman3 and mailman3web - backup /var/lib/mailman3 content On the new machine: - checkout from git the version 3.1.1 to match production and install the services - stop mailman3 and mailman3-web on the new machine - load DBs into new machine - copy content from /var/lib/mailman3 into /local/mailman/var (which means: archives/ cache/ data/ ext/ lists/ locks/ messages/ public_suffix_list.dat queue/ templates/ web/) - start mailman3 and mailman-3web - run mailman3-web migrate And I stopped here. Because it crashed. (venv) mailman@new-mailman3-server ~ (v3.1.1) [0|SIGINT]> mailman-web migrate System check identified some issues: WARNINGS: account.EmailAddress: (models.W036) MariaDB does not support unique constraints with conditions. HINT: A constraint won't be created. Silence this warning if you don't care about it. account.EmailAddress: (models.W043) MariaDB does not support indexes on expressions. HINT: An index won't be created. Silence this warning if you don't care about it. Operations to perform: Apply all migrations: account, admin, auth, contenttypes, django_mailman3, django_q, hyperkitty, postorius, sessions, sites, socialaccount Running migrations: Applying account.0003_alter_emailaddress_create_unique_verified_email... OK Applying account.0004_alter_emailaddress_drop_unique_email... OK Applying account.0005_emailaddress_idx_upper_email... OK Applying admin.0003_logentry_add_action_flag_choices... OK Applying auth.0009_alter_user_last_name_max_length... OK Applying auth.0010_alter_group_name_max_length... OK Applying auth.0011_update_proxy_permissions... OK Applying auth.0012_alter_user_first_name_max_length... OK Applying django_mailman3.0003_sessions... OK Applying django_q.0010_auto_20200610_0856... OK Applying django_q.0011_auto_20200628_1055... OK Applying django_q.0012_auto_20200702_1608... OK Applying django_q.0013_task_attempt_count... OK Applying django_q.0014_schedule_cluster... OK Applying hyperkitty.0016_auto_20180309_0056... OK Applying hyperkitty.0017_file_attachments... OK Applying hyperkitty.0018_threadcategory_color... OK Applying hyperkitty.0019_auto_20190127_null_description... OK Applying hyperkitty.0020_auto_20190907_1927... OK Applying hyperkitty.0021_add_owners_mods...Traceback (most recent call last): File "/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/utils.py", line 87, in _execute return self.cursor.execute(sql) File "/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/mysql/base.py", line 75, in execute return self.cursor.execute(query, args) File "/local/mailman/venv/lib/python3.10/site-packages/MySQLdb/cursors.py", line 179, in execute res = self._query(mogrified_query) File "/local/mailman/venv/lib/python3.10/site-packages/MySQLdb/cursors.py", line 330, in _query db.query(q) File "/local/mailman/venv/lib/python3.10/site-packages/MySQLdb/connections.py", line 261, in query _mysql.connection.query(self, query) MySQLdb.OperationalError: (1050, "Table 'hyperkitty_mailinglist_moderators' already exists") The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/local/mailman/venv/bin/mailman-web", line 8, in <module> sys.exit(main()) File "/local/mailman/venv/lib/python3.10/site-packages/mailman_web/manage.py", line 90, in main execute_from_command_line(sys.argv) File "/local/mailman/venv/lib/python3.10/site-packages/django/core/management/__init__.py", line 446, in execute_from_command_line utility.execute() File "/local/mailman/venv/lib/python3.10/site-packages/django/core/management/__init__.py", line 440, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/local/mailman/venv/lib/python3.10/site-packages/django/core/management/base.py", line 402, in run_from_argv self.execute(*args, **cmd_options) File "/local/mailman/venv/lib/python3.10/site-packages/django/core/management/base.py", line 448, in execute output = self.handle(*args, **options) File "/local/mailman/venv/lib/python3.10/site-packages/django/core/management/base.py", line 96, in wrapped res = handle_func(*args, **kwargs) File "/local/mailman/venv/lib/python3.10/site-packages/django/core/management/commands/migrate.py", line 349, in handle post_migrate_state = executor.migrate( File "/local/mailman/venv/lib/python3.10/site-packages/django/db/migrations/executor.py", line 135, in migrate state = self._migrate_all_forwards( File "/local/mailman/venv/lib/python3.10/site-packages/django/db/migrations/executor.py", line 167, in _migrate_all_forwards state = self.apply_migration( File "/local/mailman/venv/lib/python3.10/site-packages/django/db/migrations/executor.py", line 252, in apply_migration state = migration.apply(state, schema_editor) File "/local/mailman/venv/lib/python3.10/site-packages/django/db/migrations/migration.py", line 130, in apply operation.database_forwards( File "/local/mailman/venv/lib/python3.10/site-packages/django/db/migrations/operations/fields.py", line 108, in database_forwards schema_editor.add_field( File "/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/mysql/schema.py", line 104, in add_field super().add_field(model, field) File "/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/base/schema.py", line 636, in add_field return self.create_model(field.remote_field.through) File "/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/base/schema.py", line 447, in create_model self.execute(sql, params or None) File "/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/base/schema.py", line 199, in execute cursor.execute(sql, params) File "/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/utils.py", line 67, in execute return self._execute_with_wrappers( File "/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/utils.py", line 80, in _execute_with_wrappers return executor(sql, params, many, context) File "/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/utils.py", line 84, in _execute with self.db.wrap_database_errors: File "/local/mailman/venv/lib/python3.10/site-packages/django/db/utils.py", line 91, in __exit__ raise dj_exc_value.with_traceback(traceback) from exc_value File "/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/utils.py", line 87, in _execute return self.cursor.execute(sql) File "/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/mysql/base.py", line 75, in execute return self.cursor.execute(query, args) File "/local/mailman/venv/lib/python3.10/site-packages/MySQLdb/cursors.py", line 179, in execute res = self._query(mogrified_query) File "/local/mailman/venv/lib/python3.10/site-packages/MySQLdb/cursors.py", line 330, in _query db.query(q) File "/local/mailman/venv/lib/python3.10/site-packages/MySQLdb/connections.py", line 261, in query _mysql.connection.query(self, query) django.db.utils.OperationalError: (1050, "Table 'hyperkitty_mailinglist_moderators' already exists") I tried to drop the table, but then it complained about another one. I dropped all the complained tables and as result hypperkitty never started. So I went back to see why the first error happened. Any clue what to do next? Best Regards, Helio Loureiro https://helio.loureiro.eng.br https://github.com/helioloureiro https://mastodon.social/@helioloureiro

1 year, 10 months

Time Stand Still

by Barry Warsaw

Somewhen in the dark recesses of intarweb history, I found myself as the project leader for both Jython (née JPython) and GNU Mailman. I'd been involved with Jython since it was invented by Jim Hugunin around the time he came to work with us at Pythonlabs. I'd been contributing to Mailman since we inherited John Viega's Python-based Dave Matthews Band list server, and put it to use replacing python.org's Majordomo installation. I'd enjoyed both projects, but knew I could not lead both, so I had to make a choice. I chose to turn over Jython to a team that's done a much better job over the years than I ever could have. Something about email, and especially the communication and collaboration patterns that it facilitates, really fascinated me. I know, I know, but we all have our lapses of sanity. Mine has lasted almost 20 years, a bit more than "momentary" perhaps. I've rarely gotten paid to work on Mailman, but it did provide me some great opportunities. Most notably it led to my 10 year stint at Canonical. I was originally hired on there to integrate mailing lists with Launchpad, and Mailman was the obvious choice. I learned a ton doing that project, and working within the constraints of integrating the two Python-based systems, especially since Launchpad was originally not free software and Mailman was GPL'd. Later, the Zope-based Launchpad source code was released under the AGPL, making much of the monkeypatching unnecessary, but by then the system was solid and reliable, and you don't fix what's not broken. Except, I guess I did. I took a lot of the lessons from that work, along with a good hard look at all the problems with Mailman 2, and began to break another cardinal rule of software development: second system syndrome. The result is Mailman 3. It took forever, and we're still not at complete feature parity with Mailman 2, but at least it's Real Enough to be used at many Real Sites, including python.org and lists.fedoraprojects.org. It would be ridiculous for me to take significant credit for this. I have to acknowledge the amazing user community -- you! -- for all the support, patches, suggestions, feedback, patience, criticism, donations, and contributions that you've given to the project, and to me personally over the years. And my deepest gratitude goes to all the core developers that have stayed or come and gone, but most especially the current Cabal: Abhilash Raj, Aurelien Bompard, Florian Fuchs, Mark Sapiro, Stephen J. Turnbull, Terri Oda. You should know that each and every one of them is truly awesome, both in what they contribute technically, and in their amazing friendships. Mailman is infinitely better because of their involvement, and I've loved spending time with them over the years at the Pycon sprints, making releases and sharing teas and meals. My blog is called We Fear Change, and that's humorously taken from a 90's bit in Mike Myer's excellent Wayne's World movie (a phrase actually uttered by the brilliant Dana Carvey as Garth). The irony of course is that while we all may fear change, it's the one constant thing we can count on. And in fact, we *require* change to thrive, because if you aren't changing, you aren't alive. Time, and being engaged with life's vagaries, means there's no alternative to change; it must be embraced. And so, with a vague reference to the many (good!) changes in my personal and professional life, I'm announcing that I'm stepping down from the project leadership role of GNU Mailman, effective... nowish! And it's with unanimous agreement among the GNU Mailman Steering Committee (a.k.a. the Mailman Cabal), that we are announcing Abhilash Raj as the new project leader. If you don't recognize Abhilash's name, you probably aren't paying attention, at least to Mailman 3. Abhilash came to us in 2013 as a Google Summer of Code student, and he's become one of the project's most valuable contributors. His list of accomplishments is long, and it includes everything from redesigning the website, to integrating CI with our GitLab build system, porting our code to the SQLAlchemy ORM, adding MySQL support, revving up adoption through his Docker images, along with his great coding work on Core, Postorius, HyperKitty, and mailmanclient. This transition is good for the project too. Email, its defining protocols and standards, and its role in our daily lives, has changed profoundly since the early days of Mailman. A fresh perspective and enthusiasm will help keep Mailman relevant to the changing ways we -- especially the FLOSS and tech communities -- communicate. Please join me in supporting Abhilash in every way possible as he takes over in this new role as project leader. I'll be here when and if needed, even as I create space in my "spare" time for... Something Else. I look forward to the vision that Abhilash will bring to the project, and I know that he will do a great job. To me, Mailman has always been about collaboration, and the best way for it to succeed is for you to continue to contribute your insights, experiences, opinions, and skills with positive intention. -Barry https://www.wefearchange.org/

8 years, 1 month

Badsignature on uwsgi-error.log

by Helio Loureiro

Hi, I keep receiving a lot of errors like this: --- Logging error --- Traceback (most recent call last): File "/local/mailman/venv/lib/python3.10/site-packages/django_q/cluster.py", line 356, in pusher task = SignedPackage.loads(task[1]) File "/local/mailman/venv/lib/python3.10/site-packages/django_q/signing.py", line 25, in loads return signing.loads( File "/local/mailman/venv/lib/python3.10/site-packages/django_q/core_signing.py", line 35, in loads base64d = force_bytes(TimestampSigner(key, salt=salt).unsign(s, max_age=max_age)) File "/local/mailman/venv/lib/python3.10/site-packages/django_q/core_signing.py", line 70, in unsign result = super(TimestampSigner, self).unsign(value) File "/local/mailman/venv/lib/python3.10/site-packages/django_q/core_signing.py", line 55, in unsign raise BadSignature('Signature "%s" does not match' % sig) django.core.signing.BadSignature: Signature "F6V0Dr_SvBsx5-cY8vcvLXrX8tA" does not match During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.10/logging/__init__.py", line 1100, in emit msg = self.format(record) File "/usr/lib/python3.10/logging/__init__.py", line 943, in format return fmt.format(record) File "/usr/lib/python3.10/logging/__init__.py", line 678, in format record.message = record.getMessage() File "/usr/lib/python3.10/logging/__init__.py", line 368, in getMessage msg = msg % self.args TypeError: not all arguments converted during string formatting Call stack: File "/local/mailman/venv/bin/mailman-web", line 8, in <module> sys.exit(main()) File "/local/mailman/venv/lib/python3.10/site-packages/mailman_web/manage.py", line 90, in main execute_from_command_line(sys.argv) File "/local/mailman/venv/lib/python3.10/site-packages/django/core/management/__init__.py", line 446, in execute_from_command_line utility.execute() File "/local/mailman/venv/lib/python3.10/site-packages/django/core/management/__init__.py", line 440, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/local/mailman/venv/lib/python3.10/site-packages/django/core/management/base.py", line 402, in run_from_argv self.execute(*args, **cmd_options) File "/local/mailman/venv/lib/python3.10/site-packages/django/core/management/base.py", line 448, in execute output = self.handle(*args, **options) File "/local/mailman/venv/lib/python3.10/site-packages/django_q/management/commands/qcluster.py", line 22, in handle q.start() File "/local/mailman/venv/lib/python3.10/site-packages/django_q/cluster.py", line 78, in start self.sentinel.start() File "/usr/lib/python3.10/multiprocessing/process.py", line 121, in start self._popen = self._Popen(self) File "/usr/lib/python3.10/multiprocessing/context.py", line 224, in _Popen return _default_context.get_context().Process._Popen(process_obj) File "/usr/lib/python3.10/multiprocessing/context.py", line 281, in _Popen return Popen(process_obj) File "/usr/lib/python3.10/multiprocessing/popen_fork.py", line 19, in __init__ self._launch(process_obj) File "/usr/lib/python3.10/multiprocessing/popen_fork.py", line 71, in _launch code = process_obj._bootstrap(parent_sentinel=child_r) File "/usr/lib/python3.10/multiprocessing/process.py", line 314, in _bootstrap self.run() File "/usr/lib/python3.10/multiprocessing/process.py", line 108, in run self._target(*self._args, **self._kwargs) File "/local/mailman/venv/lib/python3.10/site-packages/django_q/cluster.py", line 168, in __init__ self.start() File "/local/mailman/venv/lib/python3.10/site-packages/django_q/cluster.py", line 172, in start self.spawn_cluster() File "/local/mailman/venv/lib/python3.10/site-packages/django_q/cluster.py", line 248, in spawn_cluster self.pusher = self.spawn_pusher() File "/local/mailman/venv/lib/python3.10/site-packages/django_q/cluster.py", line 201, in spawn_pusher return self.spawn_process(pusher, self.task_queue, self.event_out, self.broker) File "/local/mailman/venv/lib/python3.10/site-packages/django_q/cluster.py", line 197, in spawn_process p.start() File "/usr/lib/python3.10/multiprocessing/process.py", line 121, in start self._popen = self._Popen(self) File "/usr/lib/python3.10/multiprocessing/context.py", line 224, in _Popen return _default_context.get_context().Process._Popen(process_obj) File "/usr/lib/python3.10/multiprocessing/context.py", line 281, in _Popen return Popen(process_obj) File "/usr/lib/python3.10/multiprocessing/popen_fork.py", line 19, in __init__ self._launch(process_obj) File "/usr/lib/python3.10/multiprocessing/popen_fork.py", line 71, in _launch code = process_obj._bootstrap(parent_sentinel=child_r) File "/usr/lib/python3.10/multiprocessing/process.py", line 314, in _bootstrap self.run() File "/usr/lib/python3.10/multiprocessing/process.py", line 108, in run self._target(*self._args, **self._kwargs) File "/local/mailman/venv/lib/python3.10/site-packages/django_q/cluster.py", line 358, in pusher logger.error(e, traceback.format_exc()) Message: BadSignature('Signature "F6V0Dr_SvBsx5-cY8vcvLXrX8tA" does not match') Arguments: ('Traceback (most recent call last):\n File "/local/mailman/venv/lib/python3.10/site-packages/django_q/cluster.py", line 356, in pusher\n task = SignedPackage.loads(task[1])\n File "/local/mailman/venv/lib/python3.10/site-packages/django_q/signing.py", line 25, in loads\n return signing.loads(\n File "/local/mailman/venv/lib/python3.10/site-packages/django_q/core_signing.py", line 35, in loads\n base64d = force_bytes(TimestampSigner(key, salt=salt).unsign(s, max_age=max_age))\n File "/local/mailman/venv/lib/python3.10/site-packages/django_q/core_signing.py", line 70, in unsign\n result = super(TimestampSigner, self).unsign(value)\n File "/local/mailman/venv/lib/python3.10/site-packages/django_q/core_signing.py", line 55, in unsign\n raise BadSignature(\'Signature "%s" does not match\' % sig)\ndjango.core.signing.BadSignature: Signature "F6V0Dr_SvBsx5-cY8vcvLXrX8tA" does not match\n',) The api_key on mailman-hypperkitty.cfg, SECRET_KEY and MAILMAN_ARCHIVE_KEY on setting.py are the same. Any clue what could be the issue? And this is on the latest mailman. > pip freeze aiosmtpd==1.4.4.post2 alembic==1.13.1 arrow==1.3.0 asgiref==3.7.2 atpublic==4.0 attrs==23.2.0 authheaders==0.16.2 authres==1.2.0 blessed==1.20.0 certifi==2024.2.2 cffi==1.16.0 charset-normalizer==3.3.2 click==8.1.7 cmarkgfm==2024.1.14 cryptography==42.0.3 defusedxml==0.7.1 Django==4.1.13 django-allauth==0.61.1 django-appconf==1.0.6 django-compressor==4.4 django-extensions==3.2.3 django-gravatar2==1.4.4 django-haystack==3.2.1 django-mailman3==1.3.11 django-picklefield==3.1 django-q==1.3.9 djangorestframework==3.14.0 dkimpy==1.1.5 dnspython==2.5.0 docutils==0.20.1 falcon==3.1.3 flufl.bounce==4.0 flufl.i18n==5.0.2 flufl.lock==8.0.2 greenlet==3.0.3 gunicorn==21.2.0 HyperKitty==1.3.8 idna==3.6 lazr.config==3.0 lazr.delegates==2.1.0 mailman==3.3.9 mailman-hyperkitty==1.2.1 mailman-web==0.0.8 mailmanclient==3.3.5 Mako==1.3.2 MarkupSafe==2.1.5 mistune==2.0.5 mysql==0.0.3 mysqlclient==2.2.4 networkx==3.2.1 nh3==0.2.15 oauthlib==3.2.2 packaging==23.2 passlib==1.7.4 postorius==1.3.10 psutil==5.9.8 publicsuffix2==2.20191221 pycparser==2.21 Pygments==2.17.2 PyJWT==2.8.0 PyMySQL==1.1.0 python-dateutil==2.8.2 python3-openid==3.2.0 pytz==2024.1 rcssmin==1.1.1 readme-renderer==42.0 redis==3.5.3 requests==2.31.0 requests-oauthlib==1.3.1 rjsmin==1.2.1 robot-detection==0.4 six==1.16.0 SQLAlchemy==2.0.27 sqlparse==0.4.4 types-python-dateutil==2.8.19.20240106 typing_extensions==4.9.0 urllib3==2.2.0 uWSGI==2.0.24 wcwidth==0.2.13 Whoosh==2.7.4 xapian @ file:///local/mailman/xapian-1.4.23-cp310-cp310-linux_x86_64.whl zope.component==6.0 zope.configuration==5.0.1 zope.event==5.0 zope.hookable==6.0 zope.i18nmessageid==6.1.0 zope.interface==6.2 zope.schema==7.0.1 Best Regards, Helio Loureiro https://helio.loureiro.eng.br https://github.com/helioloureiro https://mastodon.social/@helioloureiro

1 year, 9 months

Re: where to configure max_days_to_hold on MM3 GUI interface?

by Shashikanth Komandoor

Thank you Abilash Raj for your help which made me step ahead. With your help, I have written a for loop as below which makes all the lists on my Mailman 3 box set the configuration of max_days_to_hold as 1 and of course I am successful in setting so. And the for loop is as below: *for listid in `curl -u restadmin:restpass -X GET http://localhost:8001/3.1/lists <http://localhost:8001/3.1/lists> | python -mjson.tool| grep "list_id" | awk -F"\"" '{print $4}'` * *do * * curl -u restadmin:restpass -X PATCH http://localhost:8001/3.1/lists/$listid/config <http://localhost:8001/3.1/lists/$listid/config> -d max_days_to_hold='1'* *done* With the above script I am able to set the value of max_days_to_hold as required but how to check manually and make my held messages discarded automatically which are after the specified period configured for max_days_to_hold. If I am able to do it manually I can be confident to take in to production so that the held messages after a specific period would not be appeared under "held messages" tab. On Sat, Feb 1, 2020 at 11:14 PM Abhilash Raj <maxking(a)asynchronous.in> wrote: > On Sat, Feb 1, 2020, at 5:27 AM, Shashikanth Komandoor wrote: > > Hello Mark, > > > > Thanks for helping me for moving ahead in my project. > > > > Troubling you again, I would like to put another request at you. > > > > As per your suggestion, I am trying to configure my list > > configuration through REST API for specially the parameter like > > max_days_to_hold as it is not available through interface and I am > > following the official links of mailman 3 i.e > > > https://mailman.readthedocs.io/en/latest/src/mailman/rest/docs/listconf.html > > > > But I am getting "name is not defined" sort of errors as below: > > > > > > > > > > > > *>>> dump_json('http://localhost:9001/3.0/lists/ > > <http://localhost:9001/3.0/lists/>','ant(a)example.com/config > > <http://ant@example.com/config>',dict(display_name='My > > List'),'PATCH')Traceback (most recent call last): File "<stdin>", line > 1, > > in <module>NameError: name 'dump_json' is not defined>>>* > > > > Actually I am new to REST API but hope this is the only issue > that > > is preventing me to go ahead. > > > > Could you please help me by saying how should I handle this so > that > > I should be able to configure *max_days_to_hold* of a list or multiple ? > > > > > dump_json is basically a Python function which sends the request to the > URL you add as the first parameter (GET, if any data isn't specified and > uses POST if data is specified or explicitly define the PATCH or method > like you have above) and prints the json response. > > You can easily do the same using curl with the right authorization > headers, with something like: > > > $ curl -u restadmin:restpass -X PATCH \ > http://localhost:8001/3.1/lists/somelist.example.com/config -d > display_name='Patched Name' > > > Note that "restadmin:restpass" is the username password that you have set > in your mailman.cfg. > > If you do want to use Python, you can just use a regular PATCH request > using requests or standard library urllib3. > > Finally, dump_json is documented here: > https://mailman.readthedocs.io/en/latest/src/mailman/docs/documentation.htm… > > > > On Wed, Jan 29, 2020 at 11:20 PM Mark Sapiro <mark(a)msapiro.net> wrote: > > > > > On 1/28/20 8:42 PM, Shashikanth Komandoor wrote: > > > > > > > > But I could see that parameter value configurable on MM2 GUI > > > > interface in General Options but I don't see the same on the MM3 GUI > > > > interface. > > > > > > > > > There are many core settings not (yet) exposed in Postorius. > > > max_days_to_hold. is one of them. It can be set via `mailman shell` or > > > via the REST API > > > < > > > > https://mailman.readthedocs.io/en/latest/src/mailman/rest/docs/rest.html#re… > > > >. > > > > > > -- > > > 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/ > > > > > > > > > -- > > Thanks & Regards, > > Shashi Kanth.K > > 9052671936 > > _______________________________________________ > > 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) > _______________________________________________ > 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 & Regards, Shashi Kanth.K 9052671936

5 years, 11 months

Re: Which folder should I share between pods with kubernetees persistentVolumeClaim ?

by Stephen J. Turnbull

antoine.depoisier--- via Mailman-users writes: > First, my nodes are all an instance of mailman-core only. > I have an existing MTA that handle all email, and sent them to a > proxy, that dispatch all email between the existing pods. Then, > email are transferred to the MTA and MTA send them. So you are distributing mailman core across multiple nodes? And "proxy" = "load balancer" (such as HAProxy)? That is probably subject to a number of problems, unless you do things that I'm not sure how to do. For example, when a user account is disabled by bounces, every so often Mailman will send a "hey, are you alive again?" message to the user. If enough of those bounce, the user gets unsubscribed. The problem is that that status is recorded in the PostgreSQL database that all Mailman instances have access to, and I think they'll probably all send those messages. At best there's a race condition where more than one might send the message. Under some conditions moderators may get daily messages about bounces. I suspect they would get one from each Mailman instance. I think digests will be broken unless you share the lists subfolder, because each Mailman instance will accumulate only the messages it processes, so chances are good on an active list that digest subscribers will get multiple partial digests when they should get only one. As I'll describe below, Mailman tends to spawn a lot of processes, many of which don't have much work to do. Now you're dividing very little work across multiple nodes, which seems very wasteful. You haven't said where your MTA lives. If it's Postfix, it needs to share the $data_dir folder with a Mailman instance that is responsible for list creation. Every time you restart Mailman it recreates the files in that folder, so if it's shared among Mailman instances there will be delays due to file locking. So unless you have an insane amount of list traffic to process (say, a G7 national government ;-), I wonder if the multi-instance approach is necessary. Mailman is not implemented to be operated that way -- you're asking for trouble. The design is such that I imagine it can be done with careful tuning, but current default configuration didn't consider such a use case. You don't need to answer, you know your use case and I don't, but you may save yourself a lot of trouble by just running with a little more resources on a single node. Mailman uses a lot of memory just to get started (about 2GB unless you're really aggressive and do unsupported tuning of which runners are started and what modules are loaded), but then it easily scales without increasing resources except CPU to some extent. For example I've worked on a system that processes hundreds of thousands of incoming posts a day on a single Linode (2vCPU, 16GB) running core, Postorius, HyperKitty, Xapian, and nginx (PostgreSQL got its own VM for some reason). CPU usage on that system never gets above 25%, active memory usage generally 20-25% and there's usually a substantial amount free despite Linux's strategy of aggressively caching files, load average normally around 2.5 and never more than 5. The only tuning we did there was to bump the out queue's slices to 8 and in queue to 2, but all running on that same Linode (which pushes Mailman's memory usage to over 2GB). Running "ls -R queue" gives all empty subfolders about 2/3 of the time. > For the folder queue, I'm not sure if I should share this folder > between all pods, because one instance of mailman core mean one > worker if I'm right, No, one instance of Mailman core means a minimum of 15 processes (one master and 14 runners) in the default configuration. About half of those have nothing to do most of the time. You can probably whittle that 15 down to 11 with some care at a cost of a certain amount of functionality. Most runners have their own queues as subfolders of 'queue'. Each queue consists of message files with times derived from the timestamp of creation and a hash. Each runner processes its queue in order of the timestamps. When its task is complete, it passes the message to the next runner in sequence by moving the file into the appropriate subfolder (with the same filename). By the nature of email, each message is independent of all the others. So we can process them in parallel, as long as there is a way to assign one and only one runner to each message in a queue. The way we do that is to take the top N bits of the hash component of the filename, which we call a slice. Thus each queue has 1 or 2 or 4 or 8, etc slices. To configure multiple slices for the out runner (usually the bottleneck because it's the one that talks almost directly to the network[1]), add [runner.out] instances: 4 to your mailman.cfg and restart. That's what I recommend you do. Footnotes: [1] At least Postfix optimizes relaying by opening a connection to the remote smtpd while still talking to Mailman, and only queues the file on disk if the remote connection fails.

11 months, 1 week

Re: admin/login/ cannot be accessed

by Abhilash Raj

On Thu, Dec 12, 2019, at 2:37 AM, jean-christophe manciot wrote: > - Django version is 2.2.6-1ubuntu1 > - Disabling HTTP2 in nginx means disabling it for all server blocks listening on the same IP, which would degrade all other servers. > - Doing so leads to another error: > This page isn’t working > <mysite> didn’t send any data. > ERR_EMPTY_RESPONSE > - I cannot run nginx and apache on the same <ip_address>:443 port either. > > I found no error in mailman3 or syslog logs. > In ```/etc/mailman3/mailman.cfg```, I have: > ``` > [logging.debian] > format: %(asctime)s (%(process)d) %(message)s > datefmt: %b %d %H:%M:%S %Y > propagate: no > level: debug > path: mailman.log > ``` > Yet, mailman.log does not seem to show debug level information. mailman.log is only a log file for the Core. Since you are having issues with Django, the requests aren't even touch Mailman Core. Depending on how you are deploying, you should look at mailman-web.log or whatever the name of the log file is. You can find it in the Django settings. > > On Wed, Dec 11, 2019 at 7:04 PM Abhilash Raj <maxking(a)asynchronous.in> wrote: >> >> >> On Wed, Dec 11, 2019, at 9:25 AM, jean-christophe manciot wrote: >> > Ubuntu 20.04 >> > python3-django 2:2.2.6-1ubuntu1 >> > python3-django-hyperkitty 1.3.1 (built from sources) >> > mailman3-full 3.2.2-1 >> >> Which version of Django are you using? >> >> > >> > Nginx server configuration: >> > ``` >> > ... >> > ######## >> > # Static >> > ######## >> > location /favicon.ico >> > { >> > alias <mysite_dir>/static/hyperkitty/img/favicon.ico; >> > } >> > location /static/favicon.ico >> > { >> > alias <mysite_dir>/static/postorius/img/favicon.ico; >> > } >> > location /static/ >> > { >> > alias <mysite_dir>/static/; >> > } >> > >> > ####################### >> > # Upstream uwsgi server >> > ####################### >> > location / >> > { >> > include /etc/nginx/uwsgi_params; >> > uwsgi_pass 127.0.0.1:<uwsgi_server_port>; >> > } >> > ... >> > ``` >> > where: >> > - <mysite_dir> is a symlink to <django_dir>/static >> > - <uwsgi_server_port> matches the one defined in ```/etc/mailman3/uwsgi.ini```: >> > ``` >> > [uwsgi] >> > # Port on which uwsgi will be listening. >> > uwsgi-socket = 127.0.0.1:<uwsgi_server_port> >> > ``` >> > >> >> The config looks good to me in a quick glance. >> >> >> > All 3 systemd services run fine: >> > - mailman3 >> > - mailman3-web >> > - qcluster >> > >> > I'm trying to login to the django administration pages. >> > I get the django administration login page at: >> > https://mysite/admin/login/ >> > Logging in with the admin credentials leads to: >> > ``` >> > This site can’t be reached >> > The webpage at https://mysite/admin/login/ might be temporarily down or >> > it may have moved permanently to a new web address. >> > ERR_HTTP2_PROTOCOL_ERROR >> > ``` >> > This is very strange because it is the URL which I used to get the >> > login page in the first place. >> >> >> Looking at the error, it seems like something somewhere is re-directing to HTTP/2 or the request is based off of HTTP/2 and all the components in the stack don't support HTTP/2, leading to the error message. >> >> I haven't played a lot with HTTP/2 yet so I am not sure which specific component in the stack could be incompatible here. >> >> > >> > If I launch a test web server at another port with: >> > ``` >> > <django_dir># python3 manage.py runserver <mysite_ip_address>:8080 >> > Performing system checks... >> > >> > System check identified no issues (0 silenced). >> > December 11, 2019 - 17:50:48 >> > Django version 2.2.6, using settings 'settings' >> > Starting development server at http://<mysite_ip_address>:8080/ >> > Quit the server with CONTROL-C. >> > ``` >> > and access it at ```http://<mysite_ip_address>:8080/admin/login/``` to >> > login with the same credentials as before, I get through and all the >> > django administration lines appear, although in a degraded layout: >> > ``` >> > Site administration >> > Accounts >> > Email addresses Add Change >> > Authentication and Authorization >> > Groups Add Change >> > Users Add Change >> > Django Mailman 3 >> > Mail domains Add Change >> > Profiles Add Change >> > ... >> > ``` >> > Any idea what could be happening here? >> >> >> Degraded layout is due to missing static files since the development server that you spun off doesn't serve static files. So, that is okay. >> > _______________________________________________ >> > 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) > > > -- > Jean-Christophe -- thanks, Abhilash Raj (maxking)

6 years, 1 month

Migrated from MM2 to MM3, all is well except *one* list

by Scott Courtney

Hello, all I have migrated a multi-list server from MM2 to MM3, on Debian 11, and migrated about half a dozen lists with fairly large archives. Absolutely everything has been working for a couple of months, but I am still unable to get one specific list to send mail to its subscribers. Of course, the first place I started was the logs, but that's the problem -- even with logging turned up, it appears to be failing silently as it connects to the MTA. Here's a summary of the environment: OS: Debian Linux 11, 64-bit, on a virtual machine MTA: Exim 4.94.2 List server: Mailman 3.3.3 (installed from Debian repo) Database: MariaDB 10.5.15 All daemons are running on the same host, and communication is either UNIX socket or loopback network interface, for security. Web server: Apache 2.4.53, with proxy to WSGI per the MM3 setup guide Symptom: There are six lists on the server. All six can accept inbound traffic and will post the messages to the (always private, in this environment) archives. The web interface is working perfectly. Five of the lists also can send out messages to subscribers, but the sixth list cannot send traffic to the MTA, or is not attempting to do so. Tests run so far (all resulting in successful posting to archives, but no outbound mail): * Originate mail from inbound SMTP to the list address. * Originate mail from the web UI as a member/moderator. * Originate mail from the web UI as the site admin (also the list owner). * Originate mail from both inbound SMTP and web UI by multiple users. Log data for the inbound traffic (typical test message, some data redacted): 2022-08-27 15:11:57 1oS1Dn-003AWH-Hz <= REDACTED H=REDACTED:25 P=esmtps X=TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128 CV=no K S=2552 DKIM=REDACTED id=REDACTED T="TEST 8.27.001" 2022-08-27 15:11:57 1oS1Dn-003AWH-Hz => MY_LIST(a)lists.MY_DOMAIN R=mailman_main_director T=mailman3_transport H=127.0.0.1 [127.0.0.1] I=[127.0.0.1] C="250 Ok" 2022-08-27 15:11:57 1oS1Dn-003AWH-Hz Completed Log data for MM3 smtp.log (again, partially redacted): Aug 27 15:11:57 2022 (690182) Available AUTH mechanisms: LOGIN(builtin) PLAIN(builtin) Aug 27 15:11:57 2022 (690182) Peer: ('127.0.0.1', 48170) Aug 27 15:11:57 2022 (690182) ('127.0.0.1', 48170) handling connection Aug 27 15:11:57 2022 (690182) ('127.0.0.1', 48170) Data: b'LHLO REDACTED' Aug 27 15:11:57 2022 (690182) ('127.0.0.1', 48170) Data: b'MAIL FROM:<REDACTED>' Aug 27 15:11:57 2022 (690182) ('127.0.0.1', 48170) sender: REDACTED Aug 27 15:11:57 2022 (690182) ('127.0.0.1', 48170) Data: b'RCPT TO:<erevnite(a)lists.4th.com>' Aug 27 15:11:57 2022 (690182) ('127.0.0.1', 48170) recip: MY_LIST(a)lists.MY_DOMAIN Aug 27 15:11:57 2022 (690182) ('127.0.0.1', 48170) Data: b'DATA' Aug 27 15:11:57 2022 (690182) ('127.0.0.1', 48170) Data: b'QUIT' Aug 27 15:11:57 2022 (690182) ('127.0.0.1', 48170) connection lost Aug 27 15:11:57 2022 (690182) Connection lost during _handle_client() Originally I thought the "connection lost" indicated a failure, but that is happening for all the lists, and also on successful traffic. Since it occurs after the QUIT command in the SMTP session, and based on some online searching, my current understanding is that this is harmless and simply indicates the MTA closed the socket after the QUIT. (Please correct me if that is wrong.) Log data for mailman.log, with partial redaction: Aug 27 15:11:57 2022 (690181) ACCEPT: <REDACTED> Aug 27 15:11:59 2022 (690178) HyperKitty archived message <REDACTED> to https://lists.MY_DOMAIN/hyperkitty/list/MY_LIST@lists.MY_DOMAIN/message/G3D… 19:11:59 [Q] INFO Enqueued 518 19:11:59 [Q] INFO Enqueued 519 19:11:59 [Q] INFO Enqueued 520 19:11:59 [Q] INFO Enqueued 521 19:11:59 [Q] INFO Enqueued 522 19:11:59 [Q] INFO Enqueued 523 19:11:59 [Q] INFO Enqueued 524 INFO 2022-08-27 19:11:59,648 690164 hyperkitty.views.mailman Archived message <REDACTED> to https://lists.MY_DOMAIN/hyperkitty/list/MY_LIST@lists.MY_DOMAIN/message/G3D… [pid: 690164|app: 0|req: 4688541/4688541] 2600:3c04::f03c:91ff:fe02:9cc1 () {64 vars in 1255 bytes} [Sat Aug 27 19:11:59 2022] POST /hyperkitty/api/mailman/archive?key=xombsjgLDqe6d1oxvBaQWH4ZT81uCEjH => generated 113 bytes in 110 msecs (HTTP/1.1 200) 5 headers in 160 bytes (1 switches on core 0) 19:12:00 [Q] INFO Process-1:4 processing [update_from_mailman] 19:12:00 [Q] INFO Process-1:3 processing [sender_mailman_id] 19:12:00 [Q] INFO Process-1:2 processing [rebuild_thread_cache_new_email] 19:12:00 [Q] INFO Process-1:1 processing [compute_thread_positions] 19:12:00 [Q] INFO Processed [rebuild_thread_cache_new_email] 19:12:00 [Q] INFO Process-1:2 processing [rebuild_mailinglist_cache_recent] 19:12:00 [Q] INFO Processed [sender_mailman_id] 19:12:00 [Q] INFO Process-1:3 processing [rebuild_mailinglist_cache_for_month] 19:12:00 [Q] INFO Process-1:1 processing [check_orphans] 19:12:00 [Q] INFO Processed [compute_thread_positions] 19:12:00 [Q] INFO Processed [rebuild_mailinglist_cache_for_month] 19:12:00 [Q] INFO Processed [check_orphans] 19:12:00 [Q] INFO Processed [rebuild_mailinglist_cache_recent] 19:12:00 [Q] INFO Processed [update_from_mailman] [pid: 690164|app: 0|req: 4693691/4693691] 184.94.240.88 () {60 vars in 929 bytes} [Sat Aug 27 19:21:50 2022] HEAD / => generated 0 bytes in 2 msecs (HTTP/1.1 301) 6 headers in 204 bytes (1 switches on core 0) [pid: 690164|app: 0|req: 4693694/4693694] 184.94.240.88 () {60 vars in 1009 bytes} [Sat Aug 27 19:21:50 2022] HEAD /postorius/lists/ => generated 7136 bytes in 142 msecs (HTTP/1.1 200) 5 headers in 163 bytes (1 switches on core 1) There is nothing at all in the Exim log indicating an outbound transaction was attempted by Mailman. I know Exim and Mailman are communicating because all the lists use the same SMTP configuration for Exim and Mailman (i.e., the non-working list is not in any way exceptional). I've done a lot of searching online to find a solution, and I did see that a couple of others had asked about this type of problem, but the only one I found that got a response had an issue that didn't apply in my small environment. Absent any other ideas, I'm going to try inserting some trace logging into the Python code, but I can't figure out what's wrong here. I've even gone to the point of looking at the SQL rows to verify this list is exactly parallel to another working list, except its name and integer ID numbers for various unique auto-increment keys. Any suggestions are appreciated. Thanks!

3 years, 4 months

Mailman-users search results for query "Postorius"