Search results for query "sapiro"
- 6020 messages
[MM3-users] Re: Creating users via RestAPI / User-Management - a bunch of questions
by Mark Sapiro
On 6/20/25 06:39, Christian Schneider wrote:
> Dear Mark and companions,
>
> somehow I can not cope with the user management...
> (I am running a venv-installation, latest stable versions)
>
> I read this manual:
> https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/…
> and played with the RestAPI calls...
>
> I know about the fine grained differences between user and member, admin/owner, superuser...
> and about the two user databases in PostgreSQL and Django-Framework.
I'm not sure what distinction you are making between PostgreSQL and
Django-Framework. There are two separate and distinct users, Django
users and Mailman core users. Information about both is in the
PostgreSQL database. Django users are in the `auth_user` table and
Mailman core users are in the `user` table, both in the public schema,
although if you split the data into a `mailman` database and a
`mailmanweb` database the `auth_user` table is in `mailmanweb` and the
`user` table is in `mailman`.
> What I stumble upon is the RestAPI calls to create a "working" user (with the ability to login via WebUI).
> When I follow the manual (from the url above) I create a user (including password) that appears in the PostgreSQL database.
> (And this user is visible on the User-URL (https://example.com/mailman3/users))
> Even when I (via WebUI) set the user as "approved" this user is not able to log in...
> I assume this restriction is in accordance to the fact that there is not equivalent Django user.
> (There was a mail in the archive of the MM3 user group...stating that one has to use the Django RestAPI to create the appropriate user)
The above is correct. The Mailman REST API only deals with Mailman core.
Mailman core knows nothing about Django.
> When I create the user using the WebUI (https://example.com/accounts/signup/?next=/mailman3/lists/)
> the new user is created in the right (complete) way...appearing in the PostgreSQL database and as a user in Django.
> How is this sync between the two databases realized?
I'm still looking into that, but it isn't the creation of the Django
user per se that creates the Mailman user. The process has multiple steps.
1) Sign-up for an account. This creates the Django user and sends an
address confirmation email.
2) Click the link in the confirmation email. This takes you to a page
with a `Confirm` button to confirm the email address.
3) Click the confirm button.
It is not until step 3) that the Mailman user and address records are
created.
> (The Django user also has the correct status (no staff status / no superuser status / just active status) how is this realized?)
Presumably by the sign-up process not setting staff status and superuser
status.
> As I am not very familiar with python programming (I know Perl/Java/C++ and have an (maybe outdated) concept of OOP),
> is there a quick way to implement this kind of sync by copying the register logic from mailman's python action script for registering?
I think it must be django-mailman3 that's doing this, but I haven't been
able to see how so far. django-mailman3 does override the template for
the /accounts/confirm-email page, but this is only to include styling.
> Other questions:
> Will there be a create_admin_user-script that is callable via CLI (like createsuperuser or create_list)?
> (This script ought create a user in PostgreSQL and as Django user)
No plans. There are `mailman addmembers` and `mailman admins` commands
to add members or admins to a list. Adding an owner or moderator to a
list via `mailman admins` will also create a Mailman user for that
person if there isn't one already, but it won't create a Django user.
> How will a social account provider (like oidc) linkage (in Django) fit in this concept?
> Will oidc-accounts be copied to the Django's user database (or PostgreSQL db) or is it an on-the-fly check against the oidc-provider? (I assume second option)
> What are the status-flags (staff status/superuser status/active status) of the linked oidc-accounts? (Can I specify the status flags?)
I don't offhand know the answers to that, but I think logging in via a
social account provider creates a Django user..
> A conceptual thought:
> When "user1" (with email user1(a)example.com) is known to django via oidc linkage
> and I create "user1" (also with email user1(a)example.com) via RestAPI calls
> (following the url https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/…)
> do I have a "complete" user then?
> I mean a user who is able to login and who can be assigned to a list as admin (e.g.)
> (In this case I would not have to care about the Django user database... ;-))
If the user can log in to the web UI with an associated email address,
if that address is an admin of a list, the logged in user can admin the
list.
--
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
5 months, 3 weeks
[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, 1 month
[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/>
6 years, 11 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
2 years, 9 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/
4 years, 4 months
[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, 1 month
[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.
6 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 '^$|^.*#' ¯\_(ツ)_/¯ :-)
2 years, 11 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
8 years, 4 months
[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
2 years, 5 months