Search results for "Postorius" - Mailman-users

Re: Mailman web interface / uwsgi

by Stephen J. Turnbull

Mark Sapiro writes: > On 11/27/22 00:19, Jan Eden via Mailman-users wrote: > > > > I see. But the mailman.cfg is placed in /etc/mailman3, and this file > > also belongs to the core, doesn't it? In any case, I changed the > > configuration parameter for [archiver.hyperkitty] as you suggested and > > all settings are in one place now. > > In that case, it's probably just an oversight. Yes, I think that's what's going on. There's been quite a bit of simplification and unification of the Django configuration over time, which is ongoing and not 100% reflected in all documentation. Because of the way most Linux distros work (and I think it's probably true for *BSD and other POSIX systems), it makes sense to put users' site configurations in /etc. I don't see a particular reason why with the current relatively small set of config files we'd want to put HyperKitty or Postorius files elsewhere than /etc/mailman3 (although it might make sense to have more separation given the existence of EMWD's Affinity etc). Steve

3 years, 9 months

Re: proper update procedure for MM3 docker containers

by Fabian A. Santiago

On 2018-08-06 12:24 PM, Abhilash Raj wrote: > On Mon, Aug 6, 2018, at 6:28 AM, Fabian A. Santiago wrote: >> Hello, >> >> Can someone remind me of the proper / best way to update my docker >> containers for MM3 / postorius based on maxking's images? Thanks. >> >> and this for both the stable and rolling releases. > > Well, the process is fairly straightforward, when moving form an older > to a newer release, > > Stop and remove the container ($docker-compose stop, $docker-compose > rm) and then start the new ones ($ docker compose up -d). > > That should be all! > >> >> -- >> Fabian S. >> >> OpenPGP: >> >> 0x643082042DC83E6D94B86C405E3DAA18A1C22D8F (new key) >> >> *** >> >> 0x3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC (to be retired, still >> valid) >> _______________________________________________ >> 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/ thank you. -- Fabian S. OpenPGP: 0x643082042DC83E6D94B86C405E3DAA18A1C22D8F (new key) *** 0x3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC (to be retired, still valid)

8 years, 1 month

Re: General question mailman3: message sender acceptance "always"

by Mark Sapiro

On 10/23/23 09:08, Wikinaut wrote: >>> In the Postorius held messages view, click on the message's subject to >> open a dialog showing the messages content > > Dear Mark, sorry: > How should I know this? Well, the subject of the message in the held messages view looks like a link. Maybe click it once to see what it does. > I'd rather prefer to have these both changes: > > i) relabel the existing one od three buttons from "accept" to "accept once" ; and > ii) add a fourth button "accept all messages from this sender (i.e. add to white list)" That wouldn't include options like "discard further posts from this user", "reject further posts from this user" and perhaps other possibilities. If I were going to do anything, it would probably be adding a line above the list of held messages saying something like "Click the message's subject for more options." -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 10 months

Re: How to store additional information about lists?

by Stephen J. Turnbull

Andreas Barth writes: > public: anyone can subscribe and read the archive. This is already possible, more or less the default list configuration. "Subscribe and read archive" involves multiple separate list attributes, enforced by three separate applications. Subscription policy is controlled by whether you need approval of an admin or not, and whether you need to verify your email or not, plus the ban lists. Archive access (assuming you have one at all) is contrlled by a different list attribute, archive_policy. Core has final say on subscriptions, but Postorius could do it if email subscriptions are disabled. HyperKitty handles the archive permissions. These various aspects are currently quite loosely coupled. > restricted: for employees (or members - or whatever) only. So they > could subscribe themself. The archive and posting may be restricted > to subscribers or to anyone in that group - both would be working > for me. I think this can be implemented with the controls we already have. The basic idea is to handle the "anyone in that group" case by mass subscribing and setting the subscription to no-mail. Obviously, this is most practical with a fairly static membership (eg, students at a school). A fluid membership (for example, a volunteer organization) would be made easier to manage with a "member adapter" to an external database to handle the "do I know this person" questions. ("Member adapter" is Mailman 2 terminology, I don't know if it's exactly the same in Mailman 3; it does or *should* exist in Mailman 3, though.) It's possible that we could make this easier to configure with some changes to core. However, if this is as close to what you need as I think it is, I would advise against vendoring Mailman, and instead writing some scripts to help manage mass subscription, or create the member adapter. > (How to know who is allowed to subscribe is another question - having > an internal mailing list which contains all the members just for this > purpose would be ok for me.) That's helpful to know. This sounds very similar to the Systers approach, where the Mailman core User database is the authoritative membership database for the organization. > private: hand-selected people, think about e.g. board or steering > committees internal discussions. Of course, the archive (if there is > any) should be restricted to the actual members. Posting to these > lists is currently not restricted, so no derivation needed from the > current set in postorius. This is already possible by requiring admin approval, or by setting the ban list to something that matches everything like "^.".

5 years, 3 months

Re: New Mailman Releases

by Abhilash Raj

On 10/26/22 12:32, Odhiambo Washington wrote: > > > On Wed, Oct 26, 2022 at 8:44 AM Abhilash Raj <maxking(a)asynchronous.in > <mailto:maxking@asynchronous.in>> wrote: > > Hi, > > I am pleased to announce several new releases for GNU Mailman project. > > 1. Mailman Core 3.3.6 [1] > 2. Postorius 1.3.7 [2] > 3. Hyperkitty 1.3.6 [3] > 4. Mailmanclient 3.3.4 [4] > 5. Django-mailman3 1.3.8 [5] > > All the releases are published to PyPI and you can find links to all > the > PyPI projects: > > https://docs.mailman3.org/en/latest/ > <https://docs.mailman3.org/en/latest/> > > A full list of changelogs are available below: > > [1]: > https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/NEWS.… <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/NEWS.…> > [2]: > https://docs.mailman3.org/projects/postorius/en/latest/news.html#section-2 <https://docs.mailman3.org/projects/postorius/en/latest/news.html#section-2> > -- Something weird is going on with the page missing the bullets. > [3]: > https://docs.mailman3.org/projects/hyperkitty/en/latest/news.html#news-1-3-6 <https://docs.mailman3.org/projects/hyperkitty/en/latest/news.html#news-1-3-6> > [4]: > https://docs.mailman3.org/projects/mailmanclient/en/latest/src/mailmanclien… <https://docs.mailman3.org/projects/mailmanclient/en/latest/src/mailmanclien…> > [5]: > https://gitlab.com/mailman/django-mailman3/-/blob/master/README.rst > <https://gitlab.com/mailman/django-mailman3/-/blob/master/README.rst> > > > Finally, the minimum Python version required is 3.7 although, 3.9 is > recommended if you are doing a new install for longest support. 3.10 is > supported for Django apps, but Mailman Core is missing that due to one > of the core dependencies not support 3.10 yet (aiosmtpd). > > > > Hello @Abhilash Raj <mailto:maxking@asynchronous.in> > > Thank you and the whole MM3 team for all the free work you do to make us > have mailing lists :) > > I have a question regarding the Python version. > I have a very recent installation of MM3, via the Virtual Environment > method, running smoothly - so far. > The Python version that got installed is 3.10.6 > > wash@lists:~$ sudo su - mailman > (venv) mailman@lists:~$ which python > /opt/mailman/mm/venv/bin/python > (venv) mailman@lists:~$ /opt/mailman/mm/venv/bin/python -V > Python 3.10.6 > (venv) mailman@lists:~$ mailma > mailmail3 mailman > (venv) mailman@lists:~$ mailman --version > GNU Mailman 3.3.5 (Tom Sawyer) > (venv) mailman@lists:~$ > > 1. What does the incompatibility with Python-3.10 portend for my setup > and anyone else with Python-3.10? The bug in aiosmtpd is a bit weird and has to do with how the test cases in aiosmtpd and Python 3.10 changes interact with SSL. For the intents and purposes of Mailman, we don't use SSL for the communication between MTA and aiosmtpd, so there _shouldn't_ be any issuer with your setup. Ideally, `pip` shouldn't have allowed you to install aiosmtpd in a Python venv with 3.10, but that depends on which version of pip you are using since the newer versions have better support for such management. > 2. Is it possible to downgrade the Python in a Venv down to 3.9 without > breaking the installation? You can keep the current installation running and create a 2nd installation by simply creating a 2nd venv with 3.9. Something like, `/opt/mailman/mm/venv-3.9/`. You can install things into that venv and when you are done and ready to switch, you can update all the paths in various places to use update 'venv-3.9' instead of 'venv'. In case you encounter any issues, you can always revert back to older 'venv' in the paths wherever the are needed and bring back the old install. Venvs are good for multiple installs so you can switch back and forth pretty easily. > > And finally, is there documentation/procedure to upgrade a VENV install > in this case? You don't want to upgrade venv is what i've heard, you should always create a new one if you are bumping python versions. If you are just upgrading packages in the existing venv, then you can follow: https://docs.mailman3.org/en/latest/upgrade-3.2.html -- thanks, Abhilash Raj (maxking)

3 years, 10 months

Re: lists.mailman3.org web site.

by Barry Warsaw

On Aug 30, 2016, at 12:01 AM, Mark Sapiro wrote: >Django Allauth is now properly configured and working on >lists.mailman3.org. You can log in by email/password as noted above or via >OAuth2 with a GitHub, GitLab, Google or Facebook identity. > >If you are an existing user, in order to use one of the OAuth2 providers, you >must first log in with email and password and go to the Account Connections >tab in your account settings and add the 3rd party account(s) you wish. This works pretty great. I tried it with my GitHub and GitLab accounts and was easily able to associate those with my Postorius and HK accounts. I didn't try FB or Google, but I guess those would work the same way. I'll miss Persona but I think this is an entirely acceptable alternative, with plenty of choice for folks wanting to control which authority they delegate to. I'd mildly like to see Launchpad support, but I understand 1) it's a minority platform; 2) it only supports OAuth 1. Thanks to the developers for adding this support and to Mark for enabling it. Cheers, -Barry

10 years

Re: mailman-suite: Error 500 on Lists /setting/ pages

by Mark Sapiro

On 11/18/20 8:43 AM, ljsbw-it(a)riseup.net wrote: > I just installed Mailman3 (mailman-suite) on my Server following these instructions: https://lab.uberspace.de/guide_mailman-3.html Please see <https://wiki.list.org/x/12812344> > and everything works fine so far. I can create lists, subscribe people and send mails through lists but when I click the settings button and get redirected to /postorius/lists/listname/settings/ i get an Error 500 message. I couldn't find anything in the logs except the uwsgi log: > [pid: 20568|app: 0|req: 62/62] 100.64.115.1 () {48 vars in 1052 bytes} [Wed Nov 18 16:27:59 2020] GET /postorius/lists/listname/settings/ => generated 1102 bytes in 1438 msecs (HTTP/1.1 500) 6 headers in 209 bytes (1 switches on core 0) I think that uwsgi log message just refers to the delivery of the error page to your browser. What other logs are you looking at? There should be something in Mailman core's mailman.log or the Django log whose location is defined in settings(-local).py, probably mailman-suite/logs/mailmansuite.log. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 10 months

Re: Module Not Found Error after update

by Abhilash Raj

On Thu, Feb 4, 2021, at 8:52 AM, Brian Carpenter wrote: > > On 2/4/21 11:46 AM, Mark Sapiro wrote: > > You need django-mailman3 1.3.5 > > > > > > While all are not required in this case, when you upgrade like this with > > pip, you should upgrade all of django-mailman3, hyperkitty, mailman, > > mailmanclient, mailman-hyperkitty and postorius. > > Thanks Mark. Perhaps Abhilash can include that in the instructions on > the following page for future releases: > > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/… I was hoping pip would actually upgrade django-mailman3 given that P requires ‘django-mailman3>=1.3.5’ [1] but looks like it didn’t :( [1]: https://gitlab.com/mailman/postorius/-/blob/master/setup.py#L56 > I will make a note of this in my own personal documentation and the > Debian 10 How-to guide that I am currently working on. > > -- > Brian Carpenter > Harmonylists.com > Emwd.com > _______________________________________________ > 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)

5 years, 7 months

Could not locate column in row for column 'user.id'

by Shashikanth Komandoor

Hi Team, I am currently running Mailman 3 with version 3.3.1 and in built postfix version 2.10.1-6 on RHEL 7.5 in production environment from the past 2 months almost. From the past few days, I found my server is responding to the users very slowly and throwing the Server Error page (of course getting the required page after multiple refreshes) for almost every click on the postorius pages (not yet observed on hyperkitty front end which in fact is not so important for me as of now). During that time, I observed in the mailman.log an error message saying "Could not locate column in row for column 'user.id'". The complete traceback log is attached with the mail. The error message is generated for almost all the lists and all the clicks. And despite this error message, I don't know how the required page is loaded after a few refreshes of the webpage. I don't know how to resolve this issue. Please advise. Also, please let me know if anything I need to share with you. -- Thanks & Regards, Shashi Kanth.K 9052671936

6 years, 1 month

Re: Postorius claims 2 messages held when there are none - out of sync

by Ken Alker

--On Monday, June 26, 2023 2:32 PM -0700 Mark Sapiro <mark(a)msapiro.net> wrote: > On 6/26/23 11:53 AM, Ken Alker wrote: >> >> Is the var/messages hierarchy also where all the archived emails are >> stored for future viewing via the web interface? > > > No. They are stored in the hyperkitty_email and hyperkitty_attachment > tables in the database. What else is stored in /var/messages, if not archives? I see 4711 messages in that directory (which I presume would be as many messages are in the archive database). If there is a write-up on this, feel free to point me to it. I found <https://docs.mailman3.org/projects/mailman/en/latest/build/lib/mailman/mode…> but this isn't really answering my question. >>> Also, there is a long thread at >>> https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thr >>> ea d/UWCUQYU7Q5X5LWNII57ZZ4DDXE4DEFX7/ and maybe others that might be >>> relevant. >> >> I have never used the mailman shell before, but based on the referenced >> thread I learned to do this (note that the thread also taught me how to >> rewrite it to narrow down to just the list with issues so I didn't >> delete held messages in other lists, if my case): >> >> for verification: >> >> venv) mailman@speedy:~/web/logs$ mailman shell -l >> sbarc-list(a)lists.netlojix.com >> Welcome to the GNU Mailman shell >> Use commit() to commit changes. >> Use abort() to discard changes since the last commit. >> Exit with ctrl+D does an implicit commit() but exit() does not. >> The variable 'm' is the sbarc-list(a)lists.netlojix.com mailing list >> >>> requests = IListRequests(m) >> >>> first = True >> >>> for request in requests.held_requests: >> ... key, data = requests.get_request(request.id) >> ... if first: >> ... first = False >> ... print(m.list_id) >> ... print (f"""\ >> ... Sender: {data['_mod_sender']} >> ... Subject: {data['_mod_subject']} >> ... Date: {data['_mod_hold_date']} >> ... Reason: {data['_mod_reason']} >> ... """) >> ... > >> and then to delete the two messages: >> >> (venv) mailman@speedy:~/web/logs$ mailman shell -l >> sbarc-list(a)lists.netlojix.com >> Welcome to the GNU Mailman shell >> Use commit() to commit changes. >> Use abort() to discard changes since the last commit. >> Exit with ctrl+D does an implicit commit() but exit() does not. >> The variable 'm' is the sbarc-list(a)lists.netlojix.com mailing list >> >>> requests = IListRequests(m) >> >>> first = True >> >>> for request in requests.held_requests: >> ... key, data = requests.get_request(request.id) >> ... if first: >> ... first = False >> ... print(m.list_id) >> ... print(f'request id: {request.id}, deleting') >> ... requests.delete_request(request.id) >> ... >> sbarc-list.lists.netlojix.com >> request id: 27, deleting >> request id: 28, deleting >> >>> >> >> The result of this, however, was that the web interface still claimed I >> had two held messages. I wasn't sure if there was some cron-type >> "sweeper" process I had to wait to auto-run or if I had to manually do >> something to create an update. I then realized that the sample script >> had a ' >>> commit ()" ' at the end, which I'd missed. So, I >> re-entered the script (but it didn't spit out that it deleted anything >> this time) and got an error when I did the commit. > > Was this in the same `mailman shell` interaction or a new one? What was > the error? I am pretty sure I started over entirely (ie. exited via ctrl-D and restarted). It was a syntax error, but in reviewing, I see now that I'd copied the example exactly, and I included the trailing quote mark. After some experimentation and reading, I see now that that should not have been there. >> So, I figured the messages HAD >> been delete and the commit wasn't really necessary. When I went back >> to the web interface, the number of held messages was at 0 and I no >> longer get the original error when clicking on "Held messages", so my >> issue is solved. But this does leave me with some educational questions: >> >> 1) Did I affect something somehow with my "commit", or was there a job >> that cleaned things up (if so, what job)? > > > I'm not sure of the sequence of events, but I think you probably looked > in Postorius before you quit `mailman shell` and then you quit `mailman > shell` with ctrl-D which did an implicit commit. I didn't think so, but I'll certainly buy that. So, I'm assuming by this you are implying that there is no helper function that needed to run and the number of held messages should have dropped to zero immediately upon a refresh of the web page? >> 2) Is the "commit" even necessary (I saw it in someone else's script in >> the thread)? > > It is necessary to explicitly commit() or quit with ctrl-D to actually > update the database. Got it. Thanks. That explains why I didn't see any deletions when I re-ran the script the second time (after likely exiting with ctrl-D first). >> 3) Is there a way to save a script and then execute it via shell rather >> than typing it in every time (it appears from the examples that people >> are typing them in every time, which is super tedious; I didn't paste >> for fear of doing something damaging, but maybe that would work)? > > > Yes, you can save a script in the bin/ directory in your venv and run it > with `mailman shell -r`. See `mailman shell --details`. > > >> 4) Are the request.id's of the messages dynamic/changing, or are they >> fixed for life? I thought I'd delete based on exact request.id without >> looping but I was afraid maybe they were changing over time and that >> this wouldn't be a good idea. Might be nice to know for the future. > > The request.id is constant for that request object. The request object is > fixed for a specific held message request. I.e., a specific held > message's request object and its request.id and other attributes are > fixed until that request is handled. So if I run the script, exist the shell, then come back in again, I can't rely on the request.id being the same? I'd need to re-run the script and get a new request.id?

3 years, 2 months

Mailman-users search results for query "Postorius"