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

[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

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

3 years, 4 months

[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"

4 years, 8 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)

4 years, 11 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 ^[^#] :-)

4 years, 5 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/

2 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

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

3 years, 4 months

[MM3-users] Re: mailman-cli tools

by Abhilash Raj

On Wed, Sep 27, 2017, at 10:29 AM, Dmitry Makovey wrote: > On 09/27/2017 10:20 AM, Abhilash Raj wrote: > > On Wed, Sep 27, 2017, at 08:44 AM, Mark Sapiro wrote: > >> On 09/27/2017 08:26 AM, Dmitry Makovey wrote: > >>> On 09/27/2017 08:25 AM, Dmitry Makovey wrote: > >>>> I've come across mailman-cli docs: > >>>> > >>>> http://mailman-cli.readthedocs.io/en/latest/src/mailmanclient/cli/docs/usin… > >>>> > > > > This is basically one of our GSoC projects which hasn't yet been merged > > with MailmanClient. It uses the REST API to to provide a command line > > client for Mailman, while there hasn't been any in-compatible changes in > > API since this project was finished, I am not sure about the current > > status of it. > > > >>>> yet I cannot figure out what's the official source for the installation. > > > > Official source for MailmanClient is at gitlab.com/mailman/mailmanclient > > and it doesn't have a CLI, the Github project you linked to says right > > on the top that it is not official project (Thanks for that Rajeev!). > > I did see that, thus I was asking the question here. > > > Also, I would say not to use this client to remotely access Mailman, the > > REST API is not meant to be exposed over internet (unless you have a VPN > > or other sort of setup to securely access the box remotely). > > > > in my case - I need to use REST API since we're deploying with docker > and pieces that need to integrate with mailman commands now live in a > different container (and very likely on a different machine). I do need > to be able to execute commands remotely - I can handle securing of that > connection, but it is not an option for me to run "fat" docker > containers thus the only interconnect is via sockets (either UNIX or > TCP). The CLI project is basically a Shell+CLI based on MailmanClient (python library for Mailman API) and Mailman Core's REST API. So, if I understand correctly, this would run commands over REST API like you want. -- Abhilash Raj maxking(a)asynchronous.in

7 years, 9 months

[MM3-users] Re: mailman-core installation on debian stretch/maria-db

by Wolfgang Bock

Am 10.03.2018 um 23:44 schrieb Mark Sapiro: > How? Did you install > <https://packages.debian.org/stretch-backports/mailman3-core>? -> No, if I had known this, I wouldn't waste my time for the last 3 days in fiddeling and googleling ... > If so, these are probably issues with the Debian package. > > You may find<https://gitlab.com/mailman/mailman/issues/455> to be of > interest. > > If you installed Mailman some other way, How? -> From here: http://docs.mailman3.org/en/latest/prodsetup.html#installing-mailman-core including dependencies > >> 1. On "mailman start" I got the error message: >> Starting Mailman's master runner >> /usr/bin/python3: can't open file '/sbin/master': [Errno 2] No such file >> or directory > Where is it? What does 'which master' show? -> /usr/local/bin/master -> After I set a symlink to /sbin/master another errormessage occurs >> 2. connection to maria-db >> In debian stretch maria-db is running. In my mailman.cfg I set: >> [database] >> class: mailman.database.mysql.MySQLDatabase >> url: >> mysql+pmysql://#username#:#user-pawo#@localhost/#databasename#?charset=utf8&use_unicode=1 > should that be mysql+pymysql ? -> Yes, according to: http://mailman.readthedocs.io/en/latest/src/mailman/docs/database.html -> Not right?? After that I decided to delete mailman via pip and took a new approach via debians apt-get ... mailman 3 So far so good, now new errormessage: Traceback (most recent call last): File "/usr/local/bin/mailman", line 11, in <module> sys.exit(main()) File "/usr/local/lib/python3.5/dist-packages/mailman/bin/mailman.py", line 94, in main initialize(config_path) File "/usr/local/lib/python3.5/dist-packages/mailman/core/initialize.py", line 189, in initialize initialize_2(propagate_logs=propagate_logs) File "/usr/local/lib/python3.5/dist-packages/mailman/core/initialize.py", line 160, in initialize_2 config.db = getUtility(IDatabaseFactory, utility_name).create() File "/usr/local/lib/python3.5/dist-packages/mailman/database/factory.py", line 52, in create database = call_name(database_class) File "/usr/local/lib/python3.5/dist-packages/mailman/utilities/modules.py", line 67, in call_name named_callable = find_name(dotted_name) File "/usr/local/lib/python3.5/dist-packages/mailman/utilities/modules.py", line 51, in find_name return getattr(sys.modules[package_path], object_name) AttributeError: module 'mailman.database.mysql' has no attribute 'MYSQLDatabase' Another question is, where can I find the sql-command within the database mailman3 like CREATE TABLE x and TABLE y as I created a database mailman3 which is empty?? Thanks for your help in advance. Regards Wolfgang

7 years, 3 months

Search results for query "sapiro"