Search results for "Postorius" - Mailman-users

Weird response to postings after subscriptions and accounts

by Paul Arenson

I accidentally posted to a test account I had not actually used. Am reposting to my correct account. Sorry to the moderators. 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 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? 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" 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" 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? But here it seems that both make them 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. Before I can move my actual members over from another mailing list provider, I want to make sure what works and what doesn't. Thanks. PS I am running out of test accounts to use to test my own setup. Thanks. paul!!!Subscribe to this list still shows up at the bottom.

6 years, 8 months

MM3 not starting afte an upgrade

by Gelpi Andrea

Hi, to day in a Debian system I upgraded some packages. After the MM3 doesn't start anymore. These are the packages I upgraded: [UPGRADE] clamav:amd64 0.102.3+dfsg-1 -> 0.102.4+dfsg-1 [UPGRADE] clamav-base:amd64 0.102.3+dfsg-1 -> 0.102.4+dfsg-1 [UPGRADE] clamav-daemon:amd64 0.102.3+dfsg-1 -> 0.102.4+dfsg-1 [UPGRADE] clamav-freshclam:amd64 0.102.3+dfsg-1 -> 0.102.4+dfsg-1 [UPGRADE] clamdscan:amd64 0.102.3+dfsg-1 -> 0.102.4+dfsg-1 [UPGRADE] gcc-10-base:amd64 10.1.0-4 -> 10.1.0-6 [UPGRADE] libc-l10n:amd64 2.30-8 -> 2.31-1 [UPGRADE] libclamav9:amd64 0.102.3+dfsg-1 -> 0.102.4+dfsg-1 [UPGRADE] libgcc-s1:amd64 10.1.0-4 -> 10.1.0-6 [UPGRADE] libnss3:amd64 2:3.42.1-1+deb10u2 -> 2:3.42.1-1+deb10u3 [UPGRADE] python3-django-hyperkitty:amd64 1.3.2-1 -> 1.3.2-1.1 [UPGRADE] python3-django-postorius:amd64 1.3.2-2 -> 1.3.2-2.1 [UPGRADE] qemu-guest-agent:amd64 1:3.1+dfsg-8+deb10u5 -> 1:3.1+dfsg-8+deb10u6 MM3 on start up says: Jul 23 13:29:39 posta mailman3[2608]: Traceback (most recent call last): Jul 23 13:29:39 posta mailman3[2608]: File "/usr/bin/mailman", line 11, in <module> Jul 23 13:29:39 posta mailman3[2608]: load_entry_point('mailman==3.2.1', 'console_scripts', 'mailman')() Jul 23 13:29:39 posta mailman3[2608]: File "/usr/lib/python3/dist-packages/click/core.py", line 764, in __call__ Jul 23 13:29:39 posta mailman3[2608]: return self.main(*args, **kwargs) Jul 23 13:29:39 posta mailman3[2608]: File "/usr/lib/python3/dist-packages/click/core.py", line 717, in main Jul 23 13:29:39 posta mailman3[2608]: rv = self.invoke(ctx) Jul 23 13:29:39 posta mailman3[2608]: File "/usr/lib/python3/dist-packages/mailman/bin/mailman.py", line 69, in invoke Jul 23 13:29:39 posta mailman3[2608]: return super().invoke(ctx) Jul 23 13:29:39 posta mailman3[2608]: File "/usr/lib/python3/dist-packages/click/core.py", line 1137, in invoke Jul 23 13:29:39 posta mailman3[2608]: return _process_result(sub_ctx.command.invoke(sub_ctx)) Jul 23 13:29:39 posta mailman3[2608]: File "/usr/lib/python3/dist-packages/click/core.py", line 956, in invoke Jul 23 13:29:39 posta mailman3[2608]: return ctx.invoke(self.callback, **ctx.params) Jul 23 13:29:39 posta mailman3[2608]: File "/usr/lib/python3/dist-packages/click/core.py", line 555, in invoke Jul 23 13:29:39 posta mailman3[2608]: return callback(*args, **kwargs) Jul 23 13:29:39 posta mailman3[2608]: File "/usr/lib/python3/dist-packages/click/decorators.py", line 17, in new_func Jul 23 13:29:39 posta mailman3[2608]: return f(get_current_context(), *args, **kwargs) Jul 23 13:29:39 posta mailman3[2608]: File "/usr/lib/python3/dist-packages/mailman/commands/cli_control.py", line 81, in start Jul 23 13:29:39 posta mailman3[2608]: status, lock = master_state() Jul 23 13:29:39 posta mailman3[2608]: File "/usr/lib/python3/dist-packages/mailman/bin/master.py", line 104, in master_state Jul 23 13:29:39 posta mailman3[2608]: os.kill(pid, 0) Jul 23 13:29:39 posta mailman3[2608]: PermissionError: [Errno 1] Operation not permitted There is a permission error, but on what? Thanks for any help. Regards -- Gelpi ing. Andrea -------------------------------------------------------------- It took the computing power of three C-64s to fly to the Moon. It takes a 486 to run Windows 95. Something is wrong here. --------------------------------------------------------------

5 years, 10 months

My django container keeps getting shutdown by oom-killer

by Hirayama, Pat

Greetings, Ok, I just updated the docker containers that are running my Mailman 3 installation over the weekend. mailman-core is now 3.3.10, with mailman-ngnix at 1.28.0, mailman-postfix at 3.10.5-r0 and mailman-django-uwsgi at "latest". I think I have got everything working normally — messages seem to be processed correctly, and I can access the web pages on the web interface. And I have updated various scripts to use --run-as-root until I can get around to reconfiguring mailman-core to use a non-root user. Anyway, since that time, the EC2 instance that the containers are running on becomes "unreachable", to use AWS's parlance. I can restore functionality by rebooting the instance. According to AWS, this is an application or operating system issue, not their instance. Which means auto-recovery doesn't get activated. This always happens overnight, usually after midnight, though one time it was around 10:40. I don't see any crontab entries that correlate. And the after midnight issues don't always happen at the same time, so it seemed unlikely that it was a crontab job that was causing it I finally looked at the host (rather than the logs of each container) and realized that the oom-killer was killing django-admin. As a temporary workaround, I've limited memory on the mailman-django-uwsgi container to 4 GiB (though, since I just did that this morning, I won't know until after midnight (presumably) if it worked or not), and set the RestartPolicy to always. I'm thinking that this points to a memory leak or some kind? I did have to add a bunch of packages to my Dockerfile when I rebuilt the container, since the last build was like 5 years ago, so I suppose it could be that django is just using more memory than it used to, though at the moment, I see that it is around 1 GiB: FROM python:3.12-alpine3.22 RUN apk update && apk add --no-cache --virtual build-deps \ cargo gcc libffi-dev musl-dev && \ apk add --no-cache gettext postgresql-dev sassc build-base pcre-dev python3-dev libc-dev linux-headers && \ pip install --upgrade pip setuptools wheel && \ pip --no-cache-dir install django-haystack==3.3.0 hyperkitty==1.3.12 \ postorius==1.3.13 psycopg2 uwsgi==2.0.25 whoosh && \ apk update && apk del --no-cache build-deps WORKDIR /opt/mailman/mailman-suite/mailman-suite_project USER mail EXPOSE 8000 CMD ["uwsgi", "--ini", "uwsgi.ini"] Any insights, ideas or assistance would be appreciated. Thanks! Pat Hirayama Pronouns: he/him/his Systems Engineer IT | Systems Engineering - Infrastructure Fred Hutch Cancer Center O 206.667.4856 phirayam(a)fredhutch.org<mailto:phirayam@fredhutch.org>

7 months

Re: SMTPAuthenticationError at /accounts/login/

by Mohsen Masoudfar

Hi Stephen, Thank you for the hint. I was focused too much on the documentation and was looking for the answer in the wrong place. Problem fixed. My problem started with "SMTP authentication not supported" and after fixing that, which was a Postfix parameter, I got this issue and was also looking in Postfix or Django configuration for the answer. This problem is solved and I wished there was a chance to update the documentation, so that these sort of information could be added in the documentation for other people who try to use mailman3. Thanks Mohsen -----Original Message----- From: Stephen J. Turnbull <turnbull.stephen.fw(a)u.tsukuba.ac.jp> Sent: Thursday, April 9, 2020 4:06 AM To: Mohsen Masoudfar <mmasoudf(a)aaas.org> Cc: mailman-users(a)mailman3.org Subject: [MM3-users] SMTPAuthenticationError at /accounts/login/ [EXTERNAL EMAIL] mmasoudf(a)aaas.org writes: > I have setup the stack according to: > Mailman Suite Documentation. Release 3.3 PDF file. > I configured > EMAIL_HOST_USER and > EMAIL_HOST_PASSWORD > in Django settings.py. I could not find the place that I might > configure it for Postfix I think it helps to start thinking about it from the other end. That is, Postfix is the mail server for all users on a multiuser system. Therefore in "normal" configurations it will use the authentication mechanisms provided by the host operating system.[1] You need to have a user for Mailman in any case, typically called "mailman" or "list".[2] Once you've configured a user for Mailman on the Postfix side, you use that user and authentication data for Mailman core, Postorius, and HyperKitty to send mail via Postfix. > I am running the site on AWS and to be able to use AWS mail-servers > I have to define following parameter for AWS: > smtp_sasl_password_maps which points to a hash for AWS 'ACCESS KEY > ID' and 'SECRET ACCESS KEY' I don't think that has anything to do with the Mailman-to-Postfix side of things; that's for Postfix to send to AWS's mail exchanger (aka MX). Steve Footnotes: [1] It may also be possible to create Postfix-only "virtual" users who have no existence as far as the OS is concerned, but I don't know anything about that. [2] I haven't thought carefully about whether using Mailman's user in Django would be a security risk, but as long as it only has access to Mailman I don't see how it can do more harm than Mailman itself can, and I don't see why it would be more subject to exploitation than Mailman itself is. Anybody with security chops who wants to weigh in, please do.

6 years, 2 months

Re: how to administrate mailman3 in CLI ?

by testeur

Sorry. I didn't see in the good place. when i see parameters here : https://URL/mailman3/postorius/accounts/per-subscription-preferences/ the options or the specific language chosen (not for the ui) for the list is finally changing when i use the code used before... i should use shell with mailman user. ok i note it. I ve seen this link about python script to manage mailman3 by shell : https://fog.ccsf.edu/~msapiro/scripts/ (thx you) Regards, On 23/09/2023 17:33, Mark Sapiro wrote: > On 9/23/23 07:40, testeur via Mailman-users wrote: >> >> |# mailman shell -l testlist(a)domain.tld | > > It looks like you are running `mailman shell` as `root`. You should > always run mailman commands including starting mailman as the Mailman > user, never as root. Running thing as root can create things that > later can't be read by the mailman user. > >> ||>>> from mailman.interfaces.action import Action >>> for mbr in >> m.members.members: mbr.moderation_action = Action.defer |||commit()| >> >> |||>>> from mailman.interfaces.action import Action |||||||>>> >> english = getUtility(ILanguageManager).get('en')| >>> for mbr in >> m.members.members: || 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|commit()|| > > > I'm not sure what the above actually says. The interaction should look > like > ``` > >>> from mailman.interfaces.action import Action > >>> english = getUtility(ILanguageManager).get('en') > >>> for mbr in m.members.members: > ... 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 > ... > >>> commit() > ``` > Actually, importing Action is not necessary as it is among the things > defined by default in `mailman shell` in interactive mode. > >> Before the shell command, the web interface was with an other >> language (i tested with italian one) and other options preferences, >> but after the shell command, after a web interface refresh, it >> doesn't change. > > > The above shell interaction sets the preferred_language for all list > members to english. This has nothing to do with the language for the > web UI. This is set by Django. See > <https://docs.djangoproject.com/en/4.2/topics/i18n/translation/#how-django-d…>. > >

2 years, 8 months

Lessons learned and a couple little gotcha for newbies

by William Oliver

I just finished, with great help from Mark Sapiro on the list, a new installation of mailman3. I used the instructions at https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/insta… and https://docs.mailman3.org/en/latest/install/virtualenv.html There were a couple of gotchas that I didn't see well documented. 1) I got the error django.template.library.InvalidTemplateLibrary: Invalid template library specified. ImportError raised when trying to load 'hyperkitty.templatetags.decorate': cannot import name 'escape_html' from 'mistune.scanner' (/opt/mailman/venv/lib/python3.9/site- packages/mistune/scanner.py) when I ran 'mailman-web migrate' The fix was trivial: I just added the lines: from mistune.util import escape_html from mistune.util import escape_url to /opt/mailman/venv/lib/python3.9/site-packages/mistune/scanner.py It's not hard to search for those definitions, but if someone doesn't know a smattering of python, it might not be obvious. 2) Similarly, migrate (using postgres) also gave the error: File "/opt/mailman/venv/lib/python3.9/site- packages/django/db/backends/postgresql/utils.py", line 6, in utc_tzinfo_factory raise AssertionError("database connection isn't set to UTC") I was able to find a discusson of this one at https://stackoverflow.com/questions/68024060/assertionerror-database-connec… which had me downgrade to an older version of psycopg2-binary: pip install psycopg2-binary==2.8.6 There might be a different fix, but this worked. 3) When I ran the test "uwsgi --ini /etc/mailman3/uwsgi.ini" I got the error: ModuleNotFoundError: No module named 'settings' This was also trivially fixed by adding the path: export PYTHONPATH=$PYTHONPATH:/etc/mailman3 in /opt/mailman/.bashrc 4) Sometimes when I rebooted the machine, when I ran 'systemctl start mailman3' I'd get the error that mailman wouldn't start because the lock was stll there. I never could figure out where the lock was, so I worked around it by replacing ExecStart=/opt/mailman/venv/bin/mailman start with ExecStart=/opt/mailman/venv/bin/mailman start --force in /etc/systemd/system/mailman3.service I'm sure there's something bad about doing that, but it works for me, so far. 5) I had a problem with mail to outside people not being delivered while mail to the local host was delivered. It turned out that this was because in my mailman.cfg I had "smtp_host:my.listserver.tld when it should have been localhost. The error was "relay access denied." To fix this, I had to add my.listserver.tld to "mynetworks" in /etc/postfix/main.cf, ie change: mynetworks = 127.0.0.0/8 10.0.0.0/24 to mynetworks = 127.0.0.0/8 10.0.0.0/24 111.222.333.444 <--- my ip address However, Mark Sapiro (a God) told me this was because I had changed a line in the [mta] section of mailman.cfg. I had changed smtp_host: localhost to smtp_host: mydomain.tld Here's the thing. The reason I did this was because the instructions at https://docs.mailman3.org/en/latest/config-core.html give this as their model: [mta] incoming: mailman.mta.postfix.LMTP outgoing: mailman.mta.deliver.deliver lmtp_host: mail.example.com lmtp_port: 8024 smtp_host: mail.example.com <---- not localhost smtp_port: 25 The instructions are good, but there are a few places where one size does not fit all, I guess. 6) A second error in delivery to outside addresses resulted in an "Access denied" error. A search on the internet revealed that this had to do with (for me) smtpd_recipient_restrictions in postfix. See, for instance: https://know.mailsbestfriend.com/postfix_error_relay_access_denied_noqueue_… Changing this fixed things. I'm not sure, but I think this shows up mostly with installations that include dovecot. 7) If you are using virtual domains in postfix, you need to use the "unusual postfix configuration" in https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/mta.h… virtual_alias_maps = hash:/path-to-mailman/var/data/postfix_vmap 8) You need to manually set the local virtual host for mailman3. Somehow, I got the impression from the installation instructions that this was done automagically to the default x.mydomain.tld if your domain is mydomain.tld. It doesn't. 9) Follow the instructions verbatim, and follow them in the order provided. I installed postfix and nginx out of order, and it did OK, but once you get into the python virtual environment, it is easy to miss something if you don't do it in order. 10) Jot down lots of notes. This is one of the more complicated installations I've done, mostly because it involved configuring a zillion packages to talk to each other: Postfix, nginx, postorius, hyperkitty, django, and others (I'd never heard of "whoosh" or "sass" for instance). All of these can be unforgiving with configuration errors. The default installation instructions assumed a number of packages I'd never used. I'm an apache/dovecot/mysql kind of person, and I had to switch to nginx/postgres to use the instructions as the written defaults. I'm sure I could have used apache and mysql, but it would mean trying to figure out what didn't work without following the installations verbatim. I'd never even heard of postorius, hyperkitty, or django. So, it was easy to get confused a bit. Taking notes of changes I made was important in being able to back out of disastrous choices. Plus, once I'd installed it on one machine, I sat down and installed it on another machine, and it was very useful to have written down how I fixed an issue when it came up again -- and I didn't remember exactly what I had done. 11) Make multiple sequential backups of configuration files. I went down a couple of paths I shouldn't have gone down. For instance, with the vmap issue, I got it in my head that it was a postfix configuration issue, not a mailman issue. So I kept changing things in postfix. Once I was told that it was in *mailman* I had to set the virtual host, I needed to back out of about 8 tweaks I'd made to main.cf in /etc/postfix. If I hadn't been making main.cf.backup.01, main.cf.backup.02, etc. I would have had to spend another few hours trying to remember what inappropriate changes I had made. This is particularly true for me because I am not a great typist, and when I try to retype something to back out, there's a reasonable chance I'll mistype something and it still won't work. With these backups, I don't have both manually back out of things *and* proof my typing again and again. It's a lot easier to delete backups once things are working than to try to remember what you did late at night after a couple of bourbons. 12) Choose one set of installation instructions and follow it. Don't try to mix instructions from different tutorials unless you really know what you are doing. I didn't. For instance, there's a different set of mailman3 installation instructions at: https://wiki.list.org/DOC/Howto_Install_Mailman3_On_Debian10 It does things a little differently. It's useful to look at that when you are debugging why something's not working, but you can get into some trouble trying to do both installations at the same time -- which I found myself doing when something wasn't working. It didn't help. billo

4 years, 5 months

Re: Change Member's Address

by Dennis Putnam

5 months

Re: Re-send subscription response and file permission error in queue

by Mark Sapiro

On 9/8/20 10:56 PM, accounts-mailman(a)holbrook.no wrote: > A user sent subscription request to the `..-join@` address of a list. Email domain wasn't set up properly, so response got rejected. Now, if the user tries to send another request, no reponse comes back. In the log I find a python stack trace saying subscription already pending. > > ``` > Sep 08 10:32:44 2020 (19918) Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/mailman/core/runner.py", line 171, in _one_iteration > self._process_one_file(msg, msgdata) > File "/usr/lib/python3/dist-packages/mailman/core/runner.py", line 264, in _process_one_file > keepqueued = self._dispose(mlist, msg, msgdata) > File "/usr/lib/python3/dist-packages/mailman/runners/command.py", line 196, in _dispose > mlist, msg, msgdata, parts, results) > File "/usr/lib/python3/dist-packages/mailman/commands/eml_membership.py", line 104, in process > ISubscriptionManager(mlist).register(subscriber) > File "/usr/lib/python3/dist-packages/mailman/app/subscriptions.py", line 520, in register > list(workflow) > File "/usr/lib/python3/dist-packages/mailman/app/workflow.py", line 69, in __next__ > return step() > File "/usr/lib/python3/dist-packages/mailman/app/subscriptions.py", line 227, in _step_sanity_checks > raise SubscriptionPendingError(self.mlist, self.address.email) > mailman.interfaces.subscriptions.SubscriptionPendingError > ``` I'll look at this when I get some time. I'm still catching up after being off line for 12 days. > Furthermore I am getting a permission denied error in the attempt of shunting the message, which I don't quite understand because the folder has user `list` group `list` and `700` mode: > > ``` > Sep 08 10:25:29 2020 (19918) SHUNTING: 1599553529.9889646+88be5afa0bf3111a83e68cc97ce2000723ad93fd > Sep 08 10:29:49 2020 (19918) Uncaught runner exception: [Errno 13] Permission denied: '/var/lib/mailman3/queue/command/1599553789.306307+6fee74af69263553b5ffd0e73cc095ab651bd855.pck' > Sep 08 10:29:49 2020 (19918) Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/mailman/core/runner.py", line 156, in _one_iteration > msg, msgdata = self.switchboard.dequeue(filebase) > File "/usr/lib/python3/dist-packages/mailman/core/switchboard.py", line 150, in dequeue > with open(filename, 'rb') as fp: > PermissionError: [Errno 13] Permission denied: '/var/lib/mailman3/queue/command/1599553789.306307+6fee74af69263553b5ffd0e73cc095ab651bd855.pck' > ``` > > How can I remove the pending subscription, or re-send the response email? In Postorius, pull down Subscription Requests and select Pending Confirmation and delete the request. > And what could be the cause of the permission error? Mailman can't read the /var/lib/mailman3/queue/command/1599553789.306307+6fee74af69263553b5ffd0e73cc095ab651bd855.pck file. This is strange since it wrote it, but check the modes and user/group of all the directories in the path and the file itself. Could it be a SELinux or apparmor issue? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 9 months

Re: multiple sites on a mailman3 server question

by David Newman

> On Dec 29, 2021, at 08:49, William Oliver <billo(a)billoblog.com> wrote: > > On Tue, 2021-12-28 at 18:23 -0800, David Newman wrote: >>> >>> [snip] >>> I'm using nginx >> I'd asked about this a few weeks ago for a MM3 host running Ngnix >> with a >> few virtual domains, one of which runs Roundcubemail as its default. >> >> Mark Sapiro suggested the following, and it seems to be working OK. >> You'll need these lines in the Nginx config file for each virtual >> host >> you define. >> >> # begin mailman3 stuff >> >> location /static/ { >> alias /opt/mailman/web/static/; >> } >> > [snip] > > > > No joy. This just makes it kind of work as the mailman interface when > it gets rewritten. > > My problem is that the url is getting referred to > domainname/mailman3/lists even when I don't want it to. That sounds like an nginx configuration problem, not a Mailman3 issue. One assumption in the MM3 web setup docs is that MM3/Django/Postorius/Hyperkitty are the only web services running. If they’re not, and there are other services running, you’ll need to tell Nginx where they are. The setup I provided is an excerpt and covers only how to point to MM3 in such a scenario. It does not cover how to point to something else as root at, say, www.domain.tld. This is off-topic for a Mailman3 list, but maybe check your default files in the sites-available directory, and also anything they point to, paying particular attention to where / points and which root directory you’re using. Same thing with any other config files in that directory. dn > Adding these > changes just (partially) loads the mailman3 interface when it gets > rewritten. > > What I'm trying to figure out is where uwsgi yanks control from nginx > and does the rewriting. Pulling that proxypass stuff out will stop > mailman3 from coming up, and adding it allows mailman3 to show its > interface, but the address gets referred regardless. > > Somehow I need to tell uwsgi to ignore www.domain.com *or* somehow tell > nginx not to push it to port 8000. But I don't see where nginx is > getting told to go to 8000 in the www.domain.com section. > > billo > > > > > > > _______________________________________________ > 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/

4 years, 5 months

ValueError: ...:EVP_DigestInit_ex:disabled for fips

by Ralf Wiegand

(venv-3.6) [root@maildev mailman-suite_project]# python manage.py migrate Operations to perform: Apply all migrations: account, admin, auth, contenttypes, django_mailman3, django_q, hyperkitty, openid, postorius, sessions, sites, socialaccount Running migrations: Applying contenttypes.0001_initial...Traceback (most recent call last): File "manage.py", line 10, in <module> execute_from_command_line(sys.argv) File "/opt/mailman/venv-3.6/lib64/python3.6/site-packages/Django-2.2.12-py3.6.egg/django/core/management/__init__.py", line 381, in execute_from_command_line utility.execute() File "/opt/mailman/venv-3.6/lib64/python3.6/site-packages/Django-2.2.12-py3.6.egg/django/core/management/__init__.py", line 375, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/opt/mailman/venv-3.6/lib64/python3.6/site-packages/Django-2.2.12-py3.6.egg/django/core/management/base.py", line 323, in run_from_argv self.execute(*args, **cmd_options) File "/opt/mailman/venv-3.6/lib64/python3.6/site-packages/Django-2.2.12-py3.6.egg/django/core/management/base.py", line 364, in execute output = self.handle(*args, **options) File "/opt/mailman/venv-3.6/lib64/python3.6/site-packages/Django-2.2.12-py3.6.egg/django/core/management/base.py", line 83, in wrapped res = handle_func(*args, **kwargs) File "/opt/mailman/venv-3.6/lib64/python3.6/site-packages/Django-2.2.12-py3.6.egg/django/core/management/commands/migrate.py", line 234, in handle fake_initial=fake_initial, File "/opt/mailman/venv-3.6/lib64/python3.6/site-packages/Django-2.2.12-py3.6.egg/django/db/migrations/executor.py", line 117, in migrate state = self._migrate_all_forwards(state, plan, full_plan, fake=fake, fake_initial=fake_initial) File "/opt/mailman/venv-3.6/lib64/python3.6/site-packages/Django-2.2.12-py3.6.egg/django/db/migrations/executor.py", line 147, in _migrate_all_forwards state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial) File "/opt/mailman/venv-3.6/lib64/python3.6/site-packages/Django-2.2.12-py3.6.egg/django/db/migrations/executor.py", line 245, in apply_migration state = migration.apply(state, schema_editor) File "/opt/mailman/venv-3.6/lib64/python3.6/site-packages/Django-2.2.12-py3.6.egg/django/db/migrations/migration.py", line 124, in apply operation.database_forwards(self.app_label, schema_editor, old_state, project_state) File "/opt/mailman/venv-3.6/lib64/python3.6/site-packages/Django-2.2.12-py3.6.egg/django/db/migrations/operations/models.py", line 530, in database_forwards getattr(new_model._meta, self.option_name, set()), File "/opt/mailman/venv-3.6/lib64/python3.6/site-packages/Django-2.2.12-py3.6.egg/django/db/backends/base/schema.py", line 367, in alter_unique_together self.execute(self._create_unique_sql(model, columns)) File "/opt/mailman/venv-3.6/lib64/python3.6/site-packages/Django-2.2.12-py3.6.egg/django/db/backends/base/schema.py", line 126, in execute sql = str(sql) File "/opt/mailman/venv-3.6/lib64/python3.6/site-packages/Django-2.2.12-py3.6.egg/django/db/backends/ddl_references.py", line 194, in __str__ return self.template % self.parts File "/opt/mailman/venv-3.6/lib64/python3.6/site-packages/Django-2.2.12-py3.6.egg/django/db/backends/ddl_references.py", line 103, in __str__ return self.create_index_name(self.table, self.columns, self.suffix) File "/opt/mailman/venv-3.6/lib64/python3.6/site-packages/Django-2.2.12-py3.6.egg/django/db/backends/base/schema.py", line 1049, in create_unique_name return self.quote_name(self._create_index_name(*args, **kwargs)) File "/opt/mailman/venv-3.6/lib64/python3.6/site-packages/Django-2.2.12-py3.6.egg/django/db/backends/base/schema.py", line 884, in _create_index_name hash_suffix_part = '%s%s' % (names_digest(table_name, *column_names, length=8), suffix) File "/opt/mailman/venv-3.6/lib64/python3.6/site-packages/Django-2.2.12-py3.6.egg/django/db/backends/utils.py", line 221, in names_digest h = hashlib.md5() *ValueError: error:060800A3:digital envelope routines:EVP_DigestInit_ex:disabled for fips* Hello group, I am running into this error. any idea what is going wrong here? Help is greatly appreciated. Ralf

6 years

Mailman-users search results for query "Postorius"