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

[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, 7 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, 3 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, 4 months

[MM3-users] Re: FILTER_VHOST = True doesn't work fine with alias_domain

by Élodie BOSSIER

Thank you for your response Mark, With Mailman 2.1, the lists were split on their webpage respectively. How could I do same with Mailman 3.3.3 (Tom Sawyer) please ? My domain table SQL have this result : id, mail_host, description, alias_domain 1, ml.franceserv.fr, NULL, local.ml.franceserv.fr 2, ml.viticreation.fr, NULL, local.ml.viticreation.fr mailinglist table SQL : id, list_name, mail_host, list_id, ... 1, bar, ml.franceserv.fr, bar.ml.franceserv.fr, ... 2, viticreation, ml.viticreation.fr, viticreation.ml.viticreation.fr, ... Can I do something ? A patch somewhere ? Shall I wait issues are solved and how long approximatively please ? Which don't reassure me is I can see old discussions about FILTER_VHOST there are 2 years. I can retrieve my own old question there are 2 years when I tried to migrate from Mailman 2 to Mailman 3 : https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/… and in 2020 you told me it was working for you at this date. It's don't reassure me to retrieve a problem I got there are 2 years. I could set in production my Mailman 3 but the problem is my customers won't understand why they can see the lists of others domains name ... and not sure about the security ... Thank you again. Le 18/02/2022 à 00:33, Mark Sapiro a écrit : > There are issues with FILTER_VHOST due to the fact that mailing lists > do not have a web host attribute. This means when you go to HyperKitty > or Postorius when FILTER_VHOST is True, we look up the domain record > for the web host you are visiting and show you all the lists whose > mail host matches the mail host for the web host domain. This has > nothing to do with alias domains. > > What that means is if all your domains records have a unique mail > host, FILTER_VHOST will work as you expect, but if multiple domains > have the same mail host FILTER_VHOST will show you the lists for the > current web host plus all those with a matching mail host. > > I.e. if in your case, the ml.franceserv.fr domain and the > ml.viticreation.fr domain have the same mail host, FILTER_VHOST won't > separate them. If they have different mail hosts FILTER_VHOST will > separate them. >

4 years, 5 months

[MM3-users] Re: A little stuck with installation of MM3 - ModuleNotFoundError: No module named 'flufl.lock'

by Abhilash Raj

On Sat, Jul 25, 2020, at 2:17 PM, Mark Sapiro wrote: > On 7/25/20 12:54 PM, Odhiambo Washington wrote: > > > > Finally, I have adapted your init script to get some rudimentary one that I > > could use on FreeBSD. > > I have to change /opt/mailman to be owned by mailman3:mailman3 (because I > > have "live" MLs on this server, using mailman-2.1.34. > > I am not sure if they can co-exist. I suppose they could, but what might be > > the security implication, if any?? > > I manage more than one server that supports both Mailman 2.1 and Mailman > 3 running as user `mailman`. I'm not aware of any security issues. > > > > This is what the init script looks like (rudimentary!!): > > (venv) [root@gw /usr/local/etc/rc.d]# less mailman3 > > ### BEGIN INIT INFO > > # Provides: GNU Mailman > > # Short-Description: Mailman3 Service > > # Description: service control for Mailman3 > > ### END INIT INFO > > > > PATH=/opt/mailman/mm/bin:/opt/mailman/mm/venv/bin:/usr/sbin:/usr/bin:/bin:/sbin: > > DESC="GNU Mailman service" > > DAEMON=/opt/mailman/mm/bin/mailman > > NAME=mailman > > USER=mailman3 > > GROUP=mailman3 > > > > # Needed by click > > export LANG=en_US.UTF-8 > > > > # Exit if the package is not installed > > [ -x "$DAEMON" ] || exit 0 > > > > # Load the VERBOSE setting and other rcS variables > > #. /lib/init/vars.sh > > > > # Define LSB log_* functions. > > # Depend on lsb-base (>= 3.2-14) to ensure that this file is present > > # and status_of_proc is working. > > #. /lib/lsb/init-functions > > > > case "$1" in > > start) > > [ "$VERBOSE" != no ] && echo "Starting $DESC" "$NAME" > > # use --force to remove a stale lock. > > /usr/local/bin/sudo -u $USER $DAEMON start --force > > T don't recommend using --force in init scripts. It *shouldn't* matter > because even with --force the master shouldn't break the lock if the pip > that set it still exists, but I prefer not to use it. > > > > ;; > > stop) > > [ "$VERBOSE" != no ] && echo "Stopping $DESC" "$NAME" > > /usr/local/bin/sudo -u $USER $DAEMON stop > > ;; > > status) > > /usr/local/bin/sudo -u $USER $DAEMON status > > ;; > > reopen) > > /usr/local/bin/sudo -u $USER $DAEMON reopen > > ;; > > restart) > > log_daemon_msg "Restarting $DESC" "$NAME" > > /usr/local/bin/sudo -u $USER $DAEMON restart > > ;; > > *) > > echo "Usage: $SCRIPTNAME {start|stop|status|reopen|restart}" >&2 > > exit 3 > > ;; > > esac > > > > It does start mailman3 for sure, but also complains after a few seconds > > with the message: > > > > (venv) [root@gw /usr/local/etc/rc.d]# > > */opt/mailman/mm/venv/lib/python3.7/site-packages/mailman-3.3.2b1-py3.7.egg/mailman/rest/wsgiapp.py:180: > > DeprecatedWarning: Call to deprecated function __init__(...). API class may > > be removed in a future release, use falcon.App instead.* > > * **kws)* > > > Hmm... strange, My various MM 3 installs are running falcon 1.4.0, 2.0.0 > and 3.0.0a1 and I don't see this warning, but it is only a deprecation > warning. It doesn't mean it won't work. I have seen this during development and there is an issue open for this[1]. [1]: https://gitlab.com/mailman/mailman/-/issues/733 > > > > But: > > > > (venv) [root@gw /usr/local/etc/rc.d]# ps ax | grep mailman > ... > > It seems Mailman core and the rest runner and its workers are all running. > > > > > > Assuming that I am using mod_wsgi with Apache, and that I have configured > > apache right using > > https://wiki.list.org/DOC/Mailman%203%20installation%20experience?action=At… > > .. > > should I be able to access the MM3 web UI?? > > Yes, I think so. > > > > At that point, I am feeling somewhat confused as to what to try next. > > > > (venv) [root@gw /opt/mailman/mm/var/logs]# less mailman.log > > Jul 25 22:53:16 2020 (40670) Master started > > Jul 25 22:53:18 2020 (42036) bounces runner started. > > Jul 25 22:53:18 2020 (45205) out runner started. > > Jul 25 22:53:19 2020 (41191) archive runner started. > > Jul 25 22:53:19 2020 (46670) retry runner started. > > Jul 25 22:53:19 2020 (44567) nntp runner started. > > Jul 25 22:53:19 2020 (43069) in runner started. > > Jul 25 22:53:19 2020 (46960) virgin runner started. > > Jul 25 22:53:20 2020 (45720) pipeline runner started. > > Jul 25 22:53:20 2020 (47326) digest runner started. > > Jul 25 22:53:20 2020 (43755) lmtp runner started. > > Jul 25 22:53:20 2020 (45922) rest runner started. > > [2020-07-25 22:53:20 +0300] [45922] [INFO] Starting gunicorn 20.0.4 > > [2020-07-25 22:53:20 +0300] [45922] [INFO] Listening at: > > http://127.0.0.1:8001 (45922) > > [2020-07-25 22:53:20 +0300] [45922] [INFO] Using worker: sync > > [2020-07-25 22:53:20 +0300] [54732] [INFO] Booting worker with pid: 54732 > > [2020-07-25 22:53:20 +0300] [55467] [INFO] Booting worker with pid: 55467 > > Jul 25 22:53:21 2020 (42743) command runner started. > > > The above is all fine, but it is just Mailman core. > > > > How do I access the web UI for MM3 now? > > > The Apache config points to /opt/mailman/mm/wsgi.py, a sampole of which > is at > <https://wiki.list.org/DOC/Mailman%203%20installation%20experience?action=At…>. > Do you have that? > > If you installed the Apache config literally, the location for Mailman 3 > is defined by > <https://wiki.list.org/DOC/Mailman%203%20installation%20experience?action=At…> > and the URL would be http(s)://your.server/mm3 - have you tried that? > > -- > 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, Abhilash Raj (maxking)

6 years

[MM3-users] Re: Wrong info in moderation mail when held due to match of a header rule

by tlhackque

On 17-Oct-20 14:31, Mark Sapiro wrote: > On 10/17/20 10:39 AM, Torge Riedel wrote: >> The message is being held because: >> >> Header "Yes" matched a header rule >> >> At your convenience, visit your dashboard to approve or deny the >> request. >> >> I think this is wrong, it should read 'Header "x-spam" matched a header >> rule'. Cause the header rule is configured for header "x-spam" and >> pattern "Yes". > > The message is defined as > > 'Header "{}" matched a header rule' > > where {} is replaced with the value of the matching header. I agree it > would be better if it were something like > > 'Header value "{}" matched a header rule for {}:' > > with {}s replaced with the header value and name. That would make it in > your case > > 'Header value "Yes" matched a header rule for x-spam:' > >> I haven't found a bug report for this yet on gitlab. If someone of the >> developers confirm this is wrong, I will file a bug on gitlab for it. > > Please do file a bug. It won't be fixed until after the upcoming 3.3.2 > final release because we not making i18n changes between the candidate > and final releases. Also, if you don't like my suggestion, feel free to > suggest something else. > FWIW, I suggest: Header "{name}": rule matched value "{value}" Name tends to be short and must be simple ASCII. Value can be very long and encoded, so it may wrap. Name will be short and recognizable. Plus the name provides the context for the value - and name:value is the way the header appears in the e-mail. So I think name before value obeys the UI principle of least surprise. I might also add the rule number or config filename:line, as in Header "{name}": rule in {file}:{n} matched value "{value}" This would be helpful when backtracking from a rejected message to the cause. A sample expansion might be: Header "X-Spam": rule in foo.conf:83 matched value "yes"

5 years, 9 months

[MM3-users] Re: Problem updating mailman

by Odhiambo Washington

On Sun, 24 Jan 2021 at 00:46, Mark Sapiro <mark(a)msapiro.net> wrote: > On 1/23/21 2:56 AM, Odhiambo Washington wrote: > > I am getting this error after I did a git pull and build. > > > > (venv) [mailman3@gw ~/git]$ /opt/mailman/mm/bin/mailman-post-update > > + '[' False == False ']' > > + mkdir -p /opt/mailman/mm/static > > + /opt/mailman/mm/bin/django-admin collectstatic --clear --noinput > > --verbosity 0 > > +* /opt/mailman/mm/bin/django-admin compress* > > CommandError: An error occurred during rendering > > > /opt/mailman/mm/venv/lib/python3.7/site-packages/HyperKitty-1.3.4rc2-py3.7.egg/hyperkitty/templates/hyperkitty/404.html: > > /usr/local/lib/ruby/site_ruby/2.7/rubygems/dependency.rb:311:in > `to_specs': > > Could not find 'sass-listen' (~> 4.0.0) among 4 total gem(s) > ... > > > Ruby-sass is no longer supported. Please see the Sass compiler section > at > <https://docs.mailman3.org/en/latest/install/virtualenv.html#dependencies > >. > I uninstalled rubygem-sass from the OS. I don't remember consciously installing that because it was never in the guide I followed (which is your own writeup). But I still have a problem: (venv) [mailman3@gw ~/mm]$ /opt/mailman/mm/bin/mailman-post-update + '[' False == False ']' + mkdir -p /opt/mailman/mm/static + /opt/mailman/mm/bin/django-admin collectstatic --clear --noinput --verbosity 0 + /opt/mailman/mm/bin/django-admin compress CommandError: An error occurred during rendering /opt/mailman/mm/venv/lib/python3.7/site-packages/django_mailman3-1.3.5-py3.7.egg/django_mailman3/templates/socialaccount/signup.html: */bin/sh: sass: not found* pip3 install sass fails: ..... ERROR: Command errored out with exit status 1: /opt/mailman/mm/venv/bin/python -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-vnlujru1/sass_15812b8baa1b405c8130edb21a4f4316/setup.py'"'"'; __file__='"'"'/tmp/pip-install-vnlujru1/sass_15812b8baa1b405c8130edb21a4f4316/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' install --record /tmp/pip-record-_f8rgww1/install-record.txt --single-version-externally-managed --compile --install-headers /opt/mailman/mm/venv/include/site/python3.7/sass Check the logs for full command output. The complete failure text is at https://pastebin.ubuntu.com/p/tsB2CCNrQG/ Maybe it's time to blow up everything in the virtualenv and start over because I am not sure what caused this. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", grep ^[^#] :-)

5 years, 6 months

[MM3-users] upgraded Django & flufl.lock now do not receive own postings

by Christian

I just upgraded Django from version 3.0.11 to 3.2.15 receiving this confirmation > Successfully installed Django-3.2.15 asgiref-3.5.2 I also upgraded flufl.lock from version 7.0 to 7.1 > Successfully installed flufl.lock-7.1 Then I restarted mailman, qcluster & gunicorn Now for some reason I'm not receiving my own postings to the list whereas before I was. 'Receive own postings' is still set to yes. Thank you! -----Original Message----- From: David Newman <dnewman(a)networktest.com> Sent: Friday, July 8, 2022 11:29 AM To: mailman-users(a)mailman3.org Subject: [MM3-users] Re: FYI: Django security releases issued: 4.0.6 and 3.2.14 On 7/8/22 6:34 AM, Stephen J. Turnbull wrote: > David Newman writes: > > > Interesting -- that does produce two directories with names starting > > with a tilde: > > > > /opt/mailman/venv/lib/python3.9/site-packages/~jango: > > /opt/mailman/venv/lib/python3.9/site-packages/~jango-3.0.14.dist-info: > > I would guess that those are the previous versions before the upgrade, > moved out of the way in case a revert-to-previous was needed. Again, > guessing, they should have been removed by the upgrade process once > the new package was fully installed. Was there an interrupted or > partially successful upgrade in the past? Yes > > So I would guess you can remove them. Probably you have the relevant > Ubuntu packages cached somewhere, and they're probably available from > Ubuntu if you really wanted them. This system runs Debian 11, with everything installed in a venv. I'm unclear on the relationship between the usual apt* tools and pip, and just do everything Mailman-related using pip. On 7/8/22 7:47 AM, Mark Sapiro wrote: > When pip is doing an upgrade of the xyz package, it renames the existing > package as ~yz and then ultimately deletes the old ~yz package after > successfully installing the new xyz. In this case, the upgrade was > aborted because of the Django<3.1 constraint in mailman-web and > apparently pip then installed Django<3.1 and left the ~jango* > directories behind. Ahhh, that explains it. Thanks for your replies. I've deleted the ~ directories and so far have not noticed any adverse effects. dn _______________________________________________ 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, 10 months

[MM3-users] Re: Message shows up individually but not in the thread

by Marvin Gülker

Am 03. November 2017 um 12:35 Uhr -0700 schrieb Mark Sapiro <mark(a)msapiro.net>: > Are you running all of Django's periodic tasks? They are running. This is the excerpt from /etc/crontab: # Mailman jobs @daily mailman bash -c 'cd /home/mailman && . /home/mailman/env3/bin/activate && mailman digests --send' @hourly mailman bash -c 'cd /home/mailman && . /home/mailman/env2/bin/activate && django-admin runjobs hourly --pythonpath /home/mailman/mailman-suite/mailman-suite_project --settings settings' @daily mailman bash -c 'cd /home/mailman && . /home/mailman/env2/bin/activate && django-admin runjobs daily --pythonpath /home/mailman/mailman-suite/mailman-suite_project --settings settings' @weekly mailman bash -c 'cd /home/mailman && . /home/mailman/env2/bin/activate && django-admin runjobs weekly --pythonpath /home/mailman/mailman-suite/mailman-suite_project --settings settings' @monthly mailman bash -c 'cd /home/mailman && . /home/mailman/env2/bin/activate && django-admin runjobs monthly --pythonpath /home/mailman/mailman-suite/mailman-suite_project --settings settings' @yearly mailman bash -c 'cd /home/mailman && . /home/mailman/env2/bin/activate && django-admin runjobs yearly --pythonpath /home/mailman/mailman-suite/mailman-suite_project --settings settings' * * * * * mailman bash -c 'cd /home/mailman && . /home/mailman/env2/bin/activate && django-admin runjobs minutely --pythonpath /home/mailman/mailman-suite/mailman-suite_project --settings settings' 2,17,32,47 * * * * mailman bash -c 'cd /home/mailman && . /home/mailman/env2/bin/activate && django-admin runjobs quarter_hourly --pythonpath /home/mailman/mailman-suite/mailman-suite_project --settings settings Obviously, mailman-suite is installed at /home/mailman/mailman-suite and owned by user 'mailman', with the actual Django project in the subdirectory 'mailman-suite_project', just as cloned from the Git repository. The only difference from the official guide here is that I took the liberty to place Mailman into two virtualenvs (a Python2 one for the Django project, and a Python3 one for Mailman-Core*). There are no errors reported with this in /var/log/cron.log. And before you ask, the task queue is running as well. The uWSGI config has this: # Setup the django_q related worker processes. attach-daemon = ./manage.py qcluster And the qcluster process shows both up in the process list and is happily logging away in the uWSGI log. Greetings Marvin * It'd be great if the mailman-suite was moved to Python 3 at some point. That way one wouldn't need two separate virtualenvs. -- Blog: https://www.guelkerdev.de PGP/GPG ID: F1D8799FBCC8BC4F

8 years, 8 months

[MM3-users] Re: I did something stupid. Can i back out of it?

by William Oliver

On Sat, 2022-02-19 at 12:03 -0800, Mark Sapiro wrote: > On 2/19/22 08:33, William Oliver wrote: > > > > So... I run a small mailinglist using mailman3 that has been > > workiing > > great for a couple of months. Last week, all my users from gmail > > got > > kicked off because gmail decided that the list messages were > > "unsolicited email". I didn't find out about it until the users > > hit > > their mailman3 bounce limit. I *thought* would be seeing all the > > bounce messages, but apparently not. I didn't see any config > > settings > > for "see all the bounce messages" so i thought to myself, "Self, > > well > > maybe that's because my mailinglist username doesn't have a > > mailbox in > > /home/listname". > > > Assuming your Mailman core version is 3.3.5 and Postorius is 1.3.6, > you > will see settings like `Notify owner on bounce increment`, ` Notify > owner on disable` and `Notify owner on removal` under `Bounce > Processing`. Presumable you did get the notification of removal, so > delivery to the owner works. Are the increment and disable (or maybe > just disable if your versions are older) notices set to Yes? Found it. Thanks. > > > > So, I decided to try that. I created /home/listname/Maildir/* and > > logged in as fplist to see if it would put mail there. In order to > > log > > in as listname, I gave the user listname a password. > > > Can't you just reverse those steps. I.e. remove /home/listname/ and > remove the listname user? > Well, that was my inclination, but I didn't know if I needed to have a user by the name of listname. I was afraid that if I just deleted the user "listname" it would cause even more problems. I had created that user back when I was using another mailinglist package -- a Joomla plugin (that doesn't work nearly as well as mailman3). I was afraid to just type in "userdel -r" in case mailman3 needed a "real" user... So, I can just kill the listname user altogether? billo

4 years, 5 months

Search results for query "sapiro"