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

[MM3-users] Re: mailman3-web and the django middleware problem

by Thomas Stein

Am 2024-04-25 19:05, schrieb Mark Sapiro: > On 4/25/24 04:35, Thomas Stein wrote: >> >> Traceback (most recent call last): >> File "/usr/bin/django-admin", line 33, in <module> >> sys.exit(load_entry_point('Django==4.2.11', 'console_scripts', >> 'django-admin')()) >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> File >> "/usr/lib/python3/dist-packages/django/core/management/__init__.py", >> line 442, in execute_from_command_line >> utility.execute() >> File >> "/usr/lib/python3/dist-packages/django/core/management/__init__.py", >> line 416, in execute >> django.setup() >> File "/usr/lib/python3/dist-packages/django/__init__.py", line 24, >> in setup >> apps.populate(settings.INSTALLED_APPS) >> File "/usr/lib/python3/dist-packages/django/apps/registry.py", line >> 124, in populate >> app_config.ready() >> File "/usr/lib/python3/dist-packages/allauth/account/apps.py", line >> 15, in ready >> raise ImproperlyConfigured( >> django.core.exceptions.ImproperlyConfigured: >> allauth.account.middleware.AccountMiddleware must be added to >> settings.MIDDLEWARE Thanks for you answer. > This is a packaging issue in the Debian/Ubuntu package and should be > reported to Debian. I already did. https://bugs.launchpad.net/ubuntu/+source/mailman-suite/+bug/2062960 > See the BREAKING CHANGE item in the 1.3.10 section at > <https://gitlab.com/mailman/django-mailman3/-/blob/master/README.rst>. > > You need to add `allauth.account.middleware.AccountMiddleware` to the > MIDDLEWARE setting in your Django settings. I'm not sure how to add that to my django settings. Adding: x = list(MIDDLEWARE) x.insert(0, 'allauth.account.middleware.AccountMiddleware') MIDDLEWARE = x did not help. Any hints? thanks again, t.

1 year, 5 months

[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, 5 months

[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, 7 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.

6 months, 1 week

[MM3-users] Re: mail loops back to myself

by Florian Sukup

On 6/9/25 20:54, Mark Sapiro wrote: > On 6/9/25 05:06, Florian Sukup wrote: >> >> The setup has historic reasons. However I can eliminate >> reverse.rrr.com completely and replace it by host.xxx.com. Right now >> reverse.rrr.com has an A-record pointing to the host's ip address. > > Eliminating reverse.rrr.com completely and replacing it by host.xxx.com > would be good. This will help. > First step is done: I replaced reverse.rrr.com by host.xxx.com the DNS zones of all domain I use. Tomorrow I will have the rDNS record be rewritten by my ISP. > Also if I look up the A record for reverse.rrr.com either locally or at > aaron.ns.cloudflare.com there isn't one. This will be moot if you > replace reverse.rrr.com with host.xxx.com. > reverse.rrr.com is not the real name ... > > >>> What is the output from `postconf -n`? >>> >> >> alias_database = hash:/etc/aliases >> alias_maps = hash:/etc/aliases >> append_dot_mydomain = no >> biff = no >> compatibility_level = 2 >> inet_interfaces = all >> inet_protocols = all >> local_recipient_maps = proxy:unix:passwd.byname $alias_maps >> hash:/var/lib/mailman3/data/postfix_lmtp >> mailbox_size_limit = 0 >> message_size_limit = 0 >> mydestination = localhost, localhost.localdomain, arvak > > This needs to include $myhostname > I don't want to receive any emails like ...(a)host.xxx.com . So I thought removing host.xxx.com from $mydestination is a good idea. Is there any other solution for that? Florian.

4 months, 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, 8 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.

3 years, 3 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

2 years, 4 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

8 months, 2 weeks

[MM3-users] Re: Mails are stuck in Mailman Pipeline Queue

by Shashikanth Komandoor

Thank you Mark. This solution worked fine for me. On Sun, Mar 27, 2022 at 9:58 AM Mark Sapiro <mark(a)msapiro.net> wrote: > On 3/26/22 21:01, Shashikanth Komandoor wrote: > > > > But the below trace back is observed during mailman service stopping: > > > This doesn't say much ... > > > ...> Mar 27 09:01:22 2022 (5864) Uncaught runner exception: > > Mar 27 09:01:22 2022 (5864) Traceback (most recent call last): > > File > "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/core/runner.py", > > line 173, in _one_iteration > ... > > File > "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/core/runner.py", > > line 114, in signal_handler > > raise RunnerInterrupt > > mailman.interfaces.runner.RunnerInterrupt > > Mar 27 09:01:22 2022 (5864) SHUNTING: 1648351882.6693938+ > > c2e6ed709646a7680c73059b52d2f0451836e591 > > Mar 27 09:01:22 2022 (5864) digest runner exiting. > > Above, digest runner was interrupted in processing and shunted the > message it was working on. > > and below, pipeline runner was interrupted in processing and shunted the > message it was working on. > > > Mar 27 09:01:22 2022 (5860) Uncaught runner exception: > > Mar 27 09:01:22 2022 (5860) Traceback (most recent call last): > > File > "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/core/runner.py", > > line 173, in _one_iteration > > self._process_one_file(msg, msgdata) > > File > "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/core/runner.py", > > line 266, in _process_one_file > > keepqueued = self._dispose(mlist, msg, msgdata) > > File > "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/runners/pipeline.py", > > line 37, in _dispose > > process(mlist, msg, msgdata, pipeline) > > File > "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/core/pipelines.py", > > line 50, in process > > handler.process(mlist, msg, msgdata) > > File "/var/lib/mailman/venv/lib64/python3.6/site-packages/ > > mailman/handlers/member_recipients.py", line 84, in process > > for member in mlist.regular_members.members > > File "/var/lib/mailman/venv/lib64/python3.6/site-packages/ > > mailman/handlers/member_recipients.py", line 83, in <genexpr> > > recipients = set(member.address.email > > File > "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/model/roster.py", > > line 239, in members > > yield from self._get_members(DeliveryMode.regular) > > File > "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/model/roster.py", > > line 226, in _get_members > > if member.delivery_mode in delivery_modes: > > File > "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/model/member.py", > > line 205, in delivery_mode > > return self._lookup('delivery_mode') > > File > "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/model/member.py", > > line 167, in _lookup > > pref = getattr(self.address.preferences, preference) > > File > "/var/lib/mailman/venv/lib64/python3.6/site-packages/sqlalchemy/orm/attributes.py", > > line 287, in __get__ > > return self.impl.get(instance_state(instance), dict_) > > File > "/var/lib/mailman/venv/lib64/python3.6/site-packages/sqlalchemy/orm/attributes.py", > > line 723, in get > > value = self.callable_(state, passive) > > File > "/var/lib/mailman/venv/lib64/python3.6/site-packages/sqlalchemy/orm/strategies.py", > > line 760, in _load_for_state > > session, state, primary_key_identity, passive > > File "<string>", line 1, in <lambda> > > File > "/var/lib/mailman/venv/lib64/python3.6/site-packages/sqlalchemy/orm/strategies.py", > > line 850, in _emit_lazyload > > session.query(self.mapper), primary_key_identity > > File > "/var/lib/mailman/venv/lib64/python3.6/site-packages/sqlalchemy/ext/baked.py", > > line 603, in _load_on_pk_identity > > setup, tuple(elem is None for elem in primary_key_identity) > > The above says the runner was doing a database lookup. This may be a > coincidence or there may be some database locking issue that underlies > the issue with the pipeline runner. > > > > File > "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/core/runner.py", > > line 114, in signal_handler > > raise RunnerInterrupt > > mailman.interfaces.runner.RunnerInterrupt > > Mar 27 09:01:22 2022 (5860) SHUNTING: 1648351882.8537986+ > > 9bf59cb23a71a4bae65536bfdbec0abb261adaa0 > > Mar 27 09:01:22 2022 (5860) pipeline runner exiting. > > > I suggest doing the following assuming your Mailman database is not > sqlite3 (if it is, just do step 2): > > 1) Stop mailman core and maybe other mailman services too. > 2) Assuming the two shunted messages are still in Mailman's shunt queue, > run `mailman unshunt` to unshunt them. If there are more shunted > messages, inspect them with `mailman qfile` to see if you want them, > They may be spam. > 3) Restart your database server. > 4) Start Mailman core and any other stopped services. > > Also, look in the database server logs for any issues. > > -- > 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/ > -- Thanks & Regards, Shashi Kanth.K 9052671936

3 years, 6 months

Search results for query "sapiro"