Search results for "Postorius" - Mailman-users

Re: HYPERKITTY_ATTACHMENT_FOLDER

by Ugnius S

OK, I got it, resolved. I can confirm that adding this syntax line to /project/home settings.py or settings_local.py it works: HYPERKITTY_ATTACHMENT_FOLDER = '/full/path/to/folder/' Thank you Abhilash Kind regards Ugnius 2019-09-11, tr, 22:50 Abhilash Raj <maxking(a)asynchronous.in> rašė: > > > On Wed, Sep 11, 2019, at 12:47 PM, Ugnius S wrote: > > Could You please confirm that this parameter should be placed in > mailman-hyperkitty.cfg file? > I have checked mailman/postorius/hyperkitty owner user can write files > there and web user group > has privileges to write and to read, but *no any files appear there*. > Mailman works, it is possible to download > attachments from hyperkitty. Mailman restarted, uwsgi restarted, runjobs > restarted. No files in > /full/path/to/folder/ > > File looks like: > > [general] > base_url: https://flistserv.example.com/hyperkitty/ > api_key: BlaBlabla > > HYPERKITTY_ATTACHMENT_FOLDER = /full/path/to/folder/ > > > > No, this is supposed to go in your Django's configuration file, > settings.py. > > mailman-hyperkitty.cfg is used by Mailman Core to read config on how to > archive emails in Hyperkitty. You need want to tell Hyperkitty to put > attachments on disk and hence the changes are going to be "settings.py". > > > > BR > Ugnius > > > 2019-09-11, tr, 21:21 Ugnius S <ugniusviln(a)gmail.com> rašė: > > Thank You so much. > > 1) https://hyperkitty.readthedocs.io/en/latest/install.html > Close to the end before the "UPDATE" topic, chapter "Customization". > > 2) > https://buildmedia.readthedocs.org/media/pdf/hyperkitty/stable/hyperkitty.p… > Page 10, chapter 2.8 "Customization" > > BR > Ugnius > > 2019-09-11, tr, 20:16 Abhilash Raj <maxking(a)asynchronous.in> rašė: > > > > On Wed, Sep 11, 2019, at 9:52 AM, Ugnius S wrote: > > Hi. > > > > Can anybody send example how to set it? It is mentioned in documentation, > > but very vaguely. > > If you can point out where did you find it in docs, I can update it. > Information is kind of duplicated in a few places. > > > HYPERKITTY_ATTACHMENT_FOLDER = /full/unix/path > > This is the right value. > > It is a path on the filesystem, where the user running Hyperkitty is > allowed to write. > > > > > HYPERKITTY_ATTACHMENT_FOLDER = http://localhost:8000/something > > > > HYPERKITTY_ATTACHMENT_FOLDER = ./var/data/something/ > > > > Has anybody experience of using this, maybe have recommendations of using > > it? Better under project user or better under web content owner where the > > static content is. I would like to store attachments separately to avoid > > growing database. > > Hyperkitty documentation: > > By default, HyperKitty stores the email attachments in the database. > If > > you would rather have them stored on the filesystem, you can set the > > HYPERKITTY_ATTACHMENT_FOLDER configuration value to a directory. > > Make sure that the user running the Django process (for example, apache > or > > www-data) has the permissions to write in this directory. > > > > ------------- > > _______________________________________________ > > 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, > Abhilash Raj (maxking) > > >

6 years, 9 months

Re: Apache+mod_wsgi issue

by Mark Sapiro

On 12/22/22 22:26, Odhiambo Washington wrote: > On Fri, Dec 23, 2022 at 9:21 AM Odhiambo Washington <odhiambo(a)gmail.com> > wrote: > >> And now I am having a problem with mod_wsgi. >> First, the URL displayed when I load the page looks bogus to me. >> While I expect the URL to be >> https://mm3-lists.kictanet.or.ke/mailman3/domains/, mod_wsgi give me >> https://mm3-lists.kictanet.or.ke/mailman3/mailman3/domains/ - there is an >> extra /mailman3! See below: >> So I have; >> 1. https://mm3-lists.kictanet.or.ke/mailman3/mailman3/lists/ - working, >> or appears to. >> 2. https://mm3-lists.kictanet.or.ke/mailman3/mailman3/domains/ - working, >> or appears to. >> 3. https://mm3-lists.kictanet.or.ke/mailman3/mailman3/bans/ - working, or >> appears to >> 4. https://mm3-lists.kictanet.or.ke/mailman3/mailman3/users - working, or >> appears to >> 5. >> https://mm3-lists.kictanet.or.ke/mailman3/mailman3/lists/kictanet.lists.kic… >> - This throws an exception error when I click "Manage Subscription". >> >> -> https://pastebin.ubuntu.com/p/RkKH793Jgw/ messages like these [Fri Dec 23 09:10:55.393386 2022] [wsgi:error] [pid 74857] [remote 197.232.81.246:14181] File "/opt/mailman/mm/venv/lib/python3.9/site-packages/mailmanclient/restbase/connection.py", line 160, in call [Fri Dec 23 09:10:55.393390 2022] [wsgi:error] [pid 74857] [remote 197.232.81.246:14181] raise HTTPError(params.get('url'), response.status_code, [Fri Dec 23 09:10:55.393394 2022] [wsgi:error] [pid 74857] [remote 197.232.81.246:14181] urllib.error.HTTPError: HTTP Error 500: {"title": "500 Internal Server Error"} Indicate an uncaught exception in Mailman core. What's in mailman.log? >> And while I do not quite understand the error itself, there is also one >> particular line that I also saw that has left me baffled: >> [Fri Dec 23 08:53:18.290411 2022] [core:info] [pid 91236] [client >> 197.232.81.246:13865] AH00128: File does not exist: >> /usr/local/www/apache24/data/archives/list/ >> kictanet(a)lists.kictanet.or.ke/thread/VIHCC6MSXZSNHY7YPEJ3D2US4N7MHJEC/, >> referer: >> https://mm3-lists.kictanet.or.ke/archives/list/kictanet@lists.kictanet.or.ke This is because something is doing an HTTP GET for `/archives/list/kictanet(a)lists.kictanet.or.ke/thread/VIHCC6MSXZSNHY7YPEJ3D2US4N7MHJEC/` and the URL is not recognized as one handled by mod_wsgi so apache tries to get it from its DocumentRoot. mod_wsgi has to serve a number of URLs. Look in /opt/mailman/mm/urls.py for urlpatterns. You will probably see things like url(r'^accounts/', include('allauth.urls')), # Django admin url(r'^admin/', admin.site.urls), url(r'^mailman3/', include('postorius.urls')), url(r'^archives/', include('hyperkitty.urls')), Those are all things that need to be handled by mod_wsgi In your apache config, you only have a WSGIScriptAlias for /mailman3. Thus paths need to be prefixed with /mailman3 in order to be handled by mod_wsgi. I'm not sure what is doing this prefixing, but without it paths that don't begin with /mailman3 don't work unless you also have things like WSGIScriptAlias /accounts /opt/mailman/mm/wsgi.py WSGIScriptAlias /admin /opt/mailman/mm/wsgi.py WSGIScriptAlias /archives /opt/mailman/mm/wsgi.py in your apache config. > I also need to add the fact that at the point where I am clicking "Manage > Subscription", the URL has changed to > https://mm3-lists.kictanet.or.ke/mailman3/archives/list/kictanet@lists.kict… > (just a single /mailman3). > Something is adding mailman3/ to URLs. In the above the URL should be https://mm3-lists.kictanet.or.ke/archives/list/kictanet@lists.kictanet.or.k…, but an extra /mailman3 is added. The others are like https://mm3-lists.kictanet.or.ke/mailman3/lists/ and an extra /mailman3 is added. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 5 months

Re: Hyperkitty using wrong email address in archive view

by Stephen J Turnbull

2023-05-16 17:42 に peter(a)chubb.wattle.id.au さんは書きました: > I notice that for people with multiple email addresses, the email > address that appears as the 'FROM' address in the hyperkitty > archive is not the primary address, nor is it the address that the > email actually came from, but the address that was created first. > (Hyperkitty version 1.3.7) I can't help with this. I don't understand why that would happen, maybe Mark or Abhilash does. I would think that the address that would be shown is the address in the email's From field. > When I click on that from address in the archive view, I see all > the email addresses for the user -- these do not match up with the > ones in the django admin screen from .../admin/account/emailaddress/ They shouldn't, necessarily. The user's active emails will be maintained by the user in Postorius, which what I believe appears in the Django admin screen. However, HyperKitty needs to know *more*: in general, it needs to know every address by which that user was identified in the archives. This is valuable to the users of the archives -- if they try to mail an author at a defunct address, they can return to the profile to find an active one. > How can I as administrator get rid of bogus addresses? Or do I > have to ask each user to do this? I believe Mark has a script for getting rid of garbage addresses that have no root in user-visible data, but these are not garbage in that sense: they do appear in the archives. However, since that script refers only to the database, it would probably work for HyperKitty's addresses too. But it might require code modifications, inasmuch as there would be database errors if either the Address object doesn't exist or the User link in the Address object is null. > and how can I ensure that the email address displayed in the > archive is the primary address, not some address that no longer > works? That's not necessarily your choice (I'm not speaking to your installation, I'm talking about design principles). Remember that users can associate specific addresses with specific lists, and you would be overriding that preference ex post. (I have no problem with you announcing a "real address only" rule in advance, of course.) Also, there may be a reason why that address is defunct: stalkers, termination of employment, etc. In those cases, the user may have a strong desire not to contacted about the post in question. If you are in a jurisdication that is under GDPR or other strong privacy legislation, there may be legal implications you should consider. In general you should consider whether possibly violating users' expectations in these ways are appropriate to your site. In general, Mailman 3's design philosophy is to give users fine control of their user profiles and addresses and of their subscriptions' configurations, while list owners get the traditional features for their list configurations: control over access and default profiles, etc. So I suspect there is no way to impose the restrictions you want without writing new code. I don't have a particular objection to such features as long as the policies are transparently documented (users don't have to use those sites), but I'm not available to work on them for some time. -- University of Tsukuba　　　　　　　　　　　　 Faculty of Policy and Planning Sciences Tennodai 1-1-1, Tsukuba 305-8573 JAPAN tel/fax: +81-29-853-5091 turnbull(a)sk.tsukuba.ac.jp 　　　　　　　　　　　　　　https://turnbull.sk.tsukuba.ac.jp/

3 years

E-mail every minute: "Cron <www-data@sharky5> ..."

by Robert Heller

What am I missing? I *think* I have mailman3 *mostly* setup, but there are still some configuration things that are missing, but I am not sure how to fix them (the docs are NOT clear). I am getting an e-mail *every* minute that looks like: From www-data(a)deepsoft.com Sat Jul 6 17:38:03 2024 Return-Path: <www-data(a)deepsoft.com> X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on sharky5.deepsoft.com X-Spam-Level: X-Spam-Status: No, score=-850.0 required=5.0 tests�YES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NO_RELAYS,URIBL_BLOCKED, USER_IN_WELCOMELIST autolearn=ham autolearn_force=no version=4.0.0 X-Original-To: www-data Delivered-To: www-data(a)deepsoft.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d�epsoft.com; s�epsoft.com; t20301883; bh=qGrVTBfV1NiqgxCIzSaXwoKZ0lKxKvaK56k31yXU2Sk=; h=From:To:Subject:Date:From; b=jTml1ZF+qGkmS2tcz5kgZHjOyPxeaWIQiX1mzAF3ZfZWb0ziVLxutkcej5mGapUOq PpH6ExYM1TEipMTYQ/JRY/74vz2dEpebDrZqjyY3KakxLWiyFFEb5glmQYZGvz9wr2 e5ljD0Shku4fbRoaxO7XMQCn/fmx3+D8tI/ZPbMQReceived: by sharky5.deepsoft.com (Postfix, from userid 33) id 5257D4C1296; Sat, 6 Jul 2024 17:38:03 -0400 (EDT) From: root(a)deepsoft.com (Cron Daemon) To: www-data(a)deepsoft.com Subject: Cron <www-data@sharky5> [ -f /usr/bin/django-admin ] && flock -n /var/run/mailman3-web/cron.minutely /usr/share/mailman3-web/manage.py runjobs minutely MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Cron-Env: <SHELL=/bin/sh> X-Cron-Env: <HOME=/var/www> X-Cron-Env: <PATH=/usr/bin:/bin> X-Cron-Env: <LOGNAME=www-data> Message-Id: <20240706213803.5257D4C1296(a)sharky5.deepsoft.com> Date: Sat, 6 Jul 2024 17:38:03 -0400 (EDT) X-Scanned-By: MIMEDefang 3.3 on 108.161.129.198 Status: R /usr/lib/python3/dist-packages/django_q/conf.py:139: UserWarning: Retry and timeout are misconfigured. Set retry larger than timeout, failure to do so will cause the tasks to be retriggered before completion. See https://django-q.readthedocs.io/en/latest/configure.html#retry for details. warn( System check identified some issues: WARNINGS: django_mailman3.MailDomain: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the DjangoMailman3Config.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. django_mailman3.Profile: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the DjangoMailman3Config.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.Attachment: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.Email: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.Favorite: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.LastView: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.MailingList: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.Profile: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.Tag: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.Tagging: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.Thread: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.ThreadCategory: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.Vote: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. postorius.EmailTemplate: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the PostoriusConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. And I get this output from sudo mailman-web check --no-color : System check identified some issues: WARNINGS: django_mailman3.MailDomain: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the DjangoMailman3Config.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. django_mailman3.Profile: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the DjangoMailman3Config.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.Attachment: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.Email: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.Favorite: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.LastView: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.MailingList: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.Profile: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.Tag: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.Tagging: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.Thread: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.ThreadCategory: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.Vote: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. postorius.EmailTemplate: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the PostoriusConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. System check identified 14 issues (0 silenced). Again, the docs are not helpful (at least not to me). -- Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364 Deepwoods Software -- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services heller(a)deepsoft.com -- Webhosting Services

1 year, 11 months

Re: New year releases!

by Dan Caballero

Thanks Mark. The migration completes after I updated the curls.py file. I do see some warnings... "WARNINGS: django_mailman3.MailDomain: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the DjangoMailman3Config.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. django_mailman3.Profile: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the DjangoMailman3Config.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.Attachment: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.Email: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.Favorite: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.LastView: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.MailingList: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.Profile: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.Tag: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.Tagging: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.Thread: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.ThreadCategory: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.Vote: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. postorius.EmailTemplate: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the PostoriusConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'."

3 years, 5 months

Re: Archiving error

by Enrique Terrazas

Excellent! Thanks again for your guidance. I have a follow up question, I tried setting the base_url to https but received SSL errors in the mailman.log. The nginx.conf is using a valid certificate from a CA and the sites(Django admin, Postorius, Hyperkitty) all load with https in the browser, they are redirected from http as well. But it seems that internal communication is failing when I try to specify https in the base_url Is this something that I should be concerned about and can be configured? Thank you, Enrique On Oct 5, 2018, at 11:25 AM, Abhilash Raj <maxking(a)asynchronous.in<mailto:maxking@asynchronous.in>> wrote: On Fri, Oct 5, 2018, at 8:25 AM, Enrique Terrazas wrote: Thank you Abhilash, The port was in fact the problem. Django is listening on a different port as specified in my uwsgi.ini file To be sure I understand this correctly: In uwsgi.ini I am specifying: http-socket = my.host.name:8000 And in hyperkitty.cfg: base_url: http://my.host.name:8000/hyperkitty/<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmy.host.nam…> That is the correct thing to do! thanks, Abhilash Hyperkitty is now archiving messages as expected. Best regards, Enrique On Oct 5, 2018, at 9:57 AM, Abhilash Raj <maxking(a)asynchronous.in<mailto:maxking@asynchronous.in>> wrote: On Fri, Oct 5, 2018, at 12:06 AM, Enrique Terrazas wrote: Hello, I'm hoping someone can help me configure hyperkitty correctly. I've got mailman3 installed and working. I created a test list and can send/ receive, moderate message. However, archiving does not seem to be working. Below is a copy of my (sanitized) hyperkitty.cfg file and settings.py file(edited) along with the errors being logged to mailman.log hyperkitty.cfg ----- # Mailman-Hyperkitty Archiver plugin [general] base_url: http://localhost:8002/ Which PORT is your Django listening on? This seems like pointing to 8002 port, are you actually listening on that port? The error below seems to suggest that either the Django isn't running or you are using wrong address. api_key: ----- settings.py # Mailman API credentials MAILMAN_REST_API_URL = 'http://localhost:8001<http://localhost:8001/>' MAILMAN_REST_API_USER = '' MAILMAN_REST_API_PASS = '' MAILMAN_ARCHIVER_KEY = '' MAILMAN_ARCHIVER_FROM = ('my.host.name', 'myIPaddress', '127.0.0.1', ':: 1') ------ This is the error being sent to maillog.log ------ Oct 05 01:54:59 2018 (15127) Exception in "hyperkitty" archiver Traceback (most recent call last): File "/opt/mailman/mailman/lib64/python3.6/site-packages/urllib3/ connection.py", line 171, in _new_ conn (self._dns_host, self.port), self.timeout, **extra_kw) File "/opt/mailman/mailman/lib64/python3.6/site-packages/urllib3/util/ connection.py", line 79, in c reate_connection raise err File "/opt/mailman/mailman/lib64/python3.6/site-packages/urllib3/util/ connection.py", line 69, in c reate_connection sock.connect(sa) ConnectionRefusedError: [Errno 111] Connection refused During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/opt/mailman/mailman/lib64/python3.6/site-packages/urllib3/ connectionpool.py", line 600, in urlopen chunked=chunked) File "/opt/mailman/mailman/lib64/python3.6/site-packages/urllib3/ connectionpool.py", line 354, in _make_request conn.request(method, url, **httplib_request_kw) File "/opt/rh/rh-python36/root/usr/lib64/python3.6/http/client.py", line 1239, in request self._send_request(method, url, body, headers, encode_chunked) File "/opt/rh/rh-python36/root/usr/lib64/python3.6/http/client.py", line 1285, in _send_request self.endheaders(body, encode_chunked=encode_chunked) File "/opt/rh/rh-python36/root/usr/lib64/python3.6/http/client.py", line 1234, in endheaders self._send_output(message_body, encode_chunked=encode_chunked) File "/opt/rh/rh-python36/root/usr/lib64/python3.6/http/client.py", line 1026, in _send_output self.send(msg) File "/opt/rh/rh-python36/root/usr/lib64/python3.6/http/client.py", line 964, in send self.connect() File "/opt/mailman/mailman/lib64/python3.6/site-packages/urllib3/ connection.py", line 196, in connect conn = self._new_conn() File "/opt/mailman/mailman/lib64/python3.6/site-packages/urllib3/ connection.py", line 180, in _new_conn self, "Failed to establish a new connection: %s" % e) urllib3.exceptions.NewConnectionError: <urllib3.connection.HTTPConnection object at 0x7f0ba1c22048>: Failed to establish a new connection: [Errno 111] Connection refused During handling of the above exception, another exception occurred: ------ Thanks in advance, Enrique J. Terrazas _______________________________________________ Mailman-users mailing list -- mailman-users(a)mailman3.org<mailto:mailman-users@mailman3.org> To unsubscribe send an email to mailman-users-leave(a)mailman3.org<mailto:mailman-users-leave@mailman3.org> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mail…<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mail…> -- thanks, Abhilash Raj (maxking) -- thanks, Abhilash Raj (maxking)

7 years, 8 months

Re: Weird response to postings after subscriptions and accounts

by Mark Sapiro

On 9/16/19 9:22 PM, Paul Arenson wrote: > In my test of the two forms of signup, I am getting these unexpected results. Is it my settings or is something weird within the program itself? > > 1) https://list.tokyoprogressive.org/postorius/lists/discuss.list.tokyoprogres… > > 2) Choose "You can also subscribe without creating an account. If you wish to do so, please use the form below" > > 3) Then I have to approve it. They get "Welcome to the "Discuss" mailing list! To post to this list, send your email to: discuss(a)list.tokyoprogressive.org You have to approve it or the user has to confirm her email address? Maybe you have to approve it because the lists Subscription Policy is Moderate. > 4) But I have to approve it.I assume this is because they do not yet have a real account. And they should be listed as a NON MEMBER? No. They will be a member, they just will not have a Django account that they can log in to. > 5) But even when they sign up here: https://list.tokyoprogressive.org/accounts/signup/?next=%2Fpostorius%2Flist… they get an email from my provider (NOT MY LIST????) as follows: > > "Hello from mailman3.emwd.com! You're receiving this e-mail because user iCloud has given yours as an e-mail address to connect their account. > To confirm this is correct, go to https://list.tokyoprogressive.org/accounts/confirm-email/MTE3:1iA44k:E7w7xh… Thank you from mailman3.emwd.com! mailman3.emwd.com" Because when you create a Django account, you have to confirm your email address. > 6) And this is where it gets weird. If they send from their email program and get the welcome (Welcome to the "Discuss" mailing list! > To post to this list, send your email to: discuss(a)list.tokyoprogressive.org You can unsubscribe or make adjustments to your options via email by > sending a message to....... I then get a notice: > > "Your mail to 'discuss(a)list.tokyoprogressive.org' with the subject test notice Is being held until the list moderator can review it for approval. The message is being held because: The message is not from a list member" What is Message Acceptance -> Default action to take when a member posts to the list ? You get the notice or the user gets the notice? > 7) While if they send FROM THE interface it goes through. > > 8) What I am confused about. > > Signing up for an account should make them a member, right? Subscribing should make them a non member, no? Signing up for an account is just signing up for a Django account. You can sign up for an account and log in and then subscribe to the list. Subscribing makes one a member whether or not you subscribe from a logged in account or subscribe without creating an account. > But here it seems that both make them a non member. If an address which is not a member posts to the list, that address becomes a non-member. This is the only way other than being explicitly added by an admin that an address becomes a non-member. > And worse, someone with an account sending from the Interface has their message get through while the same person sending from an email program has me get a notice that a non member is trying to post. If by sending from the interface, you mean posting via hyperkitty, the user must have an account and be logged in to do that. Your "same person" may have multiple entities within Mailman, possibly subtly different email addresses, one of which is a member and one of which isn't. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 8 months

Re: Bulk changes to delivery mode and moderation action

by David Newman

On 1/7/22 12:06 PM, Mark Sapiro wrote: > On 1/7/22 11:06 AM, David Newman wrote: >> >> 1. In Users/Members, moderation action for the newly resubscribed >> users shows as "None". Is there a method, either in the UI or the >> command line, to change this to "Default processing" for all users? > > > I assume you don't want to set `Default action to take when a member > posts to the list` to Default Processing because you want new member > posts to be held. This is a good practice. To set all members to default > processing in mailman shell .. OK, thanks >> 2. Although Delivery Mode shows as "Regular" for all users in >> Users/Members list, clicking on a member's name shows all options such >> as delivery status, delivery mode, etc., as undefined. > > > They show as undefined, but if you look at your own settings by > selecting `Mailman settings` from the dropdown under your username at > the upper right in Postorius, you will see you have Global Mailman > preferences, Address-based preferences and List-based preferences. If a > list based preference is unset for a list, it falls back to the address > based preference for the address and if that's unset, to the global > preference. > > When you as an admin look at a user, you only see the user's list based > preferences. Thanks. This makes sense, but something's wrong with this particular list. I was able to change preferences using the shell commands you kindly provided. All list member now have regular delivery and default moderation. However, there's no evidence test messages to the list are going out. (Nondelivery was the reason I was mucking around in the admin panel in the first place.) The Postfix log shows delivery to the list address. MM3's smtp.log shows the usual handshake. However, I do not then see messages going out to subscribers in the Postfix log, and as one of those subscribers I do not receive a copy even though my preferences are set to receive my own posts. The admin panel shows 0 messages held for moderation. Another mailing list in the same domain on the same server delivers mail to all subscribers OK. This is surely config problem on my end, but which log(s) and/or admin panel setting(s) to check? Thanks again. dn > >> Similar question: How to set subscriber options for all members in one >> go? > > > Per the above, you only need to set the user's preferences if they don't > have address based preferences and the preference differs from the > global (default) preferences. > > However, if you want to set the member's list preferences, you could add > to the beginning of the above: > ``` > >>> from mailman.interfaces.member import DeliveryMode, DeliveryStatus > >>> english = getUtility(ILanguageManager).get('en') > ``` > and to the `for` loop in the above: > ``` > ... mbr.preferences.acknowledge_posts = False > ... mbr.preferences.delivery_mode = DeliveryMode.regular > ... mbr.preferences.delivery_status = DeliveryStatus.enabled > ... mbr.preferences.hide_address = False > ... mbr.preferences.preferred_language = english > ... mbr.preferences.receive_list_copy = False > ... mbr.preferences.receive_own_postings = True > ``` > Or whatever you think these settings should be. > >> 3. As a subscriber to this list, I received email notification that >> I'd been unsubscribed. Where is the control for enabling/disabling >> subscription notifications? > > > Settings -> Automatic Responses > > >> Settings/Member Policy/Un-subscription Policy is set to Confirm, but I >> don't think that's relevant here since I unsubscribed users as the >> Django superuser. > > > Correct. >

4 years, 5 months

Re: Mass operations on large list - Internal Server Error

by Liam Reilly

Liam Reilly wrote: > Stephen J. Turnbull wrote: > > Here is an example error from the log for unsubscribe all > > operation. > > Which log is this? I would guess it's the mailmanweb.log. > > [2025-12-15 15:41:02 +0000] [1022464] [ERROR] Error handling request /mailman3/lists/uclucu-members.ucl.ac.uk/unsubscribe_all > > Traceback (most recent call last): > > File "/data/mailman/venv/lib64/python3.12/site-packages/gunicorn/workers/sync.py", line 134, in handle > > self.handle_request(listener, req, client, addr) > > This is the front-end gunicorn WSGI server, handling a request for > > Postorius. > > File "/data/mailman/venv/lib64/python3.12/site-packages/mailmanclient/restobjects/mailinglist.py", line 519, in unsubscribe > > response, json = self._connection.call(path, data, method='DELETE') > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > This is mailman client translating to the REST API. > > File "/usr/lib64/python3.12/socket.py", line 720, in readinto > > return self._sock.recv_into(b) > > ^^^^^^^^^^^^^^^^^^^^^^^ > > This is the Python socket library actually talking to the REST API of > > Mailman core. An unspecified error occurs in the C code. It is not > > handled. > > File "/data/mailman/venv/lib64/python3.12/site-packages/gunicorn/workers/base.py", line 204, in handle_abort > > sys.exit(1) > > SystemExit: 1 > > This is the "Something's wrong, hope you have a clue 'cause I don't" > > last line of defense error handler. > > My guess is that it's a timeout on a socket. > > I think you should also see log messages and a traceback in the > > mailman.log. > > The timeout for the mailmanweb gunicorn is configured in the gunicorn > > conf file, usually in /etc/mailman3. This is relatively short (I > > Reilly, Liam writes: > > think my installation is default at 120 seconds). > > The timeout for the REST API gunicorn is in > > site-packages/mailman/config/gunicorn.cfg. This is long (360 seconds) > > so if my conjecture about timeout is correct it's the mailmanweb > > gunicorn that's timing out. If you need to change this one, you may > > be able to simply put "timeout: 360" in the [webservice] section of > > your mailman.cfg file, but if that doesn't work you can copy > > gunicorn.cfg to /etc/mailman3/rest-wsgi.cfg, change the timeout in it, > > and add "configuration: /etc/mailman3/rest-wsgi.cfg" to the > > [webservice] section of mailman.cfg. > > GNU Mailman consultant (installation, migration, customization) > > Sirius Open Source https://www.siriusopensource.com/ > > Software systems consulting in Europe, North America, and Japan > > As always, thank you for your prompt replies Stephen. > The entries are from error.log and are all I could find when grepping for the list name. I'll check the other logs for anything else and also try increasing the timeout config as you've suggested to see if it helps. After some experimentation, I think I've got a working configuration. Setting the timeout in /etc/mailman3/rest-wsgi.cfg did not seem to work properly. In the end I had to modify the systemd unit file for mailmanweb, adding a --timeout to the ExecStart line: ExecStart=/opt/mailman/venv/bin/gunicorn -c /opt/mailman/mm/gunicorn.conf.py --timeout 360 mailman_web.wsgi:application Mass operations now failed with a different "proxy error" after 60s instead of "internal server error" after 30s. I then added "ProxyTimeout 300" to /etc/httpd/conf.d/mailman3.conf to increase that timeout. Testing this I can now mass subscribe 4500 members in ~100s and mass remove them again in ~150s without any errors. I wonder if there's any way to reduce the time it takes to process such operations? More workers? I have been testing with 4 webservice workers.

5 months, 4 weeks

Re: New releases

by brylon＠oit.rutgers.edu

Hi all -- I'm stuck on this "compress" issue after upgrading and not sure how to remedy? After upgrading the Mailman components (core, postorius, hyperkitty) on my test server to the latest available in my venv I ran the following: $ ./bin/django-admin collectstatic --clear --noinput --verbosity 0 and then $ ./bin/django-admin compress --trace Compressing... Traceback (most recent call last): File "/opt/mailman/mm/venv/lib/python3.6/site-packages/compressor/base.py", line 282, in precompile mod = import_module(mod_name) File "/opt/mailman/mm/venv/lib64/python3.6/importlib/__init__.py", line 126, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "<frozen importlib._bootstrap>", line 994, in _gcd_import File "<frozen importlib._bootstrap>", line 971, in _find_and_load File "<frozen importlib._bootstrap>", line 953, in _find_and_load_unlocked ModuleNotFoundError: No module named 'sass -t compressed {infile} {outfile}' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/opt/mailman/mm/venv/lib/python3.6/site-packages/compressor/management/commands/compress.py", line 232, in compress result = parser.render_node(template, context, node) File "/opt/mailman/mm/venv/lib/python3.6/site-packages/compressor/offline/django.py", line 117, in render_node return node.render(context, forced=True) File "/opt/mailman/mm/venv/lib/python3.6/site-packages/compressor/templatetags/compress.py", line 143, in render return self.render_compressed(context, self.kind, self.mode, forced=forced) File "/opt/mailman/mm/venv/lib/python3.6/site-packages/compressor/templatetags/compress.py", line 119, in render_compressed rendered_output = compressor.output(mode, forced=forced, basename=file_basename) File "/opt/mailman/mm/venv/lib/python3.6/site-packages/compressor/css.py", line 46, in output ret.append(subnode.output(*args, **kwargs)) File "/opt/mailman/mm/venv/lib/python3.6/site-packages/compressor/css.py", line 48, in output return super(CssCompressor, self).output(*args, **kwargs) File "/opt/mailman/mm/venv/lib/python3.6/site-packages/compressor/base.py", line 314, in output output = '\n'.join(self.filter_input(forced)) File "/opt/mailman/mm/venv/lib/python3.6/site-packages/compressor/base.py", line 254, in filter_input for hunk in self.hunks(forced): File "/opt/mailman/mm/venv/lib/python3.6/site-packages/compressor/base.py", line 228, in hunks precompiled, value = self.precompile(value, **options) File "/opt/mailman/mm/venv/lib/python3.6/site-packages/compressor/base.py", line 287, in precompile return True, filter.input(**kwargs) File "/opt/mailman/mm/venv/lib/python3.6/site-packages/compressor/filters/base.py", line 239, in input return super(CachedCompilerFilter, self).input(**kwargs) File "/opt/mailman/mm/venv/lib/python3.6/site-packages/compressor/filters/base.py", line 206, in input raise FilterError(err) compressor.exceptions.FilterError: Error: Invalid CSS after "...lor}: #{$value}": expected "{", was ";" on line 4 of /opt/mailman/mm/venv/lib/python3.6/site-packages/hyperkitty/static/hyperkitty/libs/bootstrap/stylesheets/_root.scss from line 11 of /opt/mailman/mm/venv/lib/python3.6/site-packages/hyperkitty/static/hyperkitty/libs/bootstrap/stylesheets/bootstrap.scss from line 4 of /opt/mailman/mm/venv/lib/python3.6/site-packages/hyperkitty/static/hyperkitty/sass/hyperkitty.scss Use --trace for backtrace. During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/opt/mailman/mm/venv/bin/django-admin", line 8, in <module> sys.exit(execute_from_command_line()) File "/opt/mailman/mm/venv/lib/python3.6/site-packages/django/core/management/__init__.py", line 381, in execute_from_command_line utility.execute() File "/opt/mailman/mm/venv/lib/python3.6/site-packages/django/core/management/__init__.py", line 375, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/opt/mailman/mm/venv/lib/python3.6/site-packages/django/core/management/base.py", line 323, in run_from_argv self.execute(*args, **cmd_options) File "/opt/mailman/mm/venv/lib/python3.6/site-packages/django/core/management/base.py", line 364, in execute output = self.handle(*args, **options) File "/opt/mailman/mm/venv/lib/python3.6/site-packages/compressor/management/commands/compress.py", line 277, in handle self.handle_inner(**options) File "/opt/mailman/mm/venv/lib/python3.6/site-packages/compressor/management/commands/compress.py", line 300, in handle_inner offline_manifest, block_count, results = self.compress(engine, extensions, verbosity, follow_links, log) File "/opt/mailman/mm/venv/lib/python3.6/site-packages/compressor/management/commands/compress.py", line 235, in compress "%s" % (template.template_name, smart_text(e))) django.core.management.base.CommandError: An error occurred during rendering /opt/mailman/mm/venv/lib/python3.6/site-packages/django_mailman3/templates/socialaccount/connections.html: Error: Invalid CSS after "...lor}: #{$value}": expected "{", was ";" on line 4 of /opt/mailman/mm/venv/lib/python3.6/site-packages/hyperkitty/static/hyperkitty/libs/bootstrap/stylesheets/_root.scss from line 11 of /opt/mailman/mm/venv/lib/python3.6/site-packages/hyperkitty/static/hyperkitty/libs/bootstrap/stylesheets/bootstrap.scss from line 4 of /opt/mailman/mm/venv/lib/python3.6/site-packages/hyperkitty/static/hyperkitty/sass/hyperkitty.scss Use --trace for backtrace. Any suggestions? The fixes described in this thread don't seem to be working for my case?

5 years, 9 months

Mailman-users search results for query "Postorius"