Search results for "sapiro" - lists.mailman3.org

[MM3-users] Re: Newbie hyperkitty question

by Stephen Daniel

Thanks. Very helpful. On Tue, Jan 11, 2022 at 2:03 PM Mark Sapiro <mark(a)msapiro.net> wrote: > On 1/11/22 8:27 AM, Stephen Daniel wrote: > > Mailman users -- > > > > I am setting up a new mailman3 installation, and this is my first > > experience with the suite. All of the software is up and running, but I > > cannot tell if hyperkitty is actually running. > > > In Postorius, in the list's `info` view can you click the Archives > button and see archived messages? That's HyperKitty. > > If the messages aren't there with the hyperkitty archiving option > enabled, check `mailman.log` for why. > > Also do messages from the list have an Archived-At: header? > > > > When I look at my test mailing list, two archive options are available, > > hyperkitty and "prototype", and both are enabled. I can see that my > email > > is being archived, but I think "prototype" is what is doing the > archiving. > > I see that a test message will end up in > > > /opt/mailman/mm/var/archives/prototype/<LISTNAME>@<LISTDOMAIN.org>/new/164.... > > and nowhere else. This suggests that "prototype" is archiving, but > > hyperkitty is not. > > > No this says the prototype archiver is working. It says nothing about > Hyperkitty. > > > > So, this opens up a raft of questions on hyperkitty: > > > David Newman has answered some of this, but ... > > > > - How do I tell if hyperkitty is actually running? > > > It doesn't actually run. it is a Django web UI and a web API that serves > things on request. > > > > - Does hyperkitty have a web-UI for admins or users? How would I > access > > it? > > See above. > > > > - I can not find any documentation on hyperkitty, other than > > installation instructions and change logs. Does documentation exist? > > No, not really. > > > > - How do I set policies on how long archives are kept? > > - Assuming I want to back up my archives, what do I need to back up? > > > Messages are kept forever unless you do something to delete them. > HyperKitty's messages are stored in the database configured in the > DATABASES setting in your Django settings. How you backup the database > depends on the database manager. You already found the prototype > archiver's messages. > > > -- > Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, > San Francisco Bay Area, California better use your sense - B. Dylan > _______________________________________________ > Mailman-users mailing list -- mailman-users(a)mailman3.org > To unsubscribe send an email to mailman-users-leave(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ >

4 years, 7 months

[MM3-users] Re: debian's 3.2.1 mailman package too unreliable in production - Mail held occasionally causes server errors, and unexplained queue/bad messages -

by Mark Sapiro

On 10/20/20 6:30 PM, Alex Schuilenburg via Mailman-users wrote: > We have an issue where a mailing list has had a message sent to it from > a non-member, so the message has been held, but when the list owner or > I attempt to list the held messages for the list we get a Server Error: > "An error occurred while processing your request.". Details of the server error should be in Django's log which I think in the Debian package is named mailmansuite.log. > I see the mail being held in the mailman log with the non-subscriber > reason, and followed the suggestions in > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/… > which worked to look at and discard that held message. The problem > is, there are more and we have over 900 mailing lists > > FYI, we are running:Mailman Core VersionGNU Mailman 3.2.1 (La Villa > Strangiato)Mailman Core API Version3.0Mailman Core Python Version3.7.3 > (default, Jul 25 2020, 13:03:44) [GCC 8.3.0] > > So we are looking at setting up a virtualenv to run the latest mailman3 > 3.3.1 as the 3.2.1 package from debian is looking unstable - barely > usable. Actually, the latest Mailman core is 3.3.2rc2 with the final due by the end of October. While I would never discourage people from installing Mailman from our source distributions, without more understanding of your actual errors, it is difficult to know if that will help. > For example, while poking around I found 641 messages in > queue/bad , but when I inspect them they look fine. If, as mentioned > elsewhere, I rename them to .pck, put them in queue/shunt, and "mailman > unshunt" the mail finally gets delivered. Why work now? Some kind of > transient bug? If they are in queue/bad because of permissions errors, it is not surprising that moving them to .pck files in queue/shunt is successful. > Is 3.3.1 the way to go? > > On that last error, I've now enabled debug and hope to catch why > messages are being dropped into queue/bad instead of being delivered. > Already I have found errors in the mailman log such as: > > PermissionError: [Errno 13] Permission denied: > '/var/lib/mailman3/queue/out/1603233694.919073+d907eb9512ce11fda515c19d > 723537fc4cb15da2.pck'Oct 20 23:41:35 2020 (9793) Skipping and > preserving unparseable message: > 1603233694.919073+d907eb9512ce11fda515c19d723537fc4cb15da2Oct 20 > 23:41:35 2020 (9787) Uncaught runner exception: [Errno 13] Permission > denied: > '/var/lib/mailman3/queue/archive/1603233694.9209244+a0c1f3aab51d3d202aa > 37911ab453f094b50b450.pck'Oct 20 23:41:35 2020 (9793) Uncaught runner > exception: [Errno 13] Permission denied: > '/var/lib/mailman3/queue/out/1603233694.9260252+138142eeb15b16b5da16934 > 954d1d3aeb1331198.pck'Oct 20 23:41:35 2020 (9793) Traceback (most > recent call last): File "/usr/lib/python3/dist- > packages/mailman/core/runner.py", line 158, 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/out/1603233694.9260252+138142eeb15b16b5da16934 > 954d1d3aeb1331198.pck'Oct 20 23:41:35 2020 (9790) Uncaught runner > exception: [Errno 13] Permission denied: > '/var/lib/mailman3/queue/in/1603233694.9129462+8be9ab12e5dfeab086a1ab8b > 3917550aea313505.pck'Oct 20 23:41:35 2020 (9793) Skipping and > preserving unparseable message: > 1603233694.9260252+138142eeb15b16b5da16934954d1d3aeb1331198Oct 20 > 23:41:35 2020 (9793) Uncaught runner exception: [Errno 13] Permission > denied: > '/var/lib/mailman3/queue/out/1603233694.9269004+5f8572edfb07e0e28b9f0b7 > 928a1184b8c8048ba.pck'Oct 20 23:41:35 2020 (9793) Traceback (most > recent call last): File "/usr/lib/python3/dist- > packages/mailman/core/runner.py", line 158, 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/out/1603233694.9269004+5f8572edfb07e0e28b9f0b7 > 928a1184b8c8048ba.pck'Oct 20 23:41:35 2020 (9793) Skipping and > preserving unparseable message: > 1603233694.9269004+5f8572edfb07e0e28b9f0b7928a1184b8c8048ba Were the runners all running as user `list` when the above errors occur. > The mailman3 user, "list", owns and has full rights all the way down: > # ls -ld /var/lib/mailman3/queue/*drwxrwx--- 2 list list 4096 Oct 21 > 01:45 /var/lib/mailman3/queue/archivedrwxrwx--- 2 list list 77824 Oct > 21 00:15 /var/lib/mailman3/queue/baddrwxrwx--- 2 list list 4096 Oct 19 > 10:44 /var/lib/mailman3/queue/bouncesdrwxrwx--- 2 list list 4096 > Oct 5 17:18 /var/lib/mailman3/queue/commanddrwxrwx--- 2 list > list 4096 Oct 21 00:00 /var/lib/mailman3/queue/digestdrwxrwx--- 2 list > list 4096 Oct 21 00:20 /var/lib/mailman3/queue/indrwxrwx--- 2 list > list 4096 Aug 11 18:44 /var/lib/mailman3/queue/nntpdrwxrwx--- 2 list > list 4096 Oct 21 01:45 /var/lib/mailman3/queue/outdrwxrwx--- 2 list > list 4096 Oct 21 01:45 /var/lib/mailman3/queue/pipelinedrwxrwx--- 2 > list list 4096 Aug 11 18:44 /var/lib/mailman3/queue/retrydrwxrwx--- 2 > list list 69632 Oct 21 01:45 /var/lib/mailman3/queue/shuntdrwxrwx--- 2 > list list 4096 Oct 21 00:20 /var/lib/mailman3/queue/virgin > so I'm kinda running out of options why this particular problem is > happening. Any pointers? Or just toss the mailman 3.2.1 debian > package out and go for a virtualenv 3.3.1 mailman? Unexplained permissions errors are often SELinux issues. Is SELinux enabled? If so, have you tried disabling it? -- 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

[MM3-users] Re: digests are created but not sent out

by "Jörg M. Schulz"

Arrgh, you got it. There are messages in the shunt directories. But, also in mailman log. Uncaught runner exception: 'ascii' codec can't encode character '\xdf' in position 157: ordinal not in range(128) Jan 09 12:24:06 2019 (17491) Traceback (most recent call last): File "/usr/lib/python3/dist-packages/mailman/core/runner.py", line 173, in _one_iteration self._process_one_file(msg, msgdata) File "/usr/lib/python3/dist-packages/mailman/core/runner.py", line 266, in _process_one_file keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/lib/python3/dist-packages/mailman/runners/digest.py", line 324, in _dispose mime = mime_digest.finish() File "/usr/lib/python3/dist-packages/mailman/runners/digest.py", line 185, in finish footer = MIMEText(footer_text.encode(self._charset), so the footers may not contain special characters. Will review this one. This is the only thing I hate with python... > Am 09.01.2019 um 18:02 schrieb Mark Sapiro <mark(a)msapiro.net>: > > On 1/9/19 1:37 AM, "Jörg M. Schulz" wrote: >> >> Normal, non-digest messages are sent correctly. Administrative messages as well. >> >> Using GNU Mailman 3.2.0 (La Villa Strangiato) >> >> Where could I look for errors / stuck queues? >> >> /var/lib/mailman3/lists >> /var/lib/mailman3/lists/mailman.unswolke.de >> /var/lib/mailman3/lists/mailman.unswolke.de/digest.2.3.mmdf >> /var/lib/mailman3/lists/mailman.unswolke.de/digest.3.2.mmdf >> /var/lib/mailman3/lists/mailman.unswolke.de/digest.4.2.mmdf >> /var/lib/mailman3/lists/mailman.unswolke.de/digest.2.6.mmdf >> /var/lib/mailman3/lists/mailman.unswolke.de/digest.2.4.mmdf >> /var/lib/mailman3/lists/mailman.unswolke.de/digest.4.1.mmdf >> /var/lib/mailman3/lists/mailman.unswolke.de/digest.3.1.mmdf >> /var/lib/mailman3/lists/mailman.unswolke.de/digest.mmdf >> /var/lib/mailman3/lists/mailman.unswolke.de/digest.4.3.mmdf > > > When a digest is to be sent by 'mailman digests', the digest.mmdf file > is renamed to digest.x.y.mmdf (x and y are the volume and issue numbers) > and an entry placed in queue/digests to send that digest. The digest > runner then picks up that entry, prepares the digest, queues it in > queue/virgin to be sent to the recipients if any and removes the > digest.x.y.mmdf file. > > Since the digest.x.y.mmdf files are not removed, either the digest > runner is not running at all in which case there will still be entries > in queue/digests or it is encountering an error in processing in which > case there should be messages with tracebacks in Mailman's error log and > probably messages in queue/shunt. > > -- > Mark Sapiro <mark(a)msapiro.net <mailto:mark@msapiro.net>> The highway is for gamblers, > San Francisco Bay Area, California better use your sense - B. Dylan > _______________________________________________ > Mailman-users mailing list -- mailman-users(a)mailman3.org <mailto:mailman-users@mailman3.org> > To unsubscribe send an email to mailman-users-leave(a)mailman3.org <mailto:mailman-users-leave@mailman3.org> > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/>

7 years, 7 months

[MM3-users] Re: new list not working

by Christian

There are no such messages as you describe. After turning on debugging I got this from a test message sent to the new list: Mar 10 04:39:51 2023 (1005) Available AUTH mechanisms: LOGIN(builtin) PLAIN(builtin) Mar 10 04:39:51 2023 (1005) Peer: ('127.0.0.1', 51982) Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) handling connection Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) >> b'LHLO zarathustra.ccalternatives.org' Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) >> b'MAIL FROM:<christian(a)naturalintelligence.us> SIZE=3499' Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) sender: christian(a)naturalintelligence.us Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) >> b'RCPT TO:<redlatinleg(a)lists.ccalternatives.org>' Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) recip: redlatinleg(a)lists.ccalternatives.org Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) >> b'DATA' Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) >> b'QUIT' Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) connection lost Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) Connection lost during _handle_client() -----Original Message----- From: Mark Sapiro <mark(a)msapiro.net> Sent: Thursday, March 9, 2023 7:51 PM To: mailman-users(a)mailman3.org Subject: [MM3-users] Re: new list not working On 3/9/23 13:26, Christian via Mailman-users wrote: > Smtp.log > > ++++++ > > Mar 09 20:57:09 2023 (9401) Available AUTH mechanisms: LOGIN(builtin) > PLAIN(builtin) > > Mar 09 20:57:09 2023 (9401) Peer: ('127.0.0.1', 35982) > > Mar 09 20:57:09 2023 (9401) ('127.0.0.1', 35982) handling connection > > Mar 09 20:57:09 2023 (9401) ('127.0.0.1', 35982) >> b'LHLO zarathustra.ccalternatives.org' > > Mar 09 20:57:09 2023 (9401) ('127.0.0.1', 35982) >> b'MAIL FROM:christian@naturalintelligence.us SIZE=3653' > > Mar 09 20:57:09 2023 (9401) ('127.0.0.1', 35982) sender: > christian(a)naturalintelligence.us > > Mar 09 20:57:09 2023 (9401) ('127.0.0.1', 35982) >> b'RCPT TO:redlatinleg@lists.ccalternatives.org' > > Mar 09 20:57:09 2023 (9401) ('127.0.0.1', 35982) recip: > redlatinleg(a)lists.ccalternatives.org > > Mar 09 20:57:09 2023 (9401) ('127.0.0.1', 35982) >> b'DATA' > > Mar 09 20:57:09 2023 (9401) ('127.0.0.1', 35982) >> b'QUIT' > > Mar 09 20:57:09 2023 (9401) ('127.0.0.1', 35982) connection lost > > Mar 09 20:57:09 2023 (9401) ('127.0.0.1', 35982) Connection lost > during _handle_client() > What else is in the smtp.log? There should be messages like <timestamp> (<pid>) <message-id> smtp to redlatinleg(a)lists.ccalternatives.org for nn recips, completed in n.nnn seconds <timestamp> (<pid>) <message-id> post to redlatinleg(a)lists.ccalternatives.org from christian(a)naturalintelligence.us nnn bytes If there aren't, try setting [logging.smtp] level: debug in mailman.cfg, restarting Mailman core and see what you then get in smtp.log. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan _______________________________________________ Mailman-users mailing list -- mailman-users(a)mailman3.org To unsubscribe send an email to mailman-users-leave(a)mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/ WPMR4JUQOQ6FMT24V3W6WWJQQU4Q6O7E/ This message sent to csa(a)web-analysts.net

3 years, 5 months

[MM3-users] Re: can't get mail into mailman3 in docker

by matthew＠alberti.us

Sorry for the double-tap. Apparently https://github.com/maxking/docker-mailman/pull/441 changed the behavior that I said was the default. We might need to see your docker-compose.yaml, with sensitive info removed, to know more about your setup. - Matt Alberti -----Original Message----- From: matthew(a)alberti.us <matthew(a)alberti.us> Sent: Saturday, August 7, 2021 8:21 PM To: mailman-users(a)mailman3.org Subject: [MM3-users] Re: can't get mail into mailman3 in docker I use the docker-mailman setup. Below is the partial contents of my mailman-extra.cfg. I think by default, you would use the Docker assigned private network IP addresses for communicating with the containers. In my setup, 172.19.199.1 is the host (where postfix is) and 172.19.199.2 is mailman-core... # EMAIL SERVER / MTA CONFIGURATION [mta] incoming: mailman.mta.postfix.LMTP outgoing: mailman.mta.deliver.deliver lmtp_host: 172.19.199.2 lmtp_port: 8024 smtp_host: 172.19.199.1 smtp_port: 25 configuration: /etc/postfix-mailman.cfg This is all really going to depend on your particular setup. I'm late to the thread; but let me know if that improves the situation. - Matt Alberti -----Original Message----- From: Mark Sapiro <mark(a)msapiro.net> Sent: Saturday, August 7, 2021 2:04 AM To: mailman-users(a)mailman3.org Subject: [MM3-users] Re: can't get mail into mailman3 in docker On 8/6/21 11:28 AM, bob B wrote: > I see nothing for today when the error happens in > /opt/mailman/var/logs/smtp.log > > But the log has a bunch of these, but these stopped around the 4th > > Aug 04 19:46:04 2021 (28) Available AUTH mechanisms: LOGIN(builtin) > PLAIN(builtin) Aug 04 19:46:04 2021 (28) Peer: ('127.0.0.1', 33912) > Aug 04 19:46:04 2021 (28) ('127.0.0.1', 33912) handling connection Aug > 04 19:46:04 2021 (28) ('127.0.0.1', 33912) EOF received Aug 04 > 19:46:04 2021 (28) ('127.0.0.1', 33912) Connection lost during > _handle_client() Aug 04 19:46:04 2021 (28) ('127.0.0.1', 33912) > connection lost These are normal messages from the startup of Mailman's lmtp runner. If you correlate these with mailman.log, you'll probably see the server starting at these times. The fact that there is nothing in this log correlating with the Postfix message 2021-08-06T09:08:41.974225-04:00 dockerhost postfix/lmtp[109783]: D630B3083ED0: to=<test(a)mailman-docker.###.####>, relay=localhost[127.0.0.1]:8024, delay=0.11, delays=0.05/0.02/0.04/0, dsn=4.4.2, status=deferred (lost connection with localhost[127.0.0.1] while receiving the initial server greeting) seems to say that Postfix isn't really connecting to Mailman's lmtp and this is consistent with netstat -l not showing something listening on port 8024. I note you have lmtp_host: localhost in the [mta] section in mailman-extra.cfg. Try changing that to lmtp_host: 127.0.0.1 -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan _______________________________________________ Mailman-users mailing list -- mailman-users(a)mailman3.org To unsubscribe send an email to mailman-users-leave(a)mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ _______________________________________________ Mailman-users mailing list -- mailman-users(a)mailman3.org To unsubscribe send an email to mailman-users-leave(a)mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/

5 years

[MM3-users] Re: About to Install MM3 -- Seeking clarification

by Onyeibo Oku

Help! Regards Onyeibo On Thu Oct 13, 2022 at 6:03 AM WAT, Onyeibo Oku wrote: > On Wed, 12 Oct 2022 17:52:47 -0700 > Mark Sapiro <mark(a)msapiro.net> wrote: > > Thanks Eggert and Sapiro. > > > > > As Eggert suggests, see > > https://docs.mailman3.org/en/latest/install/virtualenv.html and > > follow that. > > I already started out on the above route. Its an adaptation because I > am running Fedora. I had no problem with system-wide installations via > dnf package management. However, some parts of the documentation does > not add up. > > > You don't need to download the source from GitLab. > > Following that doc will get the latest releases from PyPI via pip. > > Those are still somewhat out of date - we really should make new > > releases - so if you want the latest from GitLab, there are a couple > > of ways to do it. Perhaps the easiest is to just run the various `pip > > install` commands as documented and then upgrade Mailman core in your > > venv with ``` > > pip install --upgrade git+https://gitlab.com/mailman/mailman@master > > ``` > > and update the various mailman web packages with > > ``` > > pip install --upgrade git+https://gitlab.com/mailman/xxx@master > > ``` > > where xxx is mailman-web, mailman-hyperkitty, django-mailman3, > > postorius, hyperkitty. I.e., run it 5 times, once for each value of > > xxx. > > > > I will come to this eventually (assuming that does not break things > later). I aim to get it all working with regular pip packages first. I > have installed mailman core already. > > Fedora expects mailman files to reside at /usr/lib/mailman. It appears > to ship with a mailman unix user. I adapted to those system defaults. > > Now I observe that "su - mailman" gives me the proper prompt but > .bashrc doesn't kick in. I still have to manually change to the > virtual environment despite setting the automatic change in .bashrc. > However, "su mailman" runs .bashrc but the prompt says "bash X.XX $". > Is this normal? > > Subsequent parts of the doc show the path "/opt/mailman/mm/var/*" which > should correspond to "/usr/lib/mailman/mm/var/*" on my instance. > However, I don't see any instructions on how to get the "/mm" folder > and the associated sub-folders. I just have "/usr/lib/mailman" > > I am lost > > "pip list" within the venv environment confirms that I have "mailman > 3.3.5". What am I missing? > > Regards > Onyeibo > > > _______________________________________________ > 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/

3 years, 10 months

[MM3-users] Re: Trouble Installing Mailman3

by Henry Hartley

This isn't doing a lot for my self-esteem. I'm now trying to install mailman-web and mailman-hyperkitty. Running the 'pip install' (as documented here https://docs.mailman3.org/en/latest/install/virtualenv.html#installing-web-…) is giving me a similar setuptools error to the one I got before, although with a different version number: [SNIPPED successfully downloaded packages] Collecting django-haystack>=2.8.0 (from hyperkitty->mailman-web) Using cached django_haystack-3.3.0.tar.gz (467 kB) Installing build dependencies ... error error: subprocess-exited-with-error × pip subprocess to install build dependencies did not run successfully. │ exit code: 1 ╰─> [2 lines of output] ERROR: Could not find a version that satisfies the requirement setuptools>=61.2 (from versions: none) ERROR: No matching distribution found for setuptools>=61.2 [end of output] note: This error originates from a subprocess, and is likely not a problem with pip. error: subprocess-exited-with-error × pip subprocess to install build dependencies did not run successfully. │ exit code: 1 ╰─> See above for output. note: This error originates from a subprocess, and is likely not a problem with pip. Running 'pip install setuptools' replies that it's already installed (which is what I expected, because I installed it earlier) Requirement already satisfied: setuptools in ./venv/lib/python3.12/site-packages (80.9.0) I tried clearing pip's cache, but that made no difference. I am running as the mailman user in venv. It seems to be somehow related to the django-haystack package. In fact, running 'pip install django-haystack' results in the same error message. Perhaps I need to take it up with the maintainers of that. -- Henry Hartley Westat RB 2151 -----Original Message----- From: Henry Hartley via Mailman-users <mailman-users(a)mailman3.org> Sent: Friday, June 6, 2025 09:31 To: Mark Sapiro <mark(a)msapiro.net>; mailman-users(a)mailman3.org Subject: [MM3-users] Re: Trouble Installing Mailman3 CAUTION: External Email * [ This message appears to be from westat.com but the originating sender is external.] >> -----Original Message----- >> From: Mark Sapiro <mark(a)msapiro.net> >> >> >> The next step in the instructions has me create >> >> /etc/mailman3/mailman.cfg. The first thing in that file is shown as: >> >> >> >> [paths.here] >> >> var_dir: /opt/mailman/mm/var >> >> >> >> Looking in /opt/mailman, there is no mm directory. Should that >> >> have been created, or is that something I need to create myself? >> > >> > You need to create it. I'll update the doc for that too. >> >> Actually, that's wrong. You don't need to create it. The first time you start Mailman core, it will be created. Excellent. Thanks. -- Henry _______________________________________________ Mailman-users mailing list -- mailman-users(a)mailman3.org To unsubscribe send an email to mailman-users-leave(a)mailman3.org https://secure-web.cisco.com/1zFhvAPq5v7Gs3kANDBULVLuS95U56cpRwhnFwcvKwwPbI… Archived at: https://secure-web.cisco.com/1FyVIRlyXW9zpUP_wm98qkGB_DRuoOre5YHVvNpUo9unXQ… This message sent to henryhartley(a)westat.com * Please use caution when responding and/or clicking on links as this email originated from outside of Westat.

1 year, 2 months

[MM3-users] Re: Broken web UI after upgrade

by Odhiambo Washington

On Sat, Dec 17, 2022 at 9:33 AM Mark Sapiro <mark(a)msapiro.net> wrote: > On 12/16/22 22:21, Mark Sapiro wrote: > > > > I suggest you look at ownership and permissions. > > > > ``` > > find /opt/mailman/mm/static/ -not -user mailman > > find /opt/mailman/mm/static/ -not -perm -u+rw > > find /opt/mailman/mm/static/ -type d -not -perm -u+x > > ``` > > and the same on > > /opt/mailman/mm/venv/lib/python3.9/site-packages/hyperkitty/ > > > > > >> If the above doesn't reveal anything substantial, then let me know and I > >> can bump up the verbosity. > > > > > > I don't know if --verbosity 3 will reveal anything or not. You could try. > > > Did you see the post at > < > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message…>? > > Have you tried > ``` > django-admin clear_cache > (venv) mailman@list:~$ /opt/mailman/mm/bin/django-admin clear_cache Cache "default" has been cleared! (venv) mailman@list:~$ ls -al /opt/mailman/mm/static/CACHE/ total 16 drwxr-xr-x 4 mailman mailman 4096 Dec 16 22:01 . drwxr-xr-x 9 mailman mailman 4096 Dec 4 06:38 .. drwxr-xr-x 2 mailman mailman 4096 Dec 16 22:01 css drwxr-xr-x 2 mailman mailman 4096 Dec 16 22:01 js (venv) mailman@list:~$ ls -al /opt/mailman/mm/static/CACHE/css/ total 8 drwxr-xr-x 2 mailman mailman 4096 Dec 16 22:01 . drwxr-xr-x 4 mailman mailman 4096 Dec 16 22:01 .. (venv) mailman@list:~$ ls -al /opt/mailman/mm/static/CACHE/js/ total 8 drwxr-xr-x 2 mailman mailman 4096 Dec 16 22:01 . drwxr-xr-x 4 mailman mailman 4096 Dec 16 22:01 .. (venv) mailman@list:~$ So all the css files that were in /opt/mailman/mm/static/CACHE/css/ are gone after running `django-admin clear_cache`. After that, I did run my mailman-post-update script again which created dirfferent files under CACHE/css/ as the date shows (venv) mailman@list:~$ ls -al /opt/mailman/mm/static/CACHE/ total 20 drwxr-xr-x 4 mailman mailman 4096 Dec 16 22:46 . drwxr-xr-x 9 mailman mailman 4096 Dec 4 06:38 .. drwxr-xr-x 2 mailman mailman 4096 Dec 16 22:46 css drwxr-xr-x 2 mailman mailman 4096 Dec 16 22:46 js -rw-r--r-- 1 mailman mailman 621 Dec 16 22:46 manifest.json (venv) mailman@list:~$ ls -al /opt/mailman/mm/static/CACHE/css/ total 176 drwxr-xr-x 2 mailman mailman 4096 Dec 16 22:46 . drwxr-xr-x 4 mailman mailman 4096 Dec 16 22:46 .. -rw-r--r-- 1 mailman mailman 162923 Dec 16 22:46 output.1d3a3c0dd51d.css -rw-r--r-- 1 mailman mailman 1209 Dec 16 22:46 output.9a7b11621c5a.css -rw-r--r-- 1 mailman mailman 569 Dec 16 22:46 output.e68c4908b3de.css (venv) mailman@list:~$ I then rebooted the system just to be sure everything is restarted. And the PROBLEM IS SOLVED :-) Thank you very much for your time spent in following this up with me to the conclusion. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)

3 years, 8 months

[MM3-users] Re: Installing mailman 3

by Abhilash Raj

When you set DEBUG=False, Django doesn't serve static files because of which you see only text and no styles. http://docs.mailman3.org/en/latest/pre-installation-guide.html#django-stati… If you do set DEBUG=False, you need to serve the static pages somehow. Alternatively in you case, you can remove the part of the `settings.py` which changes the Emailbackend when `DEBUG=False` so that you don't have to worry about serving static files and still send out emails. On Wed, Aug 2, 2017, at 09:46 AM, Rafael Mora wrote: > For testing purpose I turned back to false the DEBUG var and everything > started working fine with HyperKitty > > I don't understand... this is the trace when I click Login from Postorius > to HyperKitty > > [02/Aug/2017 16:43:42] "GET /postorius/lists/ HTTP/1.1" 200 3645 > [02/Aug/2017 16:43:48] "GET /accounts/login/?next=/postorius/lists/ > HTTP/1.1" 200 10950 > [02/Aug/2017 16:43:49] "GET /static/CACHE/css/hyperkitty.2f591b4e31fe.css > HTTP/1.1" 200 156657 > > > What should I check? > > > > > > > > > El mié., 2 ago. 2017 a las 10:56, Mark Sapiro (<mark(a)msapiro.net>) > escribió: > > > On 08/02/2017 07:55 AM, Rafael Mora wrote: > > > HyperKitty is looking for some files in /static/CACHE/... but it doesn't > > > find them: > > > > > > [02/Aug/2017 14:53:38] "GET /static/CACHE/css/b3547a2ab51b.css HTTP/1.1" > > > 404 107 > > > [02/Aug/2017 14:53:38] "GET /static/CACHE/css/4c17bb8058aa.css HTTP/1.1" > > > 404 107 > > > [02/Aug/2017 14:53:38] "GET /static/CACHE/css/2fa1cba00450.css HTTP/1.1" > > > 404 107 > > > [02/Aug/2017 14:53:38] "GET /static/CACHE/js/4ce1260ef558.js HTTP/1.1" > > 404 > > > 105 > > > [02/Aug/2017 14:53:39] "GET /static/CACHE/js/4ce1260ef558.js HTTP/1.1" > > 404 > > > 105 > > > > > > > > > Should I run any command to activate the CACHE dir? > > > > > > You need to ensure you have a working sass compiler. As I said at > > < > > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > > >, > > See the third bullet under > > <http://docs.list.org/en/latest/prodsetup.html#dependencies>. > > > > Then you need to run commands like > > > > django-admin collectstatic --clear > > django-admin compress > > > > > > -- > > Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, > > San Francisco Bay Area, California better use your sense - B. Dylan > > _______________________________________________ > > Mailman-users mailing list > > mailman-users(a)mailman3.org > > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > > > -- > > Atentamente / Best Regards > > Ing. Rafael Mora > _______________________________________________ > Mailman-users mailing list > mailman-users(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ -- thanks, Abhilash Raj

9 years

[MM3-users] Re: Postorius claims 2 messages held when there are none - out of sync

by Mark Sapiro

On 6/26/23 11:53 AM, Ken Alker wrote: > > Is the var/messages hierarchy also where all the archived emails are > stored for future viewing via the web interface? No. They are stored in the hyperkitty_email and hyperkitty_attachment tables in the database. >> Also, there is a long thread at >> https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/threa >> d/UWCUQYU7Q5X5LWNII57ZZ4DDXE4DEFX7/ and maybe others that might be >> relevant. > > I have never used the mailman shell before, but based on the referenced > thread I learned to do this (note that the thread also taught me how to > rewrite it to narrow down to just the list with issues so I didn't > delete held messages in other lists, if my case): > > for verification: > > venv) mailman@speedy:~/web/logs$ mailman shell -l > sbarc-list(a)lists.netlojix.com > Welcome to the GNU Mailman shell > Use commit() to commit changes. > Use abort() to discard changes since the last commit. > Exit with ctrl+D does an implicit commit() but exit() does not. > The variable 'm' is the sbarc-list(a)lists.netlojix.com mailing list > >>> requests = IListRequests(m) > >>> first = True > >>> for request in requests.held_requests: > ... key, data = requests.get_request(request.id) > ... if first: > ... first = False > ... print(m.list_id) > ... print (f"""\ > ... Sender: {data['_mod_sender']} > ... Subject: {data['_mod_subject']} > ... Date: {data['_mod_hold_date']} > ... Reason: {data['_mod_reason']} > ... """) > ... > and then to delete the two messages: > > (venv) mailman@speedy:~/web/logs$ mailman shell -l > sbarc-list(a)lists.netlojix.com > Welcome to the GNU Mailman shell > Use commit() to commit changes. > Use abort() to discard changes since the last commit. > Exit with ctrl+D does an implicit commit() but exit() does not. > The variable 'm' is the sbarc-list(a)lists.netlojix.com mailing list > >>> requests = IListRequests(m) > >>> first = True > >>> for request in requests.held_requests: > ... key, data = requests.get_request(request.id) > ... if first: > ... first = False > ... print(m.list_id) > ... print(f'request id: {request.id}, deleting') > ... requests.delete_request(request.id) > ... > sbarc-list.lists.netlojix.com > request id: 27, deleting > request id: 28, deleting > >>> > > The result of this, however, was that the web interface still claimed I > had two held messages. I wasn't sure if there was some cron-type > "sweeper" process I had to wait to auto-run or if I had to manually do > something to create an update. I then realized that the sample script > had a ' >>> commit ()" ' at the end, which I'd missed. So, I re-entered > the script (but it didn't spit out that it deleted anything this time) > and got an error when I did the commit. Was this in the same `mailman shell` interaction or a new one? What was the error? > So, I figured the messages HAD > been delete and the commit wasn't really necessary. When I went back to > the web interface, the number of held messages was at 0 and I no longer > get the original error when clicking on "Held messages", so my issue is > solved. But this does leave me with some educational questions: > > 1) Did I affect something somehow with my "commit", or was there a job > that cleaned things up (if so, what job)? I'm not sure of the sequence of events, but I think you probably looked in Postorius before you quit `mailman shell` and then you quit `mailman shell` with ctrl-D which did an implicit commit. > 2) Is the "commit" even necessary (I saw it in someone else's script in > the thread)? It is necessary to explicitly commit() or quit with ctrl-D to actually update the database. > 3) Is there a way to save a script and then execute it via shell rather > than typing it in every time (it appears from the examples that people > are typing them in every time, which is super tedious; I didn't paste > for fear of doing something damaging, but maybe that would work)? Yes, you can save a script in the bin/ directory in your venv and run it with `mailman shell -r`. See `mailman shell --details`. > 4) Are the request.id's of the messages dynamic/changing, or are they > fixed for life? I thought I'd delete based on exact request.id without > looping but I was afraid maybe they were changing over time and that > this wouldn't be a good idea. Might be nice to know for the future. The request.id is constant for that request object. The request object is fixed for a specific held message request. I.e., a specific held message's request object and its request.id and other attributes are fixed until that request is handled. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 1 month

Search results for query "sapiro"