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

[MM3-users] Re: Archive search failing on one list

by Mark

On Sat, 2023-09-23 at 20:28 -0700, Mark Sapiro wrote: > > What if you do something like the following where django-admin is > whatever command you use for the Django admin command. > ``` > $ django-admin shell > Python 3.9.16 (main, Dec 11 2022, 12:49:23) > [GCC 9.4.0] on linux > Type "help", "copyright", "credits" or "license" for more > information. > (InteractiveConsole) > >>> from hyperkitty.models.mailinglist import MailingList > >>> mlist_name = 'listname(a)domain.com' > >>> mlist = MailingList.objects.get(name=mlist_name) > >>> mlist > <MailingList listname(a)domain.com (listname.domain.com)> > >>> > ``` Hi Mark, I'm still on this problem of one list's archive-search not returning any results. I created a new list today and it also has the same problem. In short, the older lists all seem fine -- their search results are up- to-date so that tells me the cron is okay. It's just these 2 newer lists that have the problem. It's taken me while to get my head around the Django admin command you have suggested, as I kept getting an error when starting: #django-admin shell >>> from hyperkitty.models.mailinglist import MailingList ... django.core.exceptions.ImproperlyConfigured ... That sent me down a rabbit hole which I haven't emerged from yet. But instead, starting with # python3 manage.py shell ... # python3 manage.py shell Python 3.9.2 (default, Feb 28 2021, 17:03:44) [GCC 10.2.1 20210110] on linux Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> from hyperkitty.models.mailinglist import MailingList >>> mlist_name = 'thepost(a)example.com' >>> mlist = MailingList.objects.get(name=mlist_name) >>> mlist <MailingList: <MailingList thepost(a)example.com>> >>> The format of my final line is different to yours ... Mine: <MailingList: <MailingList thepost(a)example.com>> Yours: <MailingList listname(a)domain.com (listname.domain.com)> Does this (missing list_id) give any clue as to why the archive-search isn't working, or is just that starting with "# python3 manage.py shell" is the wrong thing to do? By the way, the list_id shows correctly in the SQL query result. select * from hyperkitty_mailinglist where name like 'thepost(a)example.com'; ... name | thepost(a)example.com | list_id | thepost.example.com ... Any ideas appreciated. Mark

2 years, 11 months

[MM3-users] Re: urls.py location on venv install

by Torsten

Hi Mark, I had a very productive session with Odhiambo today and everything is now up and running. We installed everything with the commands you mention below and after some weird issue that mailman info first used /etc/mailman3/mailman.cfg but later switched to /opt/mailman/mm/var/etc/mailman.cfg (which only consisted of comments and no real configuration) things have settled and now my instance is up and running still containing the list and all members. The only thing I lost is the archive but that is probably gone for a while now and not worth getting back. Thanks to everyone for their help, especially to Odhiambo. Am 2026-08-12 18:30, schrieb Mark Sapiro: > On 8/11/26 22:46, Torsten wrote: >> >> But it seems that 3.3.10 depends on nntplib >= 3.13 which could not be >> fetched via pip: > > That's a bug. The requirement in Mailman 3.3.10's pyproject.toml is > ``` > 'nntplib; python_version>="3.13"', > ``` > This is wrong. it should be > ``` > 'standard-nntplib; python_version>="3.13"', > ``` > nntplib was dropped from the standard library in Python 3.13 and > replaced by standard-nntplib from pip. > > Because of the above error, a pip install of mailman 3.3.10 will not > work with Python >= 3.13. > > Also note that currently, Mailman core is not compatible with Python >= > 3.14 because it depends on aiosmtpd which is not compatible with Python > 3.14. The aiosmtpd incompatibility is fixed in GitHub but the fix is > not yet released. The incompatibility is fixed by > <https://github.com/aio-libs/aiosmtpd/pull/575> and > <https://github.com/aio-libs/aiosmtpd/pull/595> > >> I have, nevertheless, standard-nntplib 3.13 already installed but >> there is no nntplib on Pypi. > > I suggest the following depending on your Python version > > For Python 3.13 or 3.14 > ``` > pip install git+https://gitlab.com/mailman/mailman.git > ``` > and for Python 3.14 > ``` > pip install git+https://github.com/aio-libs/aiosmtpd.git > ``` > Installing Mailman from GitLab with Python 3.13 should work fine. Both > this list and the lists at mail.python.org run the latest GitLab > version with no problems. The installation of aiosmtpd from GitHub is > more of an unknown, but should be OK.

1 month

[MM3-users] Re: Templates

by David Krantz

On Sat, Sep 23, 2017 at 6:48 PM, Mark Sapiro <mark(a)msapiro.net> wrote: > > Have you tried restarting/reloading whatever dbm (MySQL, PostgreSQL, ?) > you are using? No, that would have been strange to me; the table in the database was up to date. But now I tried that, I got no effect this time but I probably could set up a better test. I also had another problem [solved]: I get the error message "Multiple rows were found for one_or_none" when I try TemplateManager.get(name, context) for the list. There is only one matching row in the templates table so something is fishy with the ORM. This occured when I changed to the previous uri value. As the database does not have any duplicates in the templates table I suspect either a broken join or that the cache retains the old value. The traceback looks like this in the mailman shell: >>> tm.get('list:member:regular:footer', 'test.example.com') Traceback (most recent call last): File "<console>", line 1, in <module> File ".../venv-3.5/lib/python3.5/site-packages/mailman-3.2.0a1-py3.5.egg/mailman/database/transaction.py", line 85, in wrapper return function(args[0], config.db.store, *args[1:], **kws) File ".../venv-3.5/lib/python3.5/site-packages/mailman-3.2.0a1-py3.5.egg/mailman/model/template.py", line 98, in get contents = cache_mgr.get(actual_uri) File ".../venv-3.5/lib/python3.5/site-packages/mailman-3.2.0a1-py3.5.egg/mailman/database/transaction.py", line 85, in wrapper return function(args[0], config.db.store, *args[1:], **kws) File ".../venv-3.5/lib/python3.5/site-packages/mailman-3.2.0a1-py3.5.egg/mailman/model/cache.py", line 125, in get CacheEntry.key == key).one_or_none() File ".../venv-3.5/lib/python3.5/site-packages/SQLAlchemy-1.2.0b2-py3.5-linux-x86_64.egg/sqlalchemy/orm/query.py", line 2814, in one_or_none "Multiple rows were found for one_or_none()") sqlalchemy.orm.exc.MultipleResultsFound: Multiple rows were found for one_or_none() Workaround: Delete cached files in .../var/cache and run delete from file_cache in postgresql. Then that works again. The culprit was that the file got cached twice so there is a bug in the cache function. I used the ITemplateManager-util in the shell to cause the problem. >> 2. the $user_delivered_to and $user_email do not expand for some >> reason. Known problem? > > > These require that the list delivery be personalized. See > <http://mailman.readthedocs.io/en/latest/src/mailman/runners/docs/outgoing.h…>. > That explains things. Thank you! Now I got two footers, first one without personalisation and one personalised. Interesting. best regards // David

8 years, 11 months

[MM3-users] Re: templates

by Odhiambo Washington

On Fri, May 5, 2023 at 12:38 AM Mark Sapiro <mark(a)msapiro.net> wrote: > On 5/4/23 13:13, Odhiambo Washington wrote: > > Isn't that the same thing as not having them in the FS? > > If your installation is in a venv for example, the base templates are in > venv/lib/python3.x/site-packages/mailman/templates/. Isn't that part of > the FS? > <Confession> This is new knowledge that I did not posses previously as I have never seen it mentioned anywhere in the documentation that I have read. Maybe I was going to come to it one day. In the documentation that I have read, even the one from this <https://wiki.list.org/DOC/Mailman%203%20installation%20experience>, I never imagined about the presence of some defaults so I copied the ones that you shared and edited them. I had made a point of asking a question around this statement: "There are several default templates that have incorrect or generic URLs for the web UI. To make these better, I installed these templates in /opt/mailman/mm/var/templates/site/en/ as follows.." from the above link, but it kinda escaped me. I had wondered where they were. In those days, MM3 installation process was still as scary as hell for many people, me being one of them, or was it the scare of the snake (Python) :-) True story - also one that can be gleaned from the myriad stupid questions I asked on the MM3 list over the years - it took me years to get to wrap my head around MM3! I find it hard to imagine that I have become a great supporter for this thing that scared me for ages, since the days when it was in BETA. The venv example has made the process very easy. In fact, after you and Abhilash helped me internalize what a venv is, I have been able to comfortably run other projects in virtualenv. These days I can install MM3 in just a few hours - getting all the components running - Core, Web, MTA, and Apache (whether with uWSGI, mod-wsgi or Gunicorn). </Confession> And I continue to learn new things everyday. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]

3 years, 4 months

[MM3-users] Re: Huge performance issue: Mailman doesn't (seem to) receive any mails.

by Henrik Rasmussen

Henrik Rasmussen wrote: > Abhilash Raj wrote: > > On Wed, Sep 18, 2019, at 8:14 AM, Mark Sapiro > > wrote: > > each other, but Postfix is trying to deliver > > mail via lmtp to > > [172.19.199.2]:8024. Mailman's lmtp runner should be running and > > listening on port 8024. Either that is not the case or that port is not > > exposed to Postfix on IP 172.19.199.2. > > Right, that is what I was wondering, you verify that by using telnet > > on the specified IP and Port (172.19.199.2:8024). > > Yes, the postfix container listens on 172.19.199.2:8024 > [root@postfix /]# nc -v 172.19.199.2 8024 > Ncat: Version 7.50 ( https://nmap.org/ncat ) > Ncat: Connected to 172.19.199.2:8024. > 220 mailman-core GNU Mailman LMTP runner 2.0 > > > docker-compose ps lists all the running containers, > > do you see all > > the containers running? > > That also seem to be okay > [root@lstapp01pl ~]# docker ps > CONTAINER ID IMAGE COMMAND CREATED > STATUS PORTS > NAMES > bddc80799b8c maxking/mailman-web:0.2 "docker-entrypoint.sh" 16 hours ago > Up 16 hours 8000/tcp, 8080/tcp > mailman-web > be098b18aeca maxking/mailman-core:0.2 "docker-entrypoint.sh" 16 hours ago > Up 16 hours 8001/tcp, 8024/tcp > mailman-core > c47fd8ccf19d postgres:9.6 "docker-entrypoint.sh" 16 hours ago > Up 16 hours 5432/tcp > mailman_database_1 > 699264501acd mailman3-mime_htmlizer "container-entrypoint" 16 hours ago > Up 16 hours 8080/tcp > postmime > 90f381a74709 mailman3-postfix:v1.1 "./entrypoint.sh" 16 hours ago > Up 16 hours 0.0.0.0:465->465/tcp, 0.0.0.0:587->587/tcp, > 0.0.0.0:26->25/tcp postfix > > And netstat in the mailman-core container shows: > Proto Recv-Q Send-Q Local Address Foreign Address State > tcp 0 0 172.19.199.2:8024 0.0.0.0:* LISTEN` > > > You mentioned that Mailman is not receiving enough > > emails, do you get > > any emails from Mailman? I am trying to see if this is a perf problem > > or if Mailman's LMTP isn't reachable at all. > > Mailman do send out mails like when someone signs up for an account. > Thanks to both. And the runner is running: `Sep 19 06:55:06 2019 (36) b'220 mailman-core GNU Mailman LMTP runner 2.0`

6 years, 11 months

[MM3-users] Re: Mailman installation results in KeyError: 'env_py'

by Marvin Gülker

Am 22. October 2017 um 07:49 Uhr -0700 schrieb Mark Sapiro <mark(a)msapiro.net>: > or you can install the fix at Thanks. Applying this patch makes it work. Now I've got a different problem, though. I can't get it to connect to Postfix for sending emails it appears. After I created a superuser account using $ python manage.py createsuperuser as described on <http://postorius.readthedocs.io/en/latest/setup.html>, I tried to login using this credentials into Postorius. It then reported it sent a confirmation email to me (for an account I created on commandline?!), but Postfix' logs reveal that it didn't; there's not even a sign of an attempted delivery in /var/log/mail.log. I've configured the Postfix configuration in mailman.cfg like this: [mta] incoming: mailman.mta.postfix.LMTP outgoing: mailman.mta.deliver.deliver lmtp_host: 127.0.0.1 lmtp_port: 8024 smtp_host: localhost smtp_port: 25 configuration: python:mailman.config.postfix as was outlined on <http://mailman.readthedocs.io/en/latest/src/mailman/docs/mta.html>. mailman-suite's settings.py contains: # Change this when you have a real email backend EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend' EMAIL_HOST = 'localhost' EMAIL_PORT = 25 which was described on <http://docs.list.org/en/latest/config-web.html>. For completeness, the following is in Postfix' main.cf, but is not the cause of the problem as it affects the incoming direction, whereas I refer to the outgoing one: transport_maps = hash:/home/mailman/var/data/postfix_lmtp local_recipient_maps = hash:/home/mailman/var/data/postfix_lmtp I failed to locate any kind of logging information about the failed email, so I don't even know where I should start looking for the problem. var/logs/smtp.log is empty in the mailman directory, and likewise is logs/mailmansuite.log in the mailman-suite_project directory. That being said, the enormous number of configuration files to consider and dozens of cross-references to other pages in the docs make the installation guide hard to follow; it also lacks logical structure in my opinion, when it refers to parts of the configuration which are later explained. For someone like me who never programmed a Django application (Ruby dev) this is all pretty cryptic. Especially, that some parts of information are on <http://docs.list.org/en/latest/index.html> whereas other parts are scattered over readthedocs.io makes it very complicated. Greetings Marvin -- Blog: https://www.guelkerdev.de PGP/GPG ID: F1D8799FBCC8BC4F

8 years, 10 months

[MM3-users] Re: Subscription issue with ghost confirmations

by Brian Carpenter

On 10/29/20 11:33 AM, Mark Sapiro wrote: > On 10/29/20 5:23 AM, Brian Carpenter wrote: >> I have a list owner who had his subscription policy set to confirm. >> Apparently that was too hard for his list members to handle so he >> changed it to moderate only. If someone sent a subscription request that >> needed to be confirm, did not respond to it, and then tried subscribing >> again after the member policy changed to moderate, their 2nd >> subscription attempt still shows up in the confirmation queue. Is that >> normal behavior. My understanding is it is. Please let me know if I am >> wrong here. > > Are you certain that the request waiting confirmation is the second one > and not the first? Good point and I am not sure. I will try to note that if this pops up again. > > >> The real mystery here is when someone tried subscribing again >> (listname-subscribe@listdomain) hours after the subscription policy was >> changed to moderate and they still showed up in the confirm queue. How >> is that possible? I tested the list with two of my addresses and both >> showed up in the moderation queue as expected. As far as I can tell from >> the mailman logs, this was the person's first attempt at subscribing. > > I suspect it was not the first attempt and that the subscription waiting > confirmation was requested when the policy was confirm. The confirmation moderation notice had the date-time stamp that came a few hours AFTER the subscription policy was changed. Also I only saw one confirmation request sent out via Postfix' mail.log. I saw no other for this subscriber. Same thing with the smtp.log. I cannot duplicate this behavior when I try to subscribe. My subscription attempts went straight to moderation. > > The real question is if a user has a subscription waiting confirmation > and the policy is changed to moderate, is a second request rejected > because of the request waiting confirmation. If so, I think this is a > bug which should be fixed. > Do you think this is a bug with Mailman core or my system? -- Brian Carpenter Harmonylists.com Emwd.com

5 years, 10 months

[MM3-users] Re: Permission denied for fulltext_index

by Jan Eden

On 2022-11-27 19:36, Jan Eden wrote: > On 2022-11-27 08:01, Mark Sapiro wrote: > > On 11/27/22 00:35, Jan Eden via Mailman-users wrote: > > > > > > – but the existing directory /opt/mailman/fulltext_index (and its > > > contents) are readable and writeable by mailman:mailman: > > > > > > > drwxrwxr-x 2 mailman mailman 4096 Nov 27 08:00 fulltext_index/ > > > > > > > > -rw-rw-r-- 1 mailman mailman 4473 Nov 27 08:00 _MAIN_65.toc > > > > -rw-rw-r-- 1 mailman mailman 15456 Nov 27 08:00 MAIN_bc0cs2aohovftat6.seg > > > > -rw-rw-r-- 1 mailman mailman 15454 Nov 27 06:00 MAIN_brbo8i8edmlz0za4.seg > > > > -rw-rw-r-- 1 mailman mailman 15462 Nov 27 07:00 MAIN_ewnemc7lsnodd3y7.seg > > > > -rw-rw-r-- 1 mailman mailman 157324 Nov 27 04:00 MAIN_qag60g1rrumshtc2.seg > > > > -rw-rw-r-- 1 mailman mailman 15459 Nov 27 05:00 MAIN_w6e0ohurasusy61d.seg > > > > -rwxrwxr-x 1 mailman mailman 0 Nov 24 16:00 MAIN_WRITELOCK* > > > > > > I fail to see where haystack tries (and fails) to create the directory. > > > FWIW, deleting threads is not a problem. > > > > It is uwsgi trying to do this. What user is it running as? Maybe you need to > > add that user to the `mailman` group. > > That's what baffles me – uwsgi is run as the mailman user: > > mailman 3904667 1.3 0.5 129516 62188 ? Ss 18:33 0:00 /opt/mailman/venv/bin/uwsgi --ini /etc/mailman3/uwsgi.ini > mailman 3904668 0.0 0.3 203248 48796 ? Sl 18:33 0:00 /opt/mailman/venv/bin/uwsgi --ini /etc/mailman3/uwsgi.ini > mailman 3904670 0.8 0.6 220436 74464 ? Sl 18:33 0:00 /opt/mailman/venv/bin/uwsgi --ini /etc/mailman3/uwsgi.ini I tried setting permissions on /opt/mailman/fulltext_index to 777 temporarily, but the issue remained (as expected). It occurs in the Whoosh backend of Haystack (whoosh_backend.py, line 132-133): > if self.use_file_storage and not os.path.exists(self.path): os.makedirs(self.path) where self.path is referenced, which is defined in line 110 (as part of the __init__ function): > def __init__(self, connection_alias, **connection_options): > super().__init__(connection_alias, **connection_options) > self.setup_complete = False > self.use_file_storage = True > self.post_limit = getattr(connection_options, "POST_LIMIT", 128 * 1024 * 1024) > self.path = connection_options.get("PATH") Unfortunately, I cannot see where the PATH key for connection_options is defined. - Jan

3 years, 9 months

[MM3-users] Re: Hyperkitty download mbox

by Andrew Hodgson

Mark Sapiro wrote: >On 4/25/21 2:20 PM, Andrew Hodgson wrote: >> Hi, >> >> Hyperkitty 1.3.4. >> >> I am trying to download a complete list mbox by going to all threads view and using the download option. I have tried a couple of tools (Gunzip and Winrar) and both are giving me an unexpected end of file when trying to decompress the gz file. [...] >Depending in the web server configuration, timeouts can occur when downloading large archive mboxes. instead of downloading the entire mbox with <https://lists.hodgsonfamily.org/hyperkitty/list/plextalk@lists.hodgsonfamil…>, >do it in pieces by adjusting start and end. e.g. [...] >Although, I don't think timing out is the issue, and I'm not sure what is, but I think it has something to do with messages in the archive. If I try to get the 3 pieces as above, the first piece with start=2008-02-19&end=2012-12-31 works but the others don't and even the smaller Yep there is a problem with an imported mbox which seems to be present somewhere in the archive on all the lists which I imported using that method. Here is a recent trace from the download option: [2021-04-26 08:53:12 +0000] [28181] [ERROR] Error handling request Traceback (most recent call last): File "/opt/mailman/venv/lib/python3.7/site-packages/gunicorn/workers/sync.py", line 180, in handle_request for item in respiter: File "/opt/mailman/venv/lib/python3.7/site-packages/hyperkitty/views/mlist.py", line 335, in stream_mbox msg = email.as_message() File "/opt/mailman/venv/lib/python3.7/site-packages/hyperkitty/models/email.py", line 178, in as_message msg["Message-ID"] = "<%s>" % self.message_id File "/usr/lib/python3.7/email/message.py", line 409, in __setitem__ self._headers.append(self.policy.header_store_parse(name, val)) File "/usr/lib/python3.7/email/policy.py", line 145, in header_store_parse raise ValueError("Header values may not contain linefeed " ValueError: Header values may not contain linefeed or carriage return characters I do still have the original mbox files for the imported lists which were on Mailman 2.1. The other thing is when downloading these mbox files I noticed they aren't the raw messages as we had in Mailman 2.1 but modified with headers stripped and email addresses modified. Is there any way to get the raw mbox back as in the option we had in Mailman 2.1? Thanks. Andrew.

5 years, 4 months

[MM3-users] Re: Fwd: [Django] ERROR (EXTERNAL IP): Internal Server Error: /mailman3/hyperkitty/api/mailman/archive

by David Partain

On Thu, 2021-02-25 at 13:24 -0800, Mark Sapiro wrote: On 2/25/21 6:32 AM, David Partain via Mailman-users wrote: In /etc/mailman3/mailman.cfg I see: class: mailman.database.mysql.MySQLDatabase url: mysql+pymysql://mailman3:NopeNotPastingThat@localhost/mailman3?charset=utf8&use_unicode=1 Should I change the latter to be something like: url: mysql+pymysql://mailman3:NopeNotPastingThat@localhost/mailman3?charset=utf8mb4&use_unicode=1 Yes, either make it charset=utf8mb4 or I think dropping the charset= option altogether will use the database default, however I'm not clear why this would be the issue as this only controls how Mailman core accesses the database, and your issue is with HyperKitty/Django and its access is controlled by the DATABASES setting in Django's settings which you say do specify 'charset': 'utf8mb4' in OPTIONS. Also, it seems Mailman core is not even using the same database - i.e. `mailman3` whereas Django's is `mailman3web`. Hi Mark, Thanks for being patient with me. I'm still baffled but might have found the problem. I've done the above, to no avail. If I look at the queries being sent to mysql, I see stuff like this: 174 Connect mailman3web@localhost<mailto:mailman3web@localhost> on mailman3web using TCP/IP 174 Query SET sql_mode='STRICT_TRANS_TABLES' 174 Query COMMIT 174 Query SET AUTOCOMMIT = 0 174 Query SET AUTOCOMMIT = 1 174 Query SET AUTOCOMMIT = 0 I note that there is nothing about the charset, so something's clearly wonky. As previously stated, /etc/mailman3/mailman-web.py has the right thing: 'OPTIONS': { 'init_command': "SET sql_mode='STRICT_TRANS_TABLES'", 'charset': 'utf8mb4', }, but that latter is having no effect. I then found /var/lib/ucf/cache/:etc:mailman3:mailman-web.py which doesn't have charset (but does have init_command), but I _think_ that's only about the package management system. So... I found that /usr/share/mailman3-web/settings_local.py is just a link to /etc/mailman3/mailman-web.py (which obviously has the right thing), but what about the .pyc file? # grep -i STRICT_TRANS_TABLES /usr/share/mailman3-web/settings_local.pyc Binary file /usr/share/mailman3-web/settings_local.pyc matches # grep -i charset /usr/share/mailman3-web/settings_local.pyc # It ain't in the .pyc file. Am I overly optimistic that that might the be problem? If so, I'd be grateful if someone'd tell the newbie how to recreate that file without trashing something. Cheers, David

5 years, 6 months

Search results for query "sapiro"