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

[MM3-users] Re: Is it possible to upgrade from Debian 11 to Debian 12 with Mailman3?

by Odhiambo Washington

On Wed, Dec 20, 2023 at 11:28 AM Pierre Malard via Mailman-users < mailman-users(a)mailman3.org> wrote: > Le 20 déc. 2023 à 09:14, Mark Sapiro <mark(a)msapiro.net> a écrit : > > > > On December 20, 2023 7:20:17 AM GMT, Pierre Malard via Mailman-users < > mailman-users(a)mailman3.org> wrote: > >> Ok, don’t throw any more away! > >> > >> If you really don't recommend the Debian packaged solution, I just have > one question: > >> Why have you included it in the Debian "main" repositories for so long? > > > > We have no control over what's in Debian repositories. Maintenance and > distribution of the Debian packages is done by Debian. > > > > We would love it if all the downstream distributions included up to date > and bug free Mailman packages. The problem is when people encounter > difficulty with a downstream package, we are often unable to help because > we don't know the details of that package. > > Ok Mark, > > Sorry, I thought that the creation of the repository depended directly on > you or, at least, on someone from the team. Obviously this is not really > the case and I will address the person in charge: Jonas Meurer I presume? > Still, the packages will always be lagging. With virtualenv, you have a container that only relies on very minimal apps from the base OS (python3-dev python3-venv sassc lynx), the MTA, the web server, and the DB backend and is mostly self-contained, besides the fact that you also get to run the latest code. -- 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]

2 years, 1 month

[MM3-users] Re: (venv) mailman-web migrate (as explained) fails with "django.core.exceptions.ImproperlyConfigured: allauth.account.middleware.AccountMiddleware must be added to settings.MIDDLEWARE"

by Eggert Ehmke

Hello Mark, I am also using MySql/MariaDb, I followed your suggestion. This would uninstall a lot of other packages, is that safe? I did not continue. $ pip uninstall psycopg2_binary Found existing installation: psycopg2-binary 2.9.6 Uninstalling psycopg2-binary-2.9.6: Would remove: /opt/mailman/venv/lib/python3.11/site-packages/psycopg2/* /opt/mailman/venv/lib/python3.11/site-packages/psycopg2_binary-2.9.6.dist-info/* /opt/mailman/venv/lib/python3.11/site-packages/psycopg2_binary.libs/ libcom_err-2abe824b.so.2.1 /opt/mailman/venv/lib/python3.11/site-packages/psycopg2_binary.libs/ libcrypto-2cd0ac56.so.1.1 /opt/mailman/venv/lib/python3.11/site-packages/psycopg2_binary.libs/ libgssapi_krb5-497db0c6.so.2.2 /opt/mailman/venv/lib/python3.11/site-packages/psycopg2_binary.libs/libk5crypto- b1f99d5c.so.3.1 /opt/mailman/venv/lib/python3.11/site-packages/psycopg2_binary.libs/libkeyutils- dfe70bd6.so.1.5 /opt/mailman/venv/lib/python3.11/site-packages/psycopg2_binary.libs/libkrb5- fcafa220.so.3.3 /opt/mailman/venv/lib/python3.11/site-packages/psycopg2_binary.libs/libkrb5support- d0bcff84.so.0.1 /opt/mailman/venv/lib/python3.11/site-packages/psycopg2_binary.libs/ liblber-69811697.so.2.0.200 /opt/mailman/venv/lib/python3.11/site-packages/psycopg2_binary.libs/libldap- e7812872.so.2.0.200 /opt/mailman/venv/lib/python3.11/site-packages/psycopg2_binary.libs/ libpcre-9513aab5.so.1.2.0 /opt/mailman/venv/lib/python3.11/site-packages/psycopg2_binary.libs/ libpq-227f62f1.so.5.15 /opt/mailman/venv/lib/python3.11/site-packages/psycopg2_binary.libs/ libsasl2-883649fd.so.3.0.0 /opt/mailman/venv/lib/python3.11/site-packages/psycopg2_binary.libs/ libselinux-0922c95c.so.1 /opt/mailman/venv/lib/python3.11/site-packages/psycopg2_binary.libs/ libssl-0331cfe8.so.1.1 Proceed (Y/n)? n Regards, Eggert Am Donnerstag, 19. Oktober 2023, 20:31:08 CEST schrieb Mark Sapiro: > On 10/19/23 05:02, Wikinaut wrote: > > (venv) mailman-web migrate > > > Traceback (most recent call last): > ... > > > File > > "/opt/mailman/venv/lib/python3.11/site-packages/django/contrib/postgre > > s/search.py", line 1, in <module>> > > import psycopg2 > > > > File > > "/opt/mailman/venv/lib/python3.11/site-packages/psycopg2/__init__.py", > > line 51, in <module>> > > from psycopg2._psycopg import ( # noqa > > > > SystemError: initialization of _psycopg raised unreported exception > > Since you are using MySql and not PostgreSQL, in your venv do > ``` > pip uninstall psycopg2_binary > ```

2 years, 3 months

[MM3-users] Re: High memory usage

by Philip Colmer

Thanks, Stephen. I think that the reason Prasanth & I wanted to check with this list first was to see if anyone was seeing similar behaviour. Our servers are *only* running Mailman 3 and associated packages like PostgreSQL and Postfix. Regards Philip On Wed, 16 Feb 2022 at 09:35, Stephen Daniel <swd(a)pobox.com> wrote: > I'm not an expert, and you might be better served by posting this question > in one of the communities that serves sysadmins; however, my reading says > that the oom-killer is invoked when the system cannot allocate more virtual > memory, not more physical memory. The graph in your screenshot is physical > memory usage. > > The first thing I would try is increasing the size of your swap > partition. That adds to the amount of available virtual memory, without > the need for actually buying more RAM. If you really need more RAM the > result will be that the system stays up, oom-killer stays quiet, but > performance is bad and the "si" and "so" columns in vmstat get into the > triple digits or higher. > > On Wed, Feb 16, 2022 at 3:18 AM Philip Colmer <philip.colmer(a)linaro.org> > wrote: > >> Thank you for the replies from Mark and Stephen. >> >> One of the reasons why Prasanth & I are concerned with this specific >> system >> is because the first time memory usage crept up, it got to the point where >> oomkiller stepped in and, as is usual for that particular mechanism, one >> of >> the processes it killed was sshd, thus removing access to the system :(. I >> know that oomkiller can be tuned to stop it killing processes like sshd >> but >> it will, nevertheless, start killing *some* processes if it sees an out of >> memory situation. >> >> So, as Prasanth said, we doubled the memory available and stuck an alarm >> on >> it to trigger when usage exceeded 85% for 5 minutes. I've saved a >> screenshot of the monitored memory usage over the last couple of weeks: >> >> https://1drv.ms/u/s!Aq7dn8GDGLdCodsU-pybJBdckxWU1A?e=BJY1UA >> >> (It is stored on OneDrive in case you don't recognise the URL format) >> >> We changed the server on 4th February to the larger memory size. On 11th >> Feb, it triggered the alarm and we rebooted the server. Memory usage is >> starting to climb again, albeit not at the pace that it was previously. >> >> What is particularly curious for us is that we have four Mailman 3 >> servers. >> Two of them are single domain and two are hosting two domains. This server >> is one of the servers hosting two domains, but it is also the ONLY one of >> the four servers exhibiting this memory pattern. By comparison, the memory >> usage for the other server hosting two domains looks like this: >> >> https://1drv.ms/u/s!Aq7dn8GDGLdCodsVyEufkeQqit_cGA?e=ifrJHs >> >> The biggest difference we are aware of with the "problematic" server is >> that some of the list archives are quite large by comparison with our >> other >> servers. The largest is 15K messages, then 2K then 1K. The other three >> servers have lists with relatively small archives by comparison (double or >> triple digits at worst). >> >> Finally, and just FYI, we're using PostgreSQL for the database and Xapian >> for the indexing engine. >> >> Regards >> >> Philip >> >> On Tue, 15 Feb 2022 at 16:36, Mark Sapiro <mark(a)msapiro.net> wrote: >> >> > On 2/15/22 08:11, Stephen Daniel wrote: >> > > TL;DR: quite likely your system has plenty of memory and is operating >> > > normally. >> > ... >> > > On Tue, Feb 15, 2022 at 5:28 AM Prasanth Nair < >> prasanth.nair(a)linaro.org> >> > > wrote: >> > > >> > >> Hi, >> > >> >> > >> We are having an issue with high memory usage on our Mailman3 server. >> > >> Initially, our server had 16GB RAM and the memory usage went up from >> 5% >> > to >> > >> 92% within a week. So, we increased the memory capacity to 32GB RAM >> and >> > we >> > >> can see that the memory usage is going up in the same pattern. >> > >> >> > >> Any idea why it is happening? or any suggestions? >> > >> > >> > Just for reference, mail.python.org supports 231 MM 2 lists and 182 MM >> 3 >> > lists with 16 GB of ram and no swap. >> > >> > The server that supports this list and also the www.list.org web site >> > has 4 GB of ram and no swap. >> > >> > -- >> > 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/ >> >

3 years, 11 months

[MM3-users] Mailman Suite release announcement

by Abhilash Raj

Hi All, I am pleased to announce new releases for Mailman Suite, including - Mailman Core 3.3.0 (Tom Swayer) - Mailmanclient 3.3.0 - django-mailman3 1.3.0 - Postorius 1.3.0 - Hyperkitty 1.3.0 This is a feature release and also includes a bunch of bugfixes. I am really really thankful to a lot of contributors who have helped out with this release. It is really nice to see Mailman 3 gaining more users and contributors. Python 3.5 is the minimum supported version, but all the releases have been tested to work with Python 3.5-3.7. This is the last release to support Python 3.5 since it has been in security only maintenance mode for a while now. Some of the highlights of this release includes: Mailman Core 3.3.0 - Support for ARC signing. Thanks to Gene Shuman and Stephen Turnbull. - Many many improvements to "mailman import21" command. Thanks to Mark Sapiro. - Addition of French templates. Thanks to Stéphane Parunakian. - A better and more scalable REST API server using Gunicorn. - Support for SMTPS/STARTTLS. Thanks to J08ny. A full copy of change log is available at: https://mailman.readthedocs.io/en/latest/src/mailman/docs/NEWS.html Postorius 1.3.0 - Many more settings for MailingList configuration exposed, including preferred language, digest related settings. - Support for FILTER_VHOST to filter MailingLists based on the serving domain. Thanks to Nate Coraor. - Ability to write MailingList info in Markdown to render info in HTML instead of Plaintext. A full copy of change log is available at: https://postorius.readthedocs.io/en/latest/news.html Hyperkitty 1.3.0 - Unread messages, when logged in, are more easily recognizable with blue envelope icon. - Improved thread view with colored background for quoted parts of messages. - Improved readability on small screens by removing the indentation in thread view. A full copy of the change log is available at: https://hyperkitty.readthedocs.io/en/latest/news.html All the packages are available to download from PyPi (https://pypi.org) https://pypi.org/project/postorius/ https://pypi.org/project/hyperkitty/ https://pypi.org/project/django-mailman3/ https://pypi.org/project/mailman/ https://pypi.org/project/mailmanclient/ -- thanks, Abhilash Raj (maxking)

6 years, 4 months

[MM3-users] Re: Can't subscribe on new site/domain

by Flo

On 10/11/25 04:45, Mark Sapiro wrote: > On 10/10/25 3:46 PM, Flo via Mailman-users wrote: >> >> /var/lib/mailman3/web# sqlite3 mailman3web.db >> SQLite version 3.46.1 2024-08-13 09:16:08 >> Enter ".help" for usage hints. >> sqlite> SELECT * from django_mailman3_maildomain JOIN django_site ON >> site_id = django_site.id; >> ... >> ... >> 8|lists.example.com|7|7|Lists of Example|lists.example.com >> sqlite> >> > > The fields in order are: > > 1. the id of the django_mailman3_maildomain entry > 2. the mail_domain in the django_mailman3_maildomain entry > 3. the site_id the django_mailman3_maildomain entry > 4. the id of the django-site entry > 5. the domain name in the django-site entry > 6. the display name in the django-site entry > For me it looks like that 5 is the display name and 6 the domain name > The important things are 2. and 5. which are the mail host and the web > host that you see in the Postorius domains view. 3. and 4. are what we > joined on so they will always be the same. They aren't related to 1. > which is just sequentially assigned when entries are created. 1., 3. and > 4. being equal in some cases is a coincidence. > > The question is what are the other 2 entries. In particular are all 3 > values for 2. different and all 3 values for 5. different or are some > the same? > > If 2 of those entries have the same value for 5. and different values > for 2., that explains the issue when accessing Postorius at 5. because > that web host does not have a unique mail host. > For each of the lines mail_domain (field 2) is the same as the domain name (field 6, if I am right). Any domain name (and mail_domain, which has the same value) differs from the ones in any other line. So they are unique. Flo

3 months, 3 weeks

[MM3-users] Re: Moderate mails from owner

by Abhilash Raj

On Thu, Mar 21, 2019, at 8:47 AM, Malcolm Austen wrote: > On Wed, 20 Mar 2019 18:42:10 -0000, Mark Sapiro <mark(a)msapiro.net> wrote: > > > However, this is apparently not relevant because both the Member and > > Non-Member actions are Hold. Thus, the post should be held unless it has > > an Approved: header with the list's moderator_password attribute if > > there is one, or it matches a Header filter rule with an accept action. > > At the risk of getting this really wrong - I have only limited MM3 > knowledge - I will ask what is, I fancy, a closely related question ... > > My only experience of MM3 is with Ancestry's 'RootsWeb' installation. From > the emails I can see a header "X-Mailman-Version: 3.1.0" but I can't find > anything to identify Postorius which is the only interface I have to the > system. > > From symptoms seen and described by others, I have deduced that the > Postorius admin-per-user moderation options of "Default processing" and > "List default" mean that a user may be set (by default on the rootsweb > system!) to use the system default moderation settings rather than the > list default settings. "Default Processing" means the default pipeline defined in List > Settings > Alter Messages > 'Pipeline' ( in the bottom). This pipeline is system wide and is defined in source code, so it can't be customized by site administrator. > > Are my deductions correct? And if so, could this be the explanation of the > issue detailed in this thread? > > Apologies if I'm barking up entirely the wrong tree, Malcolm. > > -- > Malcolm Austen <malcolm.austen(a)weald.org.uk> > _______________________________________________ > Mailman-users mailing list -- mailman-users(a)mailman3.org > To unsubscribe send an email to mailman-users-leave(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > -- thanks, Abhilash Raj (maxking)

6 years, 10 months

[MM3-users] Re: Mailman3 on FreeBSD

by Abhilash Raj

On Sat, 12 Aug 2017 18:10:49 -0700 Mark Sapiro <mark(a)msapiro.net> wrote: > On 08/12/2017 04:51 PM, Barry Warsaw wrote: > > On Aug 10, 2017, at 16:32, John Poltorak <karotlopj(a)gmail.com> > > wrote: > >> > >> On FreeBSD they ought to be in /usr/local/etc/mailman.cfg however > >> I don't see any indication as to what I should put in this file > >> and if it was in /usr/local/etc/mailman.cfg then how would mailman > >> find it? > > > > It wouldn’t by default. Right now Mailman does not search > > for /usr/local/etc/mailman.cfg, but that wouldn’t be a difficult > > change to add. I’m not sure whether that would makes sense as a > > general default or not. I’m not up on the FreeBSD conventions and > > standards here; can you explain why /usr/local/etc is preferred > > over /etc on that distro? > > > I was hoping Abhilash would chime in here, because I think John is > using the docker image and there's probably a specific path for > mailman.cfg. As per his first message, I think John is using the prod setup from the documentaion[1]. I don't have anything much to add on top of what Barry mentioned, it looks like something is wrong with the Python install and missing Sqlite3 module. The documentation does mention the paths where Core looks for configuration file and anything else can be specified using -C or MAILMAN_CONFIG_FILE environment variable. [1]: http://docs.mailman3.org/en/latest/prodsetup.html > As far as what goes in it, it could even be empty if you want to > accept all the defaults, but you probably want at least > > [mailman] > site_owner: real_person(a)example.com > > I expect if you do > > find -name mailman.cfg > > in your installation, you'll find at least examples. > thanks, Abhilash

8 years, 5 months

[MM3-users] Re: Unusual behavior: Standard discussion lists with prefix are sometimes having prefix *dropped*

by Thomas Ward

On 10/19/23 13:41, Mark Sapiro wrote: > On 10/19/23 10:02, Thomas Ward via Mailman-users wrote: >> I noticed some unusual behavior in Mailman3 stable release on PyPI >> and such. Namely, there are instances where replies are being >> processed and the prefix tags are simply being **lost** and dropped >> by Mailman3, instead of being properly prepended where they're >> supposed to go. >> >> Is this a known bug or does it need its own bug in the gitlab tracker? > > > Are you sure you are looking at messages from the list and not > messages received by direct To:, CC: or BCC:? > > I have never seen an issue where list posts would sometimes have the > subject prefix prepended and sometimes not. If you are seeing this, we > would ideally like to see a thread in the hyperkitty archive where > some of the messages have the prefix in the message view and some > don't, or at least see some of the raw Subject: headers. This might be a MUA quirk because we (read: my employer, like my other messages) are using Outlook which we all know does Weirdness. Upon examination of the actual message's source it has the proper subject line with a prefix: > Subject: [Test] Emailing Test But the way this is displayed in Outlook is weird. It may be that Microsoft is seeing the message as CC'd (reply-all was used!) and then stripping prefix, etc. because it realized there was some stupidness or such at the message-id level or something. This is looking more like a MUA issue because my other address which is subscribed and uses Thunderbird to access the mailbox instead sees the headers right with the proper prefix, suggesting this is something specific to Outlook as a MUA. Thomas

2 years, 3 months

[MM3-users] Re: Cron Error: <mailman@gw> /opt/mailman/mm/bin/django-admin runjobs monthly

by Odhiambo Washington

On Sun, Feb 5, 2023 at 8:32 PM Mark Sapiro <mark(a)msapiro.net> wrote: > On 2/5/23 01:13, Odhiambo Washington wrote: > > > > So in my case, I should at least increase the value of > > HYPERKITTY_JOBS_UPDATE_INDEX_LOCK_LIFE to, say, 1800? > > > It probably isn't even set in your case and defaults to 900 if it isn't > set. I have never seen this config option in any of the settings files and so believe that no one has it set - except the DEVs, maybe. > Yes, you can set it to a larger value. If your archive search > engine is woosh and your archive is even moderately large, 1800 probably > isn't nearly enough. Yes, my archive search engine is whoosh. And my archives size is 2.5GB+ For starters I will make it 3600 and observe next time. > There was no indication of timing in your OP, but you should determine > when that cron job started and when the error was > reported. The difference is the absolute minimum you should set > for HYPERKITTY_JOBS_UPDATE_INDEX_LOCK_LIFE, but you should add some margin > to that. > Sadly I deleted the email. I will have to determine those aspects next time. I need to make a request for a small improvement on the documentation at: https://docs.mailman3.org/en/latest/install/virtualenv.html#cron-jobs-for-m… The problem I am facing (the subject of this thread is that of a race between the "monthly hyperkitty update_and_clean_index" job and the hourly "hyperkitty update_index job" Would it be possible to add such details to the section, so that it is clear what the corn jobs do and perhaps what can lead to such race conditions (if that's not too much to ask)? -- 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: Mailman 3 stops delivering to a domain after too many bounces

by Tim Cutts

> On 12 Jul 2022, at 16:28, Mark Sapiro <mark(a)msapiro.net> wrote: > > On 7/12/22 12:34 AM, Julian Kippels wrote: >> Hi, >> We have recently upgraded from Mailman 2 to Mailman 3. Since then I >> have observed many user reports that mails to mailing lists don't reach >> all members. My suspicion is that there are too many "dead" members on >> those lists. This was not a problem on Mailman 2, but has become a >> problem on Mailman 3. It seems to me that for example Mailman 3 sends >> mails to the first 5 existing member addresses from domain A, then >> encounters several (20 or so seems to be the threshold) "dead" member >> addresses from domain A that generate a bounce and then does not even >> attempt to reach the remaining 800 member adresses from domain A and >> only sends to members on domain B and domain C. >> Is there a way to globaly ignore bounces and send out mails to all >> members of a list, no matter what? > > > Mailman's outgoing runner should not be quitting because of bounces at SMTP time. It seems like there may by some issue causing Mailman's outgoing runner to die. What's in Mailman's var/queue/shunt/ and Mailman's var/logs/mailman.log. Good point. Mailman3 needs a great deal more RAM than Mailman2, especially if you’re running the web and core on the same machine. I used to comfortably run my small mailing list server on a 1GB VM, but on Mailman3 I found it often ran out of memory and bits of mailman3 would get shot by the kernel’s OOM killer, and had to move to a larger VM. So I’d check your kernel logs and see if you’ve got OOM messages in there. Tim

3 years, 6 months

Search results for query "sapiro"