Re: moving lists to another server
by Mark Sapiro
On 11/21/23 04:32, Odhiambo Washington wrote:
>
> I tested the above out of curiosity. It failed. There are 9 lists in the
> setup, but I am only interested in 1.
>
> ```
> (venv) mailman@debian12:~$ mailman-web shell
> Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0]
> Type 'copyright', 'credits' or 'license' for more information
> IPython 8.17.2 -- An enhanced Interactive Python. Type '?' for help.
>
> In [1]: from hyperkitty.lib.compat import get_list_by_name
>
> In [2]: mlist = get_list_by_name('list_name_only', 'list_domain')
You can't use literally ('list_name_only', 'list_domain'). If the list
of interest is for example alist(a)example.com, the above should be
mlist = get_list_by_name('alist', 'example.com')
...
> Was I supposed to substitute something for the real listname of the list I
> wanted?
Yes.
> Another thing - totally unrelated - that surprised me:
> While using the commented-out block below, I could not click and get
> anything beyond http://http://list.name/mailman3 as anything to do with
> /postorius/xxxxx gave "Page not found" error.
> However, with the second config block that uses the UNIX socket, I am able
> to access everything
>
> ```
> #<IfModule mod_proxy.c>
> # ProxyPreserveHost On
> # ProxyPass "/mailman3" "http://127.0.0.1:8010/mailman3"
> # ProxyPass "/archives" "http://127.0.0.1:8010/archives"
> # ProxyPass "/accounts" "http://127.0.0.1:8010/accounts"
> # ProxyPass "/admin" "http://127.0.0.1:8010/admin"
> # ProxyPass "/user-profile" "http://127.0.0.1:8010/user-profile"
> # </IfModule>
>
> ProxyPassMatch ^/static/ !
> ProxyPassMatch ^/favicon.ico !
> ProxyPass / unix:/opt/mailman/mm/var/uwsgi.sock|uwsgi://localhost/
> ProxyPassReverse / unix:/opt/mailman/mm/var/uwsgi.sock|uwsgi://localhost/
> ```
>
> Why is it that the UNIX socket option worked flawlessly while the other
> option failed???
The first option does not have ProxyPass for urls matching /postorius or
/hyperkitty so such urls don't work. The second option passes everything
(ProxyPass / ) to uwsgi via the socket so all urls that uwsgi can handle
will work.
You could do something similar with the first option with simply
ProxyPass "/" "http://127.0.0.1:8010/"
assuming uwsgi is listening on port 8010.
--
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
1 year
Re: Mailman 3 deployment: ok to use same database instance for core, web, and hyperkitty tables?
by Andrew Hodgson
Stephen J. Turnbull wrote:
>s.dobrau(a)ucl.ac.uk writes:
> > We are currently working on a migration plan for Mailman -> Mailman > 3. We have around over 3000 mailing lists with a total of 50K > members
>Medium-size. I guess a 2-CPU/4GB Linode or similar should handle the Mailman load (including Postorius and HyperKitty), you might want more memory and maybe more CPUs if you're running the RDBMS on the same host. In the 23k lists/50k users/100k inbound messages/day migration described below, >we ended up reconfiguring the VMs 3 times before declaring the system stable. IMO the 2 x 8CPU/16GB final setup was way overpowered for the need, but we didn't try to calibrate finer than that.
Yep, I have helped a migration with around 150 lists but not as much archived data, and ended up with a 2 CPU with 8GB machine. I think we could have gone lower, but found we needed the larger VM to help us import the archives. I used a managed PostGreSQL instance from Amazon for the database.
> > Our plan is to have core+web (instance 1) and Hyperkitty (instance > 2). With the archives on the FS local to the Hyperkitty.
>The archives are in the database as BLOBs. There's no reason to have a separate instance for HyperKitty. It's not obvious to me that you need more than that 2x4 Linode for both Mailman and RDBMS, but if you're going to split it's Mailman vs RDMBS, not Mailman vs HyperKitty.
I would agree. I think the issue here is there are several ways of splitting out Mailman people get bogged down in whether they should run separate parts on different instances. In my view I have always ran Mailman, Postorius and Hyperkitty on the same host and I think it works better that way. For example, if you run Mailman and the web components on different hosts, you need to make sure the Mailman REST interface is secured, whereas if its on the same host then the REST interface can just listen on localhost. The Dockerised instances do use separate containers for Mailman Core and the web components, but that is the only real time I have seen the components split.
> > And all 3 tables (core, web, Hyperkitty) pointing to the same > database on a remote SQL (mysql-enterprise) instance. Using class > mailman.database.mysql.MySQLDatabase (and whatever necessary on the > Django/Hyperkitty instance).
>Make sure your MySQL database(s) for Mailman are configured with the utf8mb4 option for 4 byte UTF-8 support, or it will choke on emojis and the like. I don't think there are any other gotchas for MySQL.
Are there any performance benchmarks for running MySQL vs PostGreSQL? I tend to fall back to PostGreSQL because it seems to be what is used in a lot of places, I have never recommended going with MySQL for a Mailman instance.
>Note there are a lot more than 3 tables in Mailman's databases. The "traditional" configuration is a "mailman" database for core and a "mailmanweb" database for Django and the archives, but Mark says that as the tables are disjoint across Mailman, Django, and the archives there's no reason not to use a >single "mailman" database for all of them. I believe that's how this list's host is configured.
Yep, the original installation guide created one database for Mailman and the tables for all components are in the same database, this was how my larger install was done. Later revisions of the guide have us split the core vs web components to different databases, I don't think there is any performance hit either way by doing that.
>Importing list configurations, users, and subscriptions into Mailman 3 is pretty fast, as long as you're not using the stock Postfix support.[2] The problem is that generating the Postfix alias files for the lists seems to be noticably linear in number of lists, which means it's quadratic for the mass import. IIRC with >5000 lists you'd be looking at >1m/list just to keep regenerating Postfix's alias database, ie 5000 minutes. I found two solutions, both of which required patching Mailman. I hope to get both into the next release.
>I think we got it down to <5s/list, for 5000 lists that's < 1hr.
That is very interesting I had a similar issue with the Postfix alias generation in my larger setup but didn't have time to identify the root cause. In the end I used Exim sending all mails for the list domain to Mailman which is the setup I use elsewhere and it doesn't rely on the alias file generation.
>Importing archives is ... yeeech. The client decided they didn't want a ton of archives anyway (you know corporations, if it's not required by law, shred it after 6 months). I don't recall the size estimate accurately but we kept 6 months X 4500 lists, maybe 100GB out of 2.3TB of mboxes. That took 24 hours to >import into HyperKitty, without doing the full-text indexing. I do know the original conservative estimate was 20 days to import the whole 2,3 TB. The full-text indexing took more than a week if I remember correctly.
Yes, I had the same problem with the archives. I did import all the archives, in our case it took us several months to get the archives in so as not to stress load on the box. Full text indexing really caused an issue for me, I ended up disabling it for the time we were importing archives then generated a clean index once the archives were imported. This wasn't a good user experience and I would probably plan this out better next time.
>It's also quite possible to migrate incrementally, a few lists at a time. Mailman 2 and Mailman 3 can coexist happily on the same host.
>Mark can advise on that, I think.
Its worth noting this is more difficult to do now on Debian/Ubuntu installs as Python2 has been removed. This was something I ran into myself when trying to co-exist both installs on the same box.
Andrew.
1 year
how to migrate mailing lists to a new domain using mailman 3
by C. Souza
In a few days my current domain will be disabled (it is out of my control)
and I would like to know how to migrate the mailing lists to the new domain
name.
As a solution I added a new domain in mailman 3 and created a script that
replicates the lists in this new domain. To forward the emails received by
the old lists, the script removes the members and adds the email of the new
list.
Is there a fashionable way to do that?
Also, one problem that I don't have a solution is the archive of the old
lists. How to bring them to the new ones?
Thanks for your help.
My mailing list server is running on a CenOS-7x with postgreSQL and the
following mailman packages:
Package Version
------------------- ----------
1 aiosmtpd 1.2.4
2 alembic 1.5.3
3 arrow 0.17.0
4 asgiref 3.3.1
5 atpublic 2.1.2
6 authheaders 0.13.0
7 authres 1.2.0
8 bleach 3.3.0
9 blessed 1.17.12
10 certifi 2020.12.5
11 cffi 1.14.4
12 chardet 4.0.0
13 click 7.1.2
14 cmarkgfm 0.5.2
15 cryptography 3.3.1
16 decorator 4.4.2
17 defusedxml 0.6.0
18 Django 3.0.12
19 django-allauth 0.44.0
20 django-appconf 1.0.4
21 django-compressor 2.4
22 django-extensions 3.1.0
23 django-gravatar2 1.4.4
24 django-haystack 3.0
25 django-mailman3 1.3.5
26 django-picklefield 3.0.1
27 django-q 1.3.4
28 djangorestframework 3.12.2
29 dkimpy 1.0.5
30 dnspython 2.1.0
31 docutils 0.16
32 falcon 2.0.0
33 flufl.bounce 3.0.1
34 flufl.i18n 2.0.2
35 flufl.lock 3.2
36 gunicorn 20.0.4
37 HyperKitty 1.3.3
38 idna 2.10
39 importlib-resources 5.1.0
40 lazr.config 2.2.3
41 lazr.delegates 2.0.4
42 mailman 3.3.2
43 mailman-hyperkitty 1.1.0
44 mailman-web 0.0.3
45 mailmanclient 3.3.2
46 Mako 1.1.4
47 MarkupSafe 1.1.1
48 networkx 2.5
49 nose 1.3.7
50 oauthlib 3.1.0
51 packaging 20.9
52 passlib 1.7.4
53 pip 21.0.1
54 postorius 1.3.3
55 psycopg2-binary 2.8.6
56 publicsuffix2 2.20191221
57 pycparser 2.20
58 Pygments 2.7.4
59 PyJWT 2.0.1
60 pyparsing 2.4.7
61 python-dateutil 2.8.1
62 python-editor 1.0.4
63 python3-openid 3.2.0
64 pytz 2021.1
65 rcssmin 1.0.6
66 readme-renderer 28.0
67 requests 2.25.1
68 requests-oauthlib 1.3.0
69 rjsmin 1.1.0
70 robot-detection 0.4
71 setuptools 39.2.0
72 six 1.15.0
73 SQLAlchemy 1.3.23
74 sqlparse 0.4.1
75 typing-extensions 3.7.4.3
76 urllib3 1.26.3
77 uWSGI 2.0.19.1
78 wcwidth 0.2.5
79 webencodings 0.5.1
80 wheel 0.36.2
81 Whoosh 2.7.4
82 zipp 3.4.0
83 zope.component 4.6.2
84 zope.configuration 4.4.0
85 zope.deferredimport 4.3.1
86 zope.deprecation 4.4.0
87 zope.event 4.5.0
88 zope.hookable 5.0.1
89 zope.i18nmessageid 5.0.1
90 zope.interface 5.2.0
91 zope.proxy 4.3.5
92 zope.schema 6.0.1
-- Carlos Souza
2 years, 4 months
Re: List creation error
by Brian Carpenter
Odhiambo Washington wrote:
> On Wed, 6 Jan 2021 at 15:36, Andreas Barth aba(a)ayous.org wrote:
> >
> > Odhiambo Washington (odhiambo(a)gmail.com) [210106 12:12]:PS: I could probably have caused the error with some weird operation I
> > did:
> > Initially when postorius comes up, it has the domain - example.com
> > http://example.com. I am not sure
> > where it gets this.
> >
> >
> > example.com is the default domain from django. Renaming that via the
> > django (e.g. mailman3/admin/sites/site/1/change/ ) worked for me quite
> > well (without touching anything in the database by hand).
> > Hi Andi,
> I could be missing something still...
>
> At what juncture during the installation do you do this renaming?
> Where is this directory? On my setup, I have no such directory - but I
> could be missing something in the install process, maybe..
>
> root@debian10:/opt/mailman# pwd
> /opt/mailmanroot@debian10:/opt/mailman# find . -type d -name sites
> ./mm/venv/lib/python3.7/site-packages/jedi/third_party/django-stubs/django-stubs/contrib/sites
> ./mm/venv/lib/python3.7/site-packages/django/contrib/sites
> Do you find anything amiss with this HOWTO -
> https://wiki.list.org/DOC/Howto_Install_Mailman3_On_Debian10 ?? I
> find
> the guide rather straight and clear.
That is my work in progress and thank you for the compliment.
> It's the one I am following - almost to the letter - except for the fact
> that I am using Apache+mod_wsgi+MySQL+Exim instead.
> I have configs in place by the time I run 'mailman info' portion. But then
> again, when I run this command, I don't like what it prints because I see
> some reference to sqlite.
Can you paste what the mailman info output is and the contents of your mailman.cfg file?
> As it is, I believe my problem lies elsewhere, not possible to solve with
> your rename option.
To get rid of example.com, I log into Django, create a new site using the main list domain and note the site id. I then edit the settings_local.py file and change the SITE_ID setting to the new site id of the main list domain. You will need to restart mailman and qcluster I believe after making that change.
3 years, 10 months
Re: Digest Formatting
by Mark Sapiro
On 11/7/20 9:08 AM, Stephen J. Turnbull wrote:
>
> I thought there was a way to trigger immediate distribution of a
> digest immediately, but I guess I'm remembering that from Mailman 2.
> Neither the Postorius management interface nor the core documentation
> suggests there's such a trigger in Mailman 3.
There is nothing in the web UI or REST, but the `mailman digests`
command can send accumulated digests for one or more named lists or all
lists unconditionally or only if the list's digest_send_periodic is set
to True. see `mailkman digests --help` for details.
> > 2) I have customized list:member:digest:header, but am not seeing
> > the custom text where I thought it should be. The documentation
> > seems to imply that both list:member:digest:header and
> > list:member:digest:footer surround each message in the digest
>
> Which documentation do you mean? As far as I know (Mark will have
> authoritative information if I'm wrong), the digest header and footer
> appear at the top and bottom of the *whole* digest message (ie, once
> each per digest), not surrounding or in the bodies of the component
> messages.
Steve is correct. The layout is as follows
The masthead from the list:member:digest:masthead template.
The digest header if any from the list:member:digest:header template.
The table of contents.
The individual messages.
The digest footer from the list:member:digest:footer template.
For the MIME digest, these are all separate MIME parts and the
individual messages are message/rfc822 parts within a multipart/digest part.
For the plain text digest, the digest is one text/plain part containing
the above formatted par RFC 1153
And in another post, mailman(a)manygoodideas.com wrote:
> I also have a feature request (I didn't see it in the docs), consider creating list:member:digest:mastfoot – a chunk of text that could be at the end of the digest. Thanks.
This already exists, it is list:member:digest:footer. Your confusion
seems to be because you think the list:member:digest:header template and
list:member:digest:footer template are prepended/appended to each
individual message in the digest which would not make sense and is not
the case.
--
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
4 years
Re: Apache+mod_wsgi issue
by Eggert Ehmke
Am Montag, 26. Dezember 2022, 16:08:42 CET schrieb Odhiambo Washington:
> On Mon, Dec 26, 2022 at 5:07 PM Eggert Ehmke <eggert(a)eehmke.de> wrote:
> > Ok,
> >
> > I hope this is readable. I just copíed the content of some files into the
> > pastebin, don't know if it is possible to post tar.gz there.
> > https://pastebin.ubuntu.com/p/mmRJJwKDc3/
> >
> > Just tell me if this works for you, and when something is missing.
> > Most of the settings are copied from some other sites and just adjusted
> > for my
> > needs.
> > Good luck!
>
> So it seems your WSGIDaemonProcess is defined somewhere outside the VHOST,
> right? Or it wasn't necessary?
I have no settings for WSGIDaemon whatsoever. It's all handled by the uwsgi
inside the venv.
> And what does your urls.py look like?
Which of the various urls.py files do you need?
>
> My setup is PUBLIC for everyone so I will not hide the domain name :-)
>
> In my setup, MM3 is installed in /opt/mailman/mm/. and mod_wsgi is enabled
> in Apache.
> I am running uwsgi on a TCP socket, not unix socket.
>
> The whole of my *VHOST:*
> <CUT>
> WSGIDaemonProcess mailman-web display-name=mailman-web
> maximum-requests=1000 umask=0002 user=mailman group=mailman
> python-path=/opt/mailman/mm:/opt/mailman/mm/venv/lib/python3.9/site-packages
> :/opt/mailman/mm/venv/lib/python3.9 python-home=/opt/mailman/mm/venv
> home=/opt/mailman/mm/var
> WSGIRestrictSignal Off
> <VirtualHost *:443>
> ServerName mm3-lists.kictanet.or.ke
>
> SSLEngine on
> SSLCertificateFile "/usr/local/etc/letsencrypt/live/
> mm3-lists.kictanet.or.ke/cert.pem"
> SSLCertificateKeyFile "/usr/local/etc/letsencrypt/live/
> mm3-lists.kictanet.or.ke/privkey.pem"
> SSLCertificateChainFile "/usr/local/etc/letsencrypt/live/
> mm3-lists.kictanet.or.ke/chain.pem"
> CustomLog /var/log/mm3-lists-access.log combined
> ErrorLog /var/log/mm3-lists-error.log
> LogLevel info
> Alias /favicon.ico /opt/mailman/mm/static/hyperkitty/img/favicon.ico
> Alias /static "/opt/mailman/mm/static"
> <Directory "/opt/mailman/mm/static">
> Require all granted
> </Directory>
> WSGIScriptAlias / /opt/mailman/mm/wsgi.py
> <Directory "/opt/mailman/mm/">
> <Files wsgi.py>
> Order deny,allow
> Allow from all
> Require all granted
> </Files>
> WSGIProcessGroup mailman-web
> </Directory>
> </VirtualHost>
> </CUT>
>
> *2. uwsgi.ini:*
> <CUT>
> [uwsgi]
> http-socket = 127.0.0.1:8000
> pidfile = /opt/mailman/mm/var/uwsgi.pid
> chdir = /opt/mailman/mm/
> virtualenv = /opt/mailman/mm/venv/
> module=mailman_web.wsgi:application
> env =PYTHONPATH=/opt/mailman/mm/
> env =DJANGO_SETTINGS_MODULE=settings
> master = true
> process = 2
> threads = 2
> attach-daemon = /opt/mailman/mm/venv/bin/mailman-web qcluster
> req-logger = file:/opt/mailman/mm/var/logs/uwsgi.log
> logger = qcluster file:/opt/mailman/mm/var/logs/uwsgi-qcluster.log
> log-route = qcluster uwsgi-daemons
> logger = cron file://opt/mailman/mm/var/logs/uwsgi-cron.log
> log-route = cron uwsgi-cron
> logger = file:/opt/mailman/mm/var/logs/uwsgi-error.log
> uid = mailman
> gid = mailman
> </CUT>
>
> *3. uwsgi - *Running supervised (supervisord):
> <CUT>
> [program:uwsgi]
> directory=/opt/mailman/mm/
> environment=PYTHONPATH=/opt/mailman/mm/
> command=/usr/bin/su -m mailman -c '/opt/mailman/mm/venv/bin/uwsgi --ini
> /opt/mailman/mm/uwsgi.ini' 2>&1 | logger -t uwsgi
> autostart=true
> autorestart=true
> user=mailman
> group=mailman
> stopasgroup=true
> killasgroup=true
> </CUT>
>
> *4. urls.py*:
> <CUT>
> from django.conf.urls import include
> from django.urls import re_path
> from django.contrib import admin
> from django.urls import reverse_lazy
> from django.views.generic import RedirectView
> from django_mailman3.views.profile import delete_account, user_profile
> urlpatterns = [
> re_path(r'^$', RedirectView.as_view(
> url=reverse_lazy('list_index'),
> permanent=True)),
> re_path(r'^postorius/', include('postorius.urls')),
> re_path(r'^hyperkitty/', include('hyperkitty.urls')),
> re_path(r'^user-profile/delete$', delete_account,
> name='mm_user_account_delete'),
> re_path(r'^user-profile/$', user_profile, name='mm_user_profile'),
> re_path(r'^accounts/', include('allauth.urls')),
> re_path(r'^admin/', admin.site.urls),
> re_path(r'^mm/', include('postorius.urls')),
> re_path(r'^archives/', include('hyperkitty.urls')),
> ]
> </CUT>
>
> And that's pretty much what I am using on my FreeBSD server.
>
>
> PS: Possible to bottom-post instead of top-posting? :)
1 year, 11 months
Re: Mailman3 without Hyperkitty in docker
by Danil Smirnov
Hi Abhilash,
Thank you very much - the previous error is fixed now.
But I have another one now, which causes the same 500 Server Error:
bash-4.3# cat /opt/mailman-web-data/logs/uwsgi-error.log
*** Starting uWSGI 2.0.18 (64bit) on [Fri Mar 1 05:42:09 2019] ***
compiled with version: 6.3.0 on 01 March 2019 01:52:42
os: Linux-3.10.0-693.11.1.el7.x86_64 #1 SMP Mon Dec 4 23:52:40 UTC 2017
nodename: mailman-web
machine: x86_64
clock source: unix
detected number of CPU cores: 2
current working directory: /opt/mailman-web
detected binary path: /usr/local/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
setgid() to 101
setuid() to 100
chdir() to /opt/mailman-web
your memory page size is 4096 bytes
detected max file descriptor number: 1048576
building mime-types dictionary from file /etc/mime.types...1168 entry found
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uwsgi socket 0 bound to TCP address 0.0.0.0:8080 fd 8
uwsgi socket 1 bound to TCP address 0.0.0.0:8000 fd 9
Python version: 3.6.8 (default, Jan 30 2019, 23:58:16) [GCC 6.3.0]
Python main interpreter initialized at 0x55a2df7f57e0
python threads support enabled
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 166752 bytes (162 KB) for 2 cores
*** Operational MODE: threaded ***
Traceback (most recent call last):
File
"/usr/local/lib/python3.6/site-packages/django/utils/module_loading.py",
line 20, in import_string
return getattr(module, class_name)
AttributeError: module 'django.contrib.auth.middleware' has no attribute
'SessionAuthenticationMiddleware'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "wsgi.py", line 38, in <module>
application = get_wsgi_application()
File "/usr/local/lib/python3.6/site-packages/django/core/wsgi.py", line
13, in get_wsgi_application
return WSGIHandler()
File
"/usr/local/lib/python3.6/site-packages/django/core/handlers/wsgi.py", line
136, in __init__
self.load_middleware()
File
"/usr/local/lib/python3.6/site-packages/django/core/handlers/base.py", line
34, in load_middleware
middleware = import_string(middleware_path)
File
"/usr/local/lib/python3.6/site-packages/django/utils/module_loading.py",
line 24, in import_string
) from err
ImportError: Module "django.contrib.auth.middleware" does not define a
"SessionAuthenticationMiddleware" attribute/class
unable to load app 0 (mountpoint='') (callable not found or import error)
*** no app loaded. going in full dynamic mode ***
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 1)
spawned uWSGI worker 1 (pid: 37, cores: 2)
--- no python application found, check your startup logs for errors ---
--- no python application found, check your startup logs for errors ---
--- no python application found, check your startup logs for errors ---
--- no python application found, check your startup logs for errors ---
--- no python application found, check your startup logs for errors ---
--- no python application found, check your startup logs for errors ---
--- no python application found, check your startup logs for errors ---
--- no python application found, check your startup logs for errors ---
--- no python application found, check your startup logs for errors ---
--- no python application found, check your startup logs for errors ---
--- no python application found, check your startup logs for errors ---
--- no python application found, check your startup logs for errors ---
As per my investigation, this error possibly caused by Django upgrade:
*The SessionAuthenticationMiddleware class is removed. It provided no
functionality since session authentication is unconditionally enabled in
Django 1.10.*
See https://docs.djangoproject.com/en/2.0/releases/2.0/
After I've removed the line
https://github.com/maxking/docker-mailman/blob/master/postorius/mailman-web…
from settings.py, the container is finally working.
I've placed PR in github:
https://github.com/maxking/docker-mailman/pull/314
Thank you for your help.
Danil
пт, 1 мар. 2019 г. в 04:33, Abhilash Raj <maxking(a)asynchronous.in>:
>
>
> On Thu, Feb 28, 2019, at 5:19 PM, Abhilash Raj wrote:
> > On February 27, 2019 11:53:34 PM PST, Danil Smirnov <danil(a)smirnov.la>
> wrote:
> > >Hi Mark,
> > >
> > >Actually all this stuff happens inside the container after it's started
> > >and
> > >initialized without errors. I didn't amend the image anyhow.
> > >
> > >Also I have the configuration based on docker-compose.yaml provided in
> > >the
> > >repository which works just fine for mailman-web image.
> > >
> > >The very same config with postorius image (+ UWSGI_STATIC_MAP param)
> > >fails
> > >with 500 error...
> > >
> > >Now answering your questions:
> > >
> > >ср, 27 февр. 2019 г., 22:56 Mark Sapiro <mark(a)msapiro.net>:
> > >
> > >> do you have django-q in INSTALLED_APPS in your Django settings and
> > >what
> > >> is set for Q_CLUSTER?
> > >>
> > >
> > >I've checked settings.py inside the container and I haven't found any
> > >of
> > >the mentioned configurations there.
> > >
> > >Does the manage.py that's being run here point to the right
> > >settings.py?
> > >>
> > >
> > >No clue.
> > >
> > >Also I wonder why we have some Hyperkitty-related cronjobs in non-HK
> > >configured image?
> > >
> > >
> https://github.com/maxking/docker-mailman/blob/master/postorius/mailman-web…
> >
> > Because I am a dum dum ;-)
> >
> > Will work on removing those crons and stuff. Would be nice if you
> > opened an issue on Github so that I don't forget.
>
> Should now be fixed in the latest image.
>
> >
> > >Danil
> > >
> > >
> > >
> > >> --
> > >> 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/
> >
> >
> > --
> > Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
> --
> thanks,
> Abhilash Raj (maxking)
>
5 years, 8 months
Re: Mailman installation results in KeyError: 'env_py'
by Marvin Gülker
Am 22. October 2017 um 07:49 Uhr -0700 schrieb Mark Sapiro <mark(a)msapiro.net>:
> or you can install the fix at
Thanks. Applying this patch makes it work. Now I've got a different
problem, though. I can't get it to connect to Postfix for sending
emails it appears. After I created a superuser account using
$ python manage.py createsuperuser
as described on <http://postorius.readthedocs.io/en/latest/setup.html>,
I tried to login using this credentials into Postorius. It then reported
it sent a confirmation email to me (for an account I created on
commandline?!), but Postfix' logs reveal that it didn't; there's not
even a sign of an attempted delivery in /var/log/mail.log. I've
configured the Postfix configuration in mailman.cfg like this:
[mta]
incoming: mailman.mta.postfix.LMTP
outgoing: mailman.mta.deliver.deliver
lmtp_host: 127.0.0.1
lmtp_port: 8024
smtp_host: localhost
smtp_port: 25
configuration: python:mailman.config.postfix
as was outlined on
<http://mailman.readthedocs.io/en/latest/src/mailman/docs/mta.html>.
mailman-suite's settings.py contains:
# Change this when you have a real email backend
EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend'
EMAIL_HOST = 'localhost'
EMAIL_PORT = 25
which was described on <http://docs.list.org/en/latest/config-web.html>.
For completeness, the following is in Postfix' main.cf, but is not the
cause of the problem as it affects the incoming direction, whereas I
refer to the outgoing one:
transport_maps = hash:/home/mailman/var/data/postfix_lmtp
local_recipient_maps = hash:/home/mailman/var/data/postfix_lmtp
I failed to locate any kind of logging information about the failed
email, so I don't even know where I should start looking for the
problem. var/logs/smtp.log is empty in the mailman directory, and
likewise is logs/mailmansuite.log in the mailman-suite_project
directory.
That being said, the enormous number of configuration files to consider
and dozens of cross-references to other pages in the docs make the
installation guide hard to follow; it also lacks logical structure in my
opinion, when it refers to parts of the configuration which are later
explained. For someone like me who never programmed a Django application
(Ruby dev) this is all pretty cryptic. Especially, that some parts of
information are on <http://docs.list.org/en/latest/index.html> whereas
other parts are scattered over readthedocs.io makes it very
complicated.
Greetings
Marvin
--
Blog: https://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F
7 years, 1 month
Re: Easiest way to install a new mailman3 deployment?
by Andrew Hodgson
Hi,
I completed this on a Debian Buster server instance during last year and have got some notes on the process. I decided to go down the venv route rather than use Docker, but I already had it up and running using the Docker instance on another machine. I found getting it up and running on Docker helped me understand how everything hung together, but ultimately I wanted to run it under a venv so I could understand it a bit more and also I wasn't using Docker in the rest of the environment on that server. I also got caught out earlier on with the Docker containers changing the search engine from Woosh to Xapian which is why I wanted more control over what was going on. Here is a copy of those notes for interest.
I used package managers to provide PostgreSQL support as that was what the Docker install gave me to start with. I may have chosen another DB engine but as I was already using Postgres I stuck with that. I also installed Xapian using the package manager as well as Exim, Nginx, Sassc and Python using the package managers. I didn't install Memcached.
I mainly followed the instructions at: https://wiki.list.org/DOC/Mailman%203%20installation%20experience
My directory structure uses /opt/mailman as the base, the instructions on this web page use /opt/mailman/mm and I didn't have this extra subdirectory. I ensured this directory was owned by list:list.
I installed my venv under /opt/mailman/venv choosing to copy over the existing distribution installed Python packages and installed the following packages via Pip after activating it:
Upgrade packages that are already installed which need an upgrade to work with Mailman3:
pip3 install -U pip zope.interface
Get the rest installed:
pip3 install mailman mailmanclient django-mailman3 mailman-hyperkitty hyperkitty postorius psycopg2-binary xapian-haystack
This also installs Gunicorn which I use as the backend wsgi server.
The reason I chose to use existing system packages as part of the venv is because I wanted to use the Xapian installation I had installed via system packages as I ran into issues installing it via Pip. In future I think I will try and install the PostgreSQL driver this way as well.
Once deactivating the venv I recommend getting the directory structure and files copied to the right places from the links on the wiki, noting that in my cases I had to edit the files to change the relevant paths to suit my new layout, and also where necessary (Systemd units) change the user/group. . You should then run all the Mailman specific commands using these scripts in /opt/mailman/bin. I learnt the hard way that you will run into problems if you try and run Mailman from the venv directory as it will look for files in the wrong place and create data files in the wrong directory. As I went down this road my configuration files mailman.cfg and mailman-hyperkitty.cfg are actually located in /opt/mailman/etc but that isn't a requirement if you follow the wiki and use the scripts provided.
I obtained manage.py, settings.py, urls.py and wsgi.py from the Gitlab Mailman-suite project instead of the wiki site to ensure I got the latest versions and put these files in /opt/mailman. Regarding /opt/mailman/bin/mailman-post/update, I removed the references to Memcached as I didn't use it. I also didn't symlink /opt/mailman/logs to /opt/mailman/var/logs as advised by the wiki but will do this on a reinstall.
I generated a new Mailman PostgreSQL user and restored my existing database to the new server (which also upgraded the DB to a newer Postgresql version as the Docker-Compose from the Mailman Docker project uses an older Postgresql container).
I copied the Mailman runtime files from the Mailman core container data volume to /opt/mailman/var.
I generated a Hyperkitty API secret key and also a Django secret key.
Taking the mailman.cfg file from the wiki as a base, I updated the following parts:
[database]
class: mailman.database.postgresql.PostgreSQLDatabase
url: postgres://mailman:[password]@localhost/mailmandb
[mailman]
site_owner: mailman-owner(a)lists.domain.com
[mta]
incoming: mailman.mta.exim4.LMTP
configuration: python:mailman.config.exim4
[archiver.hyperkitty]
class: mailman_hyperkitty.Archiver
enable: yes
configuration: /opt/mailman/etc/mailman-hyperkitty.cfg
In /opt/mailman/etc/mailman-hyperkitty.cfg add the following:
[general]
base_url: http://localhost:8000/hyperkitty/
api_key: [generated-hyperkitty-api-key]
Using systemctl see if you can start Mailman and observe logs etc.
In terms of the Django stuff you need to create /opt/mailman/settings-local.py which will be read in by the system and will overwrite the default settings in /opt/mailman/settings.py obtained from the Mailman-suite project. This directly configures the Django framework which the Mailman web components Postorius and Hyperkitty run under.
Here is a outline copy of my file:
import os
BASE_DIR = os.path.dirname(os.path.abspath(__file__))
SECRET_KEY = '[generated-django-secret-key]'
MAILMAN_ARCHIVER_KEY = '[generated-hyperkitty-api-key]'
DEFAULT_FROM_EMAIL = 'mailman-owner(a)lists.domain.com'
EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend'
DEBUG = False
USE_X_FORWARDED_HOST = True
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
ALLOWED_HOSTS = [
'localhost',
'lists.domain.com'
]
INSTALLED_APPS = (
# Copy the installed apps from the settings.py and remove the social provider logins you don't want to support.
)
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'NAME': 'mailmandb',
'USER': 'mailman',
'PASSWORD': '[password]',
'HOST': 'localhost'
}
}
HAYSTACK_CONNECTIONS = {
'default': {
'PATH': os.path.join(BASE_DIR, "fulltext_index"),
'ENGINE': 'xapian_backend.XapianEngine'
},
}
LOGGING = {
# Copy the complete LOGGING section from settings.py and change the path as follows, if there is a way of just adding the relevant path override to this file let me know. I am doing this only because I didn't create a symlink for /opt/mailman/logs.
'version': 1,
'disable_existing_loggers': False,
'filters': {
[...]
}
},
'handlers': {
'mail_admins': {
[...]
},
'file':{
'level': 'INFO',
'class': 'logging.handlers.WatchedFileHandler',
'filename': os.path.join(BASE_DIR, 'var/logs', 'mailmansuite.log'),
'formatter': 'verbose',
},
'console': {
[...]
},
},
'loggers': {
'django.request': {
[...]
},
'django': {
[...]
},
'hyperkitty': {
[...]
},
'postorius': {
[...]
},
},
'formatters': {
'verbose': {
[...]
},
'simple': {
[...]
},
},
}
Try running /opt/mailman/bin/mailman-post-update and choose to rebuild indexes, see if the static files get saved to /opt/mailman/static and the search indexes get saved to /opt/mailman/fulltext_index. In my case I had plenty of indexing to do, not sure if these files are created on a green-field installation with nothing archived. This command will also populate the Postgresql database schema.
See if the Systemd units for mailman-web and mailman-cluster come up. Observe logs. If everything ok the Gunicorn should be listening on localhost:8000.
For Nginx integration I followed the wiki, only change I had to make was to send the host header to the backend server, here is a partial config file:
server {
server_name lists.domain.com;
root /var/www/lists;
access_log /var/log/nginx/lists-access.log;
error_log /var/log/nginx/lists-error.log warn;
listen [::]:443 ssl; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/lists.domain.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/lists.domain.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
location = /favicon.ico {
log_not_found off;
}
location = /robots.txt {
log_not_found off;
}
location / {
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $host;
proxy_pass http://localhost:8000/;
}
location /static {
alias /opt/mailman/static;
}
}
server {
if ($host = lists.domain.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
listen [::]:80;
server_name lists.domain.com;
return 404; # managed by Certbot
}
For Exim integration I followed to the letter the information here: https://mailman.readthedocs.io/en/latest/src/mailman/docs/mta.html#exim
Here is a Logrotate script which is not in the Mailman wiki:
/opt/mailman/var/logs/*.log {
missingok
sharedscripts
su list list
postrotate
/opt/mailman/bin/mailman reopen &>/dev/null || true
if [ -r /opt/mailman/var/gunicorn.pid ]; then
PID=`cat /opt/mailman/var/gunicorn.pid`
kill -s USR1 $PID
fi
endscript
}
I have been running this setup since March 2020, I run around 10 lists on this server with around 10 mails per list per day. I actually had more issues when moving from Mailman2 to Mailman3 using the Docker containers and actually this process made me understand a lot more how everything hangs together and where to troubleshoot issues.
Hope this helps someone out there.
Andrew.
-----Original Message-----
From: Matthew Alberti <matthew(a)alberti.us>
Sent: 01 January 2021 02:48
To: ieso(a)johnwillson.com
Cc: 'Mailman users' <mailman-users(a)mailman3.org>
Subject: [MM3-users] Re: Easiest way to install a new mailman3 deployment?
I had a very similar experience. I don't mean to knock the dev team; Mailman3 is an awesome tool that really meets a need. It is really much much more than a 'tool.' A very comprehensive software suite.
For me, I ended up using the docker option on Ubuntu 20.04. My advice is to give up on the idea of using OS package managers. They just aren't current enough (certainly for Ubuntu LTS), or updated frequently enough, for the current development of Mailman3. Nothing but problems for me on Ubuntu, and Debian is about the same.
Pypi, or installation in a virtualized environment, was equally challenging. I strongly recommend the docker installation method. It is not quite turnkey, but the documentation is close enough where it might 'just work' in your environment. I used MariaDB, and that introduced some challenges. If you are using postgre, postfix, and nginx, you are pretty close to a very easy installation.
This list is very supportive, with very frequent responses from the core dev team. And there are guys like me who really struggled to get to a production instance. Please let us all know what isn't working in the docker approach, and we will try to help I'm sure.
- Matt Alberti
Get BlueMail for Android
On Dec 31, 2020, 8:15 PM, at 8:15 PM, ieso(a)johnwillson.com wrote:
>So I've been trying for the last two weeks to get a new mailman3 server
>running on a virtualized server (any server), and I'm turning to this
>list after having failed many times and running out of holiday time.
>
>I started trying a non-docker installation on Ubuntu 18.04
>(https://docs.google.com/document/d/1xIcSsoNFp2nHi7r4eQys00s9a0k2sHhu1V
>5PlantPTs/edit#) , which got me the closest. Except I had a problem
>with inbound email only being triggered when it came from certain
>accounts. But that clearly wasn't good enough for production, so after
>many attempts to figure out where it was failing, I decided to turn to
>docker as a solution that should be cleaner.
>
>A few attempts at doing a docker installation on digitalocean.com
>failed, which I realized might be due to it not routing private IP
>addresses, so I moved to AWS after checking that their VPC policy would
>fit mailman's docker requirements. I found a great but slightly
>outdated guide on how to do this
>(https://xiaoxing.us/2018/01/01/deploy-mailman-3-on-aws-using-docker/).
>By this point I knew enough to correct a number of places where the
>environment had changed since the procedure was written, but postorius
>still failed at the curl test.
>
>The challenge for me has been the difficulty to know how to
>troubleshoot the different different systems and network infrastructure
>that are used to keep mailman3 humming. I've tried about 7 different
>installation walkthroughs (there are no recent ones on Youtube by the
>way, in case anyone wants to seize that opportunity!), and the good
>guides provide ways to check each stage to try to help you a bit on
>that front.
>
>Nonetheless, I feel stuck and thought I'd ask the simple question...
>for a completely basic, barebones new installation, what's the easiest
>way to get a mailman3 installation up-and running? (e.g. Which server
>provider? Which operating system and version? Docker or otherwise?)
>
>Any pointers highly appreciated. Google Groups is clearly on its way
>out, as it no longer allows for people to easily join groups by sending
>an email or clicking a link, so that should be a big opportunity for
>mailman3 to step up and help give those mailing list migrants a new
>home... which is what we're looking for. We're just not quite as smart
>as you guys. ;-) _______________________________________________
>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, 10 months
Re: Confirmation emails to Users has wrong domain name (example.com!)
by Odhiambo Washington
On Thu, Sep 30, 2021 at 4:09 PM Abhilash Raj <maxking(a)asynchronous.in>
wrote:
>
>
> On Thu, Sep 30, 2021, at 2:20 AM, Odhiambo Washington wrote:
> > On Thu, Sep 30, 2021 at 1:59 AM Abhilash Raj <maxking(a)asynchronous.in>
> > wrote:
> >
> >>
> >>
> >> > On Sep 29, 2021, at 2:34 PM, Odhiambo Washington <odhiambo(a)gmail.com>
> >> wrote:
> >> >
> >> > On Wed, Sep 29, 2021 at 8:31 PM Mark Sapiro <mark(a)msapiro.net> wrote:
> >> >
> >> >> On 9/29/21 9:50 AM, Odhiambo Washington wrote:
> >> >>> 1. Confirmation emails to Users has wrong domain name (example.com
> !)
> >> >>> <https://docs.mailman3.org/en/latest/faq.html#id1>
> >> >>> <
> >> >>
> >>
> https://docs.mailman3.org/en/latest/faq.html#confirmation-emails-to-users-h…
> >> >>>
> >> >>>
> >> >>> This happens when your reverse (SSL) proxy isn’t setting up the
> correct
> >> >>> headers when proxying requests. Fix this by setting the right
> >> >>> proxy_set_header directives:
> >> >> ...
> >> >>> How is this supposed to be mitigated in Apache when using WSGI?
> >> >>>
> >> >>> My config:
> >> >>>
> >> >>> WSGIDaemonProcess hyperkitty threads=25
> python-path=/usr/local/mailman
> >> >>> user=mailman group=mailman
> >> >>> WSGIPythonHome "/usr/local"
> >> >>> WSGIProcessGroup hyperkitty
> >> >>
> >> >>
> >> >> You are using mod_wsgi and not proxying at all, so this is not
> relevant
> >> >> in your case.
> >> >>
> >> >> Are you actually seeing this issue? If so, it might be related to
> >> >>
> >> >>
> >>
> https://docs.mailman3.org/en/latest/faq.html#the-domain-name-displayed-in-h…
> >> >>
> >> >
> >> > My issue is related to this, but the documentation referred to is not
> for
> >> > the faint-hearted!
> >> > I can't make head or tails of it.
> >>
> >> Click on “Domain” in Postorius from the top bar, which should take you
> to
> >> the Domains page.
> >>
> >> For your domain (in the “Mail Host” column), see the corresponding “Web
> >> Host” column, it should look something like:
> >>
> >> lists.mailman3.org (lists.mailman3.org)
> >> (Edit)
> >> SITE_ID = 1
> >>
> >
> > Mine looks different, slightly. But there is no example.com at all.
> >
> > [image: Abhilash.png]
> >
> >
> >
> >>
> >> on a new-ish version of Postorius.
> >>
> >
> > I have the newest versions of everything, having installed only
> yesterday.
> >
> >
> >>
> >> If it doesn’t show the right values and instead shows “example.com” for
> >> you, click on the “Edit” link, which will take
> >> you to a page that will allow you to edit both the values.
> >>
> >
> > It shows the right values, but with "SITE_ID = 2". In my
> settings_local.py
> > I have SITE_ID = 1.
> > I suppose the example.com is the one tied to SITE_ID = 1 and that is
> what I
> > have in my settings_local.py.
>
> That is most likely what is happening.
>
> > Should I edit my settings_local.py?
>
> Yes, please update it to have SITE_ID = 2 to correspond to the site you
> want and restart.
I did this, but there is still a problem: The hyperkitty URL still shows
example.com.
Maybe I need to re-import the database to clear this?
--
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", egrep -v '^$|^.*#' :-)
3 years, 1 month