Search results for "Postorius" - Mailman-users

Re: Hyperkitty CPU usage

by Alain Kohli

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. 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/ >>

6 years, 8 months

Re: Moderation action "None" is misleading

by Stephen J. Turnbull

Adding mailman-users(a)mailman3.org. Technical suggestions should go to distro channels or to Mailman's issue tracker: https://gitlab.com/mailman/mailman/-/issues/1176. Further discussion of technical details is best done there. Thomas Krichel writes: > Stephen J. Turnbull writes > > Debian has traditionally been quite slow to update Mailman, > > And now it has the addition issue that Debian testing python > standard it 3.13, so the nntplib is no longer supported. > Thus the current Mailman debian testing appears broken. That's Debian's problem, as we currently don't support Python 3.13, although of course we intend to. This is the only issue that came up in a quick search of Mailman's issue tracker for Python 3.13 (but I did not check the other subprojects such as Postorius). I conclude that not a lot of work has been done on supporting Python 3.13 (rather than the optimistic "there's nothing to be done"). From Mailman's point of view, users have two excellent options for the forseeable future: (1) don't gateway list <-> newsgroups (2) install Mailman into a Python 3.9--3.12 virtual environment. I'm sympathetic to the needs of the Debian developers, and at this point for 99% of software it's perfectly reasonable to aim to use 3.13 in the next Debian release. Unfortunately for Mailman users on Debian hosts that's not high on our list of priorities since we recommend a virtual environment installation in any case. At present there seem to be three ways forward for Debian packaging: 1. Remove NNTP support. (In honor of larsi, I'd rather not.) 2. Add nntplib.py from the Python 3.12 nntplib, as a stopgap until option 3 can be implemented. I can't speak for other developers but we might be willing to add it as a contrib module, especially if that might make life easier for distro packagers. It's suboptimal though since that absolutely has to be considered techical debt that will need to be paid someday. 3. Port Mailman to pynntp (that may need to be Debian packaged, too), which has seen a revival of activity and two feature releases since 2023. My inclination as a Mailman core developer is not to participate actively in development of NNTP support in Mailman for Python 3.13+ unless we see an outpouring of support from site admins. However, I would be happy to answer questions and work on Mailman-side issues that are blocking or inconvenient for the NNTP work. Mark and Abhilash would undoubtedly contribute as well, on a time-available basis. > I certainly would love to build an alternative Mailman Debian > package that would be more up-to-date, but I don't want > to do it on my own. Debian and Python are compatible free software; just take the existing package metadata, in a recent Mailman (presumably the most recent release) drop in the most recent nntplib, and change all the import statements. mailman/src/mailman/mta/nntplib.py seems like a plausible location. IWBNI you could keep all Mailmanisms out of nntplib (because of the GPL) so any bugfixes or improvements could be available to the Python community. I think you could probably be up and running VERY quickly with that approach. Of course it wouldn't just slot into the next iteration of Debian because they have stringent QA (or maybe that could go into unstable?). I'm pretty sure it would be useful right away to a whole lot of people who are willing to use a PPA. Regards, Steve

11 months, 1 week

Re: HYPERKITTY_ATTACHMENT_FOLDER

by Abhilash Raj

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, 4 months

Re: About to Install MM3 -- Seeking clarification

by Onyeibo Oku

Hi Mark, thanks for your inputs. I am making progress. On January 2, 2023 9:15:59 PM GMT+01:00, Mark Sapiro <mark(a)msapiro.net> wrote: >On 1/2/23 11:56, Onyeibo wrote: >> On Mon, 2 Jan 2023 09:57:45 -0800 >> Mark Sapiro <mark(a)msapiro.net> wrote: >>> >>> curl -urestadmin:restpass http://localhost:8001/3.1/lists >>> >>> It should return JSON with information about your lists. >>> >> >> I get the following: >> {"start": 0, "total_size": 0, "http_etag": >> "\"678678567346533573674563786538\""} > >That is the expected response if you have no lists yet. So connection to >Mailman's REST API works via curl, so why doesn't it work via >mailmanclient? If Mailman core was running, it should work. I don't know >why it doesn't. Perhaps you have some kind of firewall that's blocking it. > It turns out to be a fault from my settings. Postfix was not happy with the default email for the admin (<root@localhost>) since I had an operational virtual map for users. That connection error disappeared when I added a functioning admin email address. There are other issues, however. (1) Mailman refuses to resolve to a preferred subdomain. If the server's domain is "website.tld", I'd like mailman's homepage to be at "list.website.tld". Mailman insists that I add "website.tld" to the ALLOWED HOSTS, whereas "lists.website.tld" is already there as an ALLOWED HOST (same VPS/IP address nonetheless). The result is that the homepage ends up at "https://website.tld/mailman3/lists" when the desired url is "https://lists.website.tld/mailman3/lists". This is a conflict because the main domain is intended for another service. How do I approach this? (2) See the traceback below: ERROR 2023-01-03 07:40:32,078 27926 django.request Internal Server Error: /mailman3/lists/ Traceback (most recent call last): File "/opt/mailman/venv/lib64/python3.10/site-packages/django/core/handlers/exception.py", line 55, in inner response = get_response(request) File "/opt/mailman/venv/lib64/python3.10/site-packages/django/core/handlers/base.py", line 197, in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/opt/mailman/venv/lib64/python3.10/site-packages/postorius/views/list.py", line 980, in list_index return render(request, template, File "/opt/mailman/venv/lib64/python3.10/site-packages/django/shortcuts.py", line 24, in render content = loader.render_to_string(template_name, context, request, using=using) File "/opt/mailman/venv/lib64/python3.10/site-packages/django/template/loader.py", line 62, in render_to_string return template.render(context, request) File "/opt/mailman/venv/lib64/python3.10/site-packages/django/template/backends/django.py", line 62, in render return self.template.render(context) File "/opt/mailman/venv/lib64/python3.10/site-packages/django/template/base.py", line 173, in render with context.bind_template(self): File "/usr/lib64/python3.10/contextlib.py", line 135, in enter return next(self.gen) File "/opt/mailman/venv/lib64/python3.10/site-packages/django/template/context.py", line 254, in bind_template updates.update(processor(self.request)) File "/opt/mailman/venv/lib64/python3.10/site-packages/django_mailman3/context_processors.py", line 32, in common context["site_name"] = get_current_site(request).name File "/opt/mailman/venv/lib64/python3.10/site-packages/django/contrib/sites/shortcuts.py", line 16, in get_current_site return Site.objects.get_current(request) File "/opt/mailman/venv/lib64/python3.10/site-packages/django/contrib/sites/models.py", line 59, in get_current return self._get_site_by_id(site_id) File "/opt/mailman/venv/lib64/python3.10/site-packages/django/contrib/sites/models.py", line 30, in _get_site_by_id site = self.get(pk=site_id) File "/opt/mailman/venv/lib64/python3.10/site-packages/django/db/models/manager.py", line 85, in manager_method return getattr(self.get_queryset(), name)(*args, **kwargs) File "/opt/mailman/venv/lib64/python3.10/site-packages/django/db/models/query.py", line 650, in get raise self.model.DoesNotExist( django.contrib.sites.models.Site.DoesNotExist: Site matching query does not exist. It seems a migration is missing. How should I approach this?

3 years

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, 4 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

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/

2 years, 7 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

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, 6 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, 3 months

Mailman-users search results for query "Postorius"