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

[MM3-users] Re: Core, Hyperkitty and Postorius releases

by Abhilash Raj

On Fri, May 14, 2021, at 2:16 PM, Odhiambo Washington wrote: > On Sat, May 15, 2021 at 12:01 AM Mark Sapiro <mark(a)msapiro.net> wrote: > > > On 5/14/21 1:54 PM, Odhiambo Washington wrote: > > > > > > /usr/local/include/sass > > > > > > That is the only thing found that is in the base system. > > > > And that's the one you want. What is it's mode? > > > > root@gw:/usr/home/wash # ls -al /usr/local/include/sass > total 104 > drwxr-xr-x 2 root wheel 512 Apr 16 16:49 . > drwxr-xr-x 176 root wheel 10240 Apr 19 18:05 .. > -rw-r--r-- 1 root wheel 2369 Apr 8 11:08 base.h > -rw-r--r-- 1 root wheel 10742 Apr 8 11:08 context.h > -rw-r--r-- 1 root wheel 6632 Apr 8 11:08 functions.h > -rw-r--r-- 1 root wheel 6489 Apr 8 11:08 values.h > -rw-r--r-- 1 root wheel 198 Apr 8 11:08 version.h > > I imagined I needed an executable. This sounds like a result of you running `pip3 install sass`, probably with sudo which failed mid-way due to the exception you posted above. Which OS are you using? On debian/ubuntu, you can install: sudo apt install sassc I am not exactly sure how it got removed during your upgrade to the new version of Mailman since it shouldn't affect your system packages. Did you install Mailman initially using system packages or instructions provided at [1]? [1]: https://docs.mailman3.org/en/latest/install/virtualenv.html#virtualenv-inst… -- thanks, Abhilash Raj (maxking)

4 years

[MM3-users] Re: problem configuring mailman3 on debian bullseye

by Servizio Informatico U.I.C.I. Sezione territoriale di Brescia

Hi, Thank you. I discovered tha I removed all templates but in the db table the template was not removed. It was pointing to localhost and this was the problem. Thanks to all for help! Roberto Burceni Servizio informatico sezionale Tel. 0302209417 (lunedì e giovedì mattina dalle 9:00 alle 13:00, martedì emercoledì pomeriggio dalle 14:00 alle 18:00 E-mail: servizioinformatico(a)uicibrescia.it Sito web: https://www.uicibrescia.it Il 16/03/23 04:20, Mark Sapiro ha scritto: > On 3/15/23 09:55, Odhiambo Washington wrote: >> On Wed, Mar 15, 2023 at 7:10 PM Servizio Informatico U.I.C.I. Sezione >> territoriale di Brescia <servizioinformatico(a)uicibrescia.it> wrote: >> >>> Hi, >>> >>> I created a template but after some tests I deleted it. >>> >>> Now I created only a standard list without modifying any templates. >>> >>> So they are the standard templates coming with the distribution. I >>> did not >>> change also the language >>> >> Maybe you can start by deleting any templates in postorius_emailtemplate >> table in the DB? > > There shouldn't be any, but if the issue is with accessing postorius > templates, that might make it worse. > > If you want only the system default templates, you could do this > database query to remove any non-defaults: > > DELETE FROM templates; > > That will ensure that you aren't accessing Postorius for any templates. >

2 years, 2 months

[MM3-users] Re: Can't post to my own list from HyperKitty

by MegaBrutal

Mark Sapiro <mark(a)msapiro.net> ezt írta (időpont: 2025. ápr. 9., Sze, 4:49): > ``` > $ 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. > > >>> um = getUtility(IUserManager) > >>> usr = um.get_user('user(a)example.com') # any of the three addresses > >>> usr.addresses > prints a list of the 3 addresses. These are indexed as 0, 1, 2 > >>> usr.preferred_address > prints the preferred address. If this is the one you want to delete, do > >>> usr.preferred_address = usr.addresses[n] # n is the index of one > you want > >>> del usr.addresses[n] # n is the index of the address you don't want > >>> usr.addresses.remove(n) # n is the index of the address you don't > want > >>> commit() > ``` Thanks, I successfully removed my unwanted address, so it now doesn't appear anywhere. (Looks like .remove(n) wasn't needed, it only gave an exception, and the settings were saved even without commit() – which is concerning because I would have assumed that I can cancel transactions by omitting it.) However, the problem still persists: I can't post to the list from HyperKitty. In this regard, nothing has changed since my original report. I'm subscribed to the list with my primary, preferred address, which is the GMail address right now.

1 month, 1 week

[MM3-users] Re: High memory usage

by Philip Colmer

On Thu, 17 Feb 2022 at 01:02, Mark Sapiro <mark(a)msapiro.net> wrote: > On 2/16/22 00:18, Philip Colmer 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. > > > It sounds like there is a memory leak somewhere. This is an issue with > some versions of Python. I know both Python 3.10.2 and 3.9.10 were > released ahead of schedule to fix this. See > https://bugs.python.org/issue46347 Thanks, Mark. We're using Python 3.8; I've looked at the open issues and don't immediately see any that might be memory-leak related in a way that would affect Mailman 3. That said, there are quite a few libraries and other "moving parts" involved in this project so we're going to try and track memory usage over time by process or similar to see if we can see whether or not this is a leak and, if it is, what the likeliest culprit might be. Philip

3 years, 3 months

[MM3-users] Re: Walk-thru for Ubuntu Bionic Mailman 3 Full setup

by kisner＠live.com

Mark Sapiro wrote: > On 7/9/22 8:48 AM, kisner(a)live.com wrote: > > Thanks! > > OK, ran through again on a vanilla Debian 11.3 install, got this error (I'll try to create the directory and see if I can get past it): > > (venv) mailman@lists:~$ mailman-web migrate > > Traceback (most recent call last): > > File "/usr/lib/python3.9/logging/config.py", line 564, in configure > > handler = self.configure_handler(handlers[name]) > > File "/usr/lib/python3.9/logging/config.py", line 745, in configure_handler > > result = factory(**kwargs) > > File "/usr/lib/python3.9/logging/handlers.py", line 445, in __init__ > > logging.FileHandler.__init__(self, filename, mode=mode, > > File "/usr/lib/python3.9/logging/__init__.py", line 1142, in __init__ > > StreamHandler.__init__(self, self._open()) > > File "/usr/lib/python3.9/logging/__init__.py", line 1171, in _open > > return open(self.baseFilename, self.mode, encoding=self.encoding, > > FileNotFoundError: [Errno 2] No such file or directory: '/opt/mailman/web/logs/mailmanweb.log' > > Creation of the directory is documented. From > https://docs.mailman3.org/en/latest/install/virtualenv.html#initial-configur... > # Make sure that this directory is created or Django will fail on start. > LOGGING['handlers']['file']['filename'] = > '/opt/mailman/web/logs/mailmanweb.log' My bad, I missed that. Maybe pull that line out of the config comments and put it in the instructions below? That wasn't the show stopper, though, that I could figure out, it was the other bug. I'm glad someone already reported it and fixed it.

2 years, 10 months

[MM3-users] Re: Digests not working correctly

by Joel Lord

I ran the "/usr/local/bin/mailman digests --periodic" again, sadly without the --verbose, and it kicked out the digests as it ought to have the first time. Now I have to wait for some list traffic to come in to "recharge" the digests so I have something to test with again. -Joel On 6/13/2023 1:46 PM, Mark Sapiro wrote: > On 6/13/23 09:42, Joel Lord wrote: >> Now I'm on one of the lists in digest mode and I can see that it's a >> mess. Periodic digests are definitely NOT working, so I'll lay that >> out here. >> ... >> root@host2:/# grep digests /var/log/cron.log >> Jun 11 23:00:01 host2 CRON[1632765]: (lists) CMD >> (/usr/local/bin/mailman digests --periodic) >> Jun 12 23:00:01 host2 CRON[2177286]: (lists) CMD >> (/usr/local/bin/mailman digests --periodic) > > > OK. > >> root@host2:/home/members/directory# su - lists >> lists@host2:~$ /usr/local/bin/mailman digests --periodic >> lists@host2:~$ ls var/lists/<list>/ >> digest.mmdf > > > If there is nothing in Mailman's mailman.log, I don't know what the > issue is unless the list's digest_send_periodic flag is False. > > >> How can I try and track this down? > > > Try manually running > ``` > /usr/local/bin/mailman digests --periodic --verbose > ``` > to get more info. Also try > ``` > /usr/local/bin/mailman digests --send --verbose > ``` > to see what it reports and whether it sends the digest. > -- Joel Lord

1 year, 11 months

[MM3-users] Change to content filtering collapse alternatives - was: Re: Mailman shutting down Hyperkitty: Request too large

by Stephen J. Turnbull

Mark Sapiro writes: > That said, the effect on the OP's case, which may be more common, may be > harmful depending on list and Mailman config. > > The original message from the OP (edited) is > ``` > Content-Type: multipart/related; boundary="000000000000da2dcc062cb38aa1" Ouch, that's a mess. First, unless you elided it, it's missing the required type parameter. Despite being required, it's basically an optimization and in most cases will not be much of one. So that's not really a big deal. Second, the Content-IDs are malformed. They are supposed to have the form of message IDs. Also not a big deal, they're close enough for government work. The big problem is I have no idea what the semantics of multipart/related text/plain image/jpeg should be. Throwing away the image data seems like it would be the right thing to do according to RFC 2387, which delegates rendering of the entire multipart/related entity to the root entity. But if that were the desired result of the author of the original message, it's straightforward to achieve by inverting the related and alternative parts. And (at least for image content) I would think that would be a rare intention. I don't see an obvious way to resolve this without checking what popular MUAs do with the various possibilities. So as long as your patch does the expected thing, it's the minimal solution. Steve

3 months, 2 weeks

[MM3-users] Re: Weird hourly indexing error

by Mark Dadgar

On May 5, 2020, at 9:21 AM, Mark Sapiro <mark(a)msapiro.net> wrote: > > On 5/5/20 8:55 AM, Mark Dadgar wrote: >> I moved my mail server to a Digital Ocean droplet. I basically installed all the appropriate packages and then rsync’d everything that matters from my metal server up to the cloud instance. Everything more or less works fine. >> >> However, I am now getting this hourly error - see below. > ... >> [ERROR/MainProcess] Failed indexing 1 - 1000 (retry 5/5): Term too long (> 245): XSUBJECT95251413 (pid 36301): Term too long (> 245): XSUBJECT95251413 >> Traceback (most recent call last): >> File "/usr/lib/python3/dist-packages/haystack/management/commands/update_index.py", line 97, in do_update >> backend.update(index, current_qs, commit=commit) >> File "/usr/local/lib/python3.8/dist-packages/xapian_backend.py", line 488, in update >> database.replace_document(document_id, document) >> xapian.InvalidArgumentError: Term too long (> 245): XSUBJECT95251413 > > > This error comes from Xapian. It is due to a (new) message in your > archive that contains a 'word' longer than 245 characters. > > There is a PR at > <https://github.com/notanumber/xapian-haystack/pull/181> that addresses > this plus another suggested fix in that PR's comment thread. Thanks. I guess I wait for them to roll the fix in and the ubuntu maintainers to pick it up. > Note: I got there by googling "xapian term too long" which gave > <https://github.com/notanumber/xapian-haystack/issues/153> as the first > hit and that led me to the above. Yeah, that would have been smarter. - Mark ----- mark(a)pdc-racing.net | 408-348-2878

5 years

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

by Odhiambo Washington

On Wed, Feb 1, 2023 at 8:31 PM Mark Sapiro <mark(a)msapiro.net> wrote: > On 1/31/23 23:33, Odhiambo Washington wrote: > > Is this a race condition? > > > > <CUT> > > ERROR OCCURED IN JOB: update_and_clean_index (APP: hyperkitty) > > Traceback (most recent call last): > > File > > > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django_extensions/management/commands/runjobs.py", > > line 40, in runjobs > > job().execute() > > File > > > "/opt/mailman/mm/venv/lib/python3.9/site-packages/hyperkitty/jobs/update_and_clean_index.py", > > line 37, in execute > > run_with_lock(update_index, remove=True) > > File > > > "/opt/mailman/mm/venv/lib/python3.9/site-packages/hyperkitty/lib/utils.py", > > line 181, in run_with_lock > > log.exception("Failed to update the fulltext index: %s", e) > > File > > > "/opt/mailman/mm/venv/lib/python3.9/site-packages/flufl/lock/_lockfile.py", > > line 470, in __exit__ > > self.unlock() > > File > > > "/opt/mailman/mm/venv/lib/python3.9/site-packages/flufl/lock/_lockfile.py", > > line 420, in unlock > > raise NotLockedError('Already unlocked') > > flufl.lock._lockfile.NotLockedError: Already unlocked > > <CUT> > > > Yes, it is a race between the monthly hyperkitty update_and_clean_index > job and the hourly hyperkitty update_index job > Okay. This is a bit off from my understanding. What is the cause and how do I mitigate it? -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)

2 years, 3 months

[MM3-users] Re: Verification emails 'helo' rejected

by Greg Newby

Success! Below: On Wed, Oct 16, 2024 at 10:52 AM Mark Sapiro <mark(a)msapiro.net> wrote: > On 10/14/24 12:42, Greg Newby via Mailman-users wrote: > > > > Here are the corresponding logfile entries from mailmanweb.log: > > smtplib.SMTPRecipientsRefused: {'redacted(a)gmail.com': (504, b'5.5.2 > <mail>: > > Helo command rejected: need fully-qualified hostname')} > > > > and from mail.log: > > Oct 14 12:06:26 domain postfix/smtpd[722764]: NOQUEUE: reject: RCPT from > > localhost[127.0.0.1]: 504 5.5.2 <mail>: Helo command rejected: need > > fully-qualified hostname; from=<root(a)lists.domain.tld> > to=<root@localhost> > > proto=ESMTP helo=<mail> > > > > lists.domain.tld is the domain for Mailman3. I don't know why it's trying > > to send email from root@. > > > I think the mail.log entry is for the DSN for the failure. The issue is > the HELO/EHLO command. Try the following in your venv > ``` > (venv) ...:~$ python > Python 3... > Type "help", "copyright", "credits" or "license" for more information. > >>> import socket > >>> socket.getfqdn() > ``` > If that returns `localhost`, that's the issue. I think you can fix it by > putting a fully qualified domain name in /etc/hostname. > > That was the answer. I had the short hostname, not the fully qualified domain name. Thank you! The logfile messages were pretty confusing since they did not mention the hostname at all. Postfix was not the problem, as you wrote separately. ~ Greg

7 months

Search results for query "sapiro"