Search results for "Postorius" - Mailman-users

Re: Emergency Moderation

by Brian Carpenter

On 5/21/20 6:30 PM, Mark Sapiro wrote: > On 5/21/20 3:23 PM, Brian Carpenter wrote: >> Is there an Emergency Moderation function (similar to the one that Mailman 2 had) with Mailman 3 core/Postorius? > > It's in core and it's just recently been exposed in REST > https://gitlab.com/mailman/mailman/-/merge_requests/643 but it's not in > Postorius yet. > Can I add this through a mailman core update via pip? Thank you for the information. It is very helpful. -- Please let me know if you need further assistance. Thank you for your business. We appreciate our clients. Brian Carpenter EMWD.com -- EMWD's Knowledgebase: https://clientarea.emwd.com/index.php/knowledgebase EMWD's Community Forums http://discourse.emwd.com/

5 years, 11 months

Re: Help with installing Postorius and Hyperkitty on Ubuntu 19

by Mark Sapiro

On 6/8/19 4:33 PM, Andrew Bernard wrote: > Hi Mark, > > Thanks for your great help. But despite decades of UNIX experience, my area > is not Django (yet). The nub of my question is that I thought you have to > have a manage.py file for Django to be able to set up the various affairs, > such as making the database migrations and so on. It is that that is > eluding me. Apologies for this hopelessly newbie question. The equivalent of manage.py in what I suggested is /opt/mailman/bin/django-admin. > I was impressed with your method of installation in the page referenced, > and I have foolwed that closely. But I am puzzled about the build script. > If I run as user mailman, not root, it wanted to install under /usr. which > of course results in permission denied. I had to modify the script to say > this: > > python setup.py install --prefix /opt/mailman/mm/venv If you want to install in the virtualenv, you should just activate the virtualenv and it should work. Perhaps the issue is that the build script at <https://wiki.list.org/DOC/Mailman%203%20installation%20experience?action=At…> assumes the virtualenv is at /opt/mailman/mm/venv. You need to insure that the '. ../mm/venv/bin/activate' line is actually pointing to your 'venv/bin/activate' -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 11 months

Question after upgrade to mm 3.2.3 and latest postorius

by David Krantz

Hi all, I have just upgraded to mailman 3.2.3. My installation is from the git sources and I use two different venv:s, one for the web part as I did not want to compile the web server plugin to a newer python version than 3.5, and one venv for the rest running python 3.7. Apart from some missing dependencies and some changes that affected the django config I just have two issues with postorius: 1. The index page with all lists is not sorted in any useful way although it is based on something as the order seems to be stable. Prior to the upgrade the lists were sorted in alphabetical order after list name which is a lot more usable for me as admin. If I click the link at the bottom with "click to view all lists" I get the old behaviour. 2. The template menu simply does not work, it seems as if some database table is missing even after running migrations. Django logs the following: ERROR 2019-08-11 20:58:55,038 exception 11837 139756347221760 Internal Server Error: /mailman3/lists/TESTLIST/templates Traceback (most recent call last): File "/...VENV3.5/lib/python3.5/site-packages/django/db/backends/utils.py", line 85, in _execute return self.cursor.execute(sql, params) psycopg2.errors.UndefinedTable: relation "postorius_emailtemplate" does not exist LINE 1: ...ext", "postorius_emailtemplate"."identifier" FROM "postorius.. The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/...VENV3.5/lib/python3.5/site-packages/django/core/handlers/exception.py", line 35, in inner response = get_response(request) File "/...VENV3.5/lib/python3.5/site-packages/django/core/handlers/base.py", line 158, in _get_response response = self.process_exception_by_middleware(e, request) File "/...VENV3.5/lib/python3.5/site-packages/django/core/handlers/base.py", line 156, in _get_response response = response.render() File "/...VENV3.5/lib/python3.5/site-packages/django/template/response.py", line 106, in render self.content = self.rendered_content File "/...VENV3.5/lib/python3.5/site-packages/django/template/response.py", line 83, in rendered_content content = template.render(context, self._request) File "/...VENV3.5/lib/python3.5/site-packages/django/template/backends/django.py", line 61, in render return self.template.render(context) File "/...VENV3.5/lib/python3.5/site-packages/django/template/base.py", line 175, in render return self._render(context) File "/...VENV3.5/lib/python3.5/site-packages/django/template/base.py", line 167, in _render return self.nodelist.render(context) File "/...VENV3.5/lib/python3.5/site-packages/django/template/base.py", line 943, in render bit = node.render_annotated(context) File "/...VENV3.5/lib/python3.5/site-packages/django/template/base.py", line 910, in render_annotated return self.render(context) File "/...VENV3.5/lib/python3.5/site-packages/django/template/loader_tags.py", line 155, in render return compiled_parent._render(context) File "/...VENV3.5/lib/python3.5/site-packages/django/template/base.py", line 167, in _render return self.nodelist.render(context) File "/...VENV3.5/lib/python3.5/site-packages/django/template/base.py", line 943, in render bit = node.render_annotated(context) File "/...VENV3.5/lib/python3.5/site-packages/django/template/base.py", line 910, in render_annotated return self.render(context) File "/...VENV3.5/lib/python3.5/site-packages/django/template/loader_tags.py", line 67, in render result = block.nodelist.render(context) File "/...VENV3.5/lib/python3.5/site-packages/django/template/base.py", line 943, in render bit = node.render_annotated(context) File "/...VENV3.5/lib/python3.5/site-packages/django/template/base.py", line 910, in render_annotated return self.render(context) File "/...VENV3.5/lib/python3.5/site-packages/django/template/defaulttags.py", line 313, in render if match: File "/...VENV3.5/lib/python3.5/site-packages/django/db/models/query.py", line 276, in __bool__ self._fetch_all() File "/...VENV3.5/lib/python3.5/site-packages/django/db/models/query.py", line 1179, in _fetch_all self._result_cache = list(self._iterable_class(self)) File "/...VENV3.5/lib/python3.5/site-packages/django/db/models/query.py", line 54, in __iter__ results = compiler.execute_sql(chunked_fetch=self.chunked_fetch, chunk_size=self.chunk_size) File "/...VENV3.5/lib/python3.5/site-packages/django/db/models/sql/compiler.py", line 1063, in execute_sql cursor.execute(sql, params) File "/...VENV3.5/lib/python3.5/site-packages/django/db/backends/utils.py", line 68, in execute return self._execute_with_wrappers(sql, params, many=False, executor=self._execute) File "/...VENV3.5/lib/python3.5/site-packages/django/db/backends/utils.py", line 77, in _execute_with_wrappers return executor(sql, params, many, context) File "/...VENV3.5/lib/python3.5/site-packages/django/db/backends/utils.py", line 85, in _execute return self.cursor.execute(sql, params) File "/...VENV3.5/lib/python3.5/site-packages/django/db/utils.py", line 89, in __exit__ raise dj_exc_value.with_traceback(traceback) from exc_value File "/...VENV3.5/lib/python3.5/site-packages/django/db/backends/utils.py", line 85, in _execute return self.cursor.execute(sql, params) django.db.utils.ProgrammingError: relation "postorius_emailtemplate" does not exist LINE 1: ...ext", "postorius_emailtemplate"."identifier" FROM "postorius... Cheers // David

6 years, 8 months

Re: error changed after restart

by Abhilash Raj

On Sat, Feb 6, 2021 at 19:44, Guillermo Hernandez (Oldno7) via Mailman-users <mailman-users(a)mailman3.org> wrote: > On 6/2/21 18:08, Abhilash Raj wrote: >> >> On Sat, Feb 6, 2021, at 3:04 AM, Guillermo Hernandez (Oldno7) via >> Mailman-users wrote: >>> I restarted de server and the error changed. Now the log shows >>> "KeyError: 'subscription_mode'": >> Did you also restart Mailman Core after the upgrade? > > Yes, indeed: > > I stopped mailman core and all the processes related. Did the > upgrades. > Started all again. Find the errors in the web user interface. Stopped > all again. Looked for errors in the log. Restarted the complete > server. > > Found the second error that this second mail is about to. It happens > when, in the main page that shows all the lists you click to see one > of > them. It seems to me that it has been database structure changes in > django that the upgrade is not aware... but it's a very long shot from > my side. `subscription_mode` was added in Mailman Core 3.3.2 and it is actually a derived atrribute and not stored in Database. Mailman's API should be returning this attribute for each Member, but for some reason it seems to me like it isn't doing that even though do have Mailman 3.3.3 running like you said. If you have Curl installed, can you send me the output of: $ curl -u <user>:<pass> http://localhost:8001/3.1/members?count=5&page=1 It should ideally return an output that looks something like shown here[1]. You can put the username/password of Core's API server in the above command. [1]: https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/… Abhilash > > I'm using sqlite as django database and mysql for mailman. > >> >>> ERROR 2021-02-06 11:47:49,015 26798 django.request Internal Server >>> Error: /mailman3/mailman3/lists/name_and_domain.of.the.list >>> Traceback (most recent call last): >>> File >>> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py", >>> line 119, in __getattr__ >>> return self._get(name) >>> File >>> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py", >>> line 86, in _get >>> raise KeyError(key) >>> KeyError: 'subscription_mode' >>> >>> During handling of the above exception, another exception occurred: >>> >>> Traceback (most recent call last): >>> File >>> "/usr/local/lib/python3.7/site-packages/django/core/handlers/exception.py", >>> line 34, in inner >>> response = get_response(request) >>> File >>> "/usr/local/lib/python3.7/site-packages/django/core/handlers/base.py", >>> line 115, in _get_response >>> response = self.process_exception_by_middleware(e, request) >>> File >>> "/usr/local/lib/python3.7/site-packages/django/core/handlers/base.py", >>> line 113, in _get_response >>> response = wrapped_callback(request, *callback_args, >>> **callback_kwargs) >>> File >>> "/usr/local/lib/python3.7/site-packages/django/views/generic/base.py", >>> line 71, in view >>> return self.dispatch(request, *args, **kwargs) >>> File >>> "/usr/local/lib/python3.7/site-packages/postorius/views/generic.py", >>> line 74, in dispatch >>> return super(MailingListView, self).dispatch(request, *args, >>> **kwargs) >>> File >>> "/usr/local/lib/python3.7/site-packages/django/views/generic/base.py", >>> line 97, in dispatch >>> return handler(request, *args, **kwargs) >>> File >>> "/usr/local/lib/python3.7/site-packages/postorius/views/list.py", >>> line >>> 295, in get >>> member.subscription_mode == >>> File >>> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py", >>> line 124, in __getattr__ >>> self.__class__.__name__, name)) >>> AttributeError: 'Member' object has no attribute 'subscription_mode' >>> *********************** >>> some info about the installed versions via pip list: >>> pip list | grep django >>> django-allauth 0.44.0 >>> django-appconf 1.0.4 >>> django-compressor 2.4 >>> django-extensions 3.1.0 >>> django-gravatar2 1.4.4 >>> django-haystack 3.0 >>> django-mailman3 1.3.5 >>> django-picklefield 3.0.1 >>> django-q 1.3.4 >>> djangorestframework 3.12.2 >>> >>> pip list | grep mailman >>> django-mailman3 1.3.5 >>> mailman 3.3.3 >>> mailman-hyperkitty 1.1.0 >>> mailmanclient 3.3.2 >>> >>> pip list | grep postorius >>> postorius 1.3.4 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On 6/2/21 11:12, Guillermo Hernandez (Oldno7) via Mailman-users >>> wrote: >>>> I've just upgrade mailman 3 installation following Mr. Sapiro >>>> advice: >>>> did a >>>> >>>> pip install --upgrade django-mailman3 hyperkitty mailman >>>> mailmanclient >>>> mailman-hyperkitty postorius >>>> >>>> I did a "python3 manage.py migrate" after, too. >>>> >>>> And all seemed to run well. >>>> >>>> All the lists showed in postorius via web, but when I try to >>>> accesss >>>> into one of them the browser shows an error. >>>> >>>> In the log you can see: >>>> >>>> *-*-*-*-*-*-* >>>> >>>> Traceback (most recent call last): >>>> File >>>> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py", >>>> line 119, in __getattr__ >>>> return self._get(name) >>>> File >>>> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py", >>>> line 86, in _get >>>> raise KeyError(key) >>>> KeyError: 'get_requests_count' >>>> >>>> ... (And after all the traceback lines) >>>> >>>> AttributeError: 'MailingList' object has no attribute >>>> 'get_requests_count' >>>> >>>> *-*-*-*-*-*-*-* >>>> >>>> The lists seem to be distributing messeages well.. but I cannot >>>> acces >>>> via web administration (django/postorius) >>>> >>>> Can anyone point me in the right direction to solve this, please? >>>> >>>> _______________________________________________ >>>> Mailman-users mailing list -- mailman-users(a)mailman3.org >>>> <mailto:mailman-users@mailman3.org> >>>> To unsubscribe send an email to mailman-users-leave(a)mailman3.org >>>> <mailto:mailman-users-leave@mailman3.org> >>>> <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/> >>>> >>> _______________________________________________ >>> Mailman-users mailing list -- mailman-users(a)mailman3.org >>> <mailto:mailman-users@mailman3.org> >>> To unsubscribe send an email to mailman-users-leave(a)mailman3.org >>> <mailto:mailman-users-leave@mailman3.org> >>> <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/> >>> > _______________________________________________ > Mailman-users mailing list -- mailman-users(a)mailman3.org > <mailto:mailman-users@mailman3.org> > To unsubscribe send an email to mailman-users-leave(a)mailman3.org > <mailto:mailman-users-leave@mailman3.org> > <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/>

5 years, 3 months

Re: django fake users

by Stephen J. Turnbull

Andrew Hodgson writes: > >Require moderator approval for subscribing. > > I don't think this would help the issue. What I am seeing here is > users signing up through Postorius using the sign up option which > then creates an account in Django (but not Mailman). Ah, so "fake" == "account in Django but no user in Mailman"? I don't have time to look at it, so take this with a grain of salt, but I don't think they are passing the email confirmation. If they were, they would show up in Mailman. > I don't know whether they pass email confirmation or not (I don't > see this in Django admin), however they don't get added as users in > Mailman and they don't attempt to subscribe to any list. I think this would be simple enough to deal with (not trivial, so I'm not making any promises except to try adding it to the GSoC ideas page -- that should be enough to clarify whether there are any "annoyance to 'real' users" issues, and we move forward from there if there aren't). Basically, Postorius should notify Mailman that there is a *pending* user in Django, and if there's no confirmation by a deadline, remove that user. This requires a bunch of infrastructure like a table of "pending" users, callbacks for the deletion, etc, but I don't see why it would be conceptually difficult. (This combination is why I think it would be a good GSoC task) Steve

5 years, 3 months

Re: Disabling the version disclosure.

by ninad＠iitb.ac.in

Steve from another mailman list suggested the below solutions. 1st method suggested worked. This is just for this group's information. Thank Steve for the solution. --------------------------------------- Suggested solution ------------------------------------------------------- It helps to explain why you don't want to change the HTML code, because there are several ways to do this, with different implications both for the page's appearance and for future maintenance. The visually cleanest way to do this is to copy the files site-packages/postorius/templates/postorius/base.html site-packages/hyperkitty/templates/hyperkitty/base.html to /etc/mailman3/templates/postorius/base.html /etc/mailman3/templates/hyperkitty/base.html search for '_VERSION' and delete or edit the version stanzas near the end of those files, add TEMPLATES[0]['DIRS'].append('/etc/mailman3/templates') somewhere in /etc/mailman3/settings.py, and restart mailman-web (typically as root, using 'systemctl restart mailmanweb'). Alternatively and less visually appealing you can clear the version variable itself with a file 'site-packages/version_hack.py' containing the lines def suppress_version(request): return {"HYPERKITTY_VERSION": "Wouldn't you like to know?", "POSTORIUS_VERSION": "Wouldn't you like to know?"} ... you probably want to change the strings to empty strings ... and add the lines TEMPLATES[0]['OPTIONS']['context_processors'].append( 'version_hack.suppress_version' ) somewhere in /etc/mailman3/settings.py, and restart mailman-web. The former method of overriding the templates is a supported API, and very unlikely to be obsoleted any time soon. The latter method of patching the variables is something of a hack, and also leaves the tags like "Postorius version" visible in the page. Steve ----------------------------------------------------------------------------------------

1 year, 1 month

Re: Postorius no connection to REST API

by Mark Sapiro

On 8/9/21 8:56 AM, Richard Rosner wrote: > Mark Sapiro wrote: > >>> The REST API is apparently not listening on the host/port this is trying >> to connest to. > > Apparently. The question is why. You are in a better position to answer that than am I. What does `sudo netstat -lntp` show? What does `ps -fwwa|grep rest` show? >>> What is executing the manage.py command to start Django. Is it user list? > > Probably. It depends on who is calling it. I understand too little of the new architecture. But mailman3.service is run as list, mailman3-web.service as root. mailman3-web.service must also run as list. >>> I don't use uwsgi and know little about it so I don't know what the Unix >> domain socket /run/mailman3-web/uwsgi.sock connection is for, but this >> appears to be some miscunfiguration between apache and uwsgi. >> Normally, in an apache/uwsgi configuration, apache proxies to uwsgi via >> tcp port 8000 and uwsgi is configured with >> [uwsgi] >> uwsgi-socket = 0.0.0.0:8000 > > I too have no experience in the combination ow apache and uwsgi. The only other uwsgi app I'm running is on another server and running under nginx. So, what do you have in your apache config for proxying to uwsgi and what's your uwsgi configuration. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 8 months

Re: Core, Hyperkitty and Postorius releases

by Odhiambo Washington

On Sat, May 15, 2021 at 1:08 AM Mark Sapiro <mark(a)msapiro.net> wrote: > On 5/14/21 3:00 PM, Odhiambo Washington wrote: > > On Sat, May 15, 2021 at 12:47 AM Mark Sapiro <mark(a)msapiro.net> wrote: > > > >> Those are headers for compiling some sass. Possibly you actually have a > >> `sassc` installed in which case you may need > >> > >> COMPRESS_PRECOMPILERS = ( > >> ('text/x-scss', 'sassc -t compressed {infile} {outfile}'), > >> ('text/x-sass', 'sassc -t compressed {infile} {outfile}'), > >> ) > >> > >> > > This change makes the error I was getting to go away. However, I cannot > > login to manage lists, even after restarting mailman. > > > > The error details are here: https://pastebin.ubuntu.com/p/vM2c5WYyJ4/ > > > The relevant part of which is > > OfflineGenerationError at /accounts/login/ > You have offline compression enabled but key > "fa788b08b65fd318d68cfc5afebc18acd3e93cebffadb54d863572ad1754f368" is > missing from offline manifest. You may need to run "python manage.py > compress". Here is the original content: > > I.e., something went wrong with your compress command. Try it again. > I have successfully run the following commands: /opt/mailman/mm/bin/django-admin collectstatic --clear --noinput --verbosity 0 /opt/mailman/mm/bin/django-admin compress /opt/mailman/mm/bin/django-admin compilemessages /opt/mailman/mm/bin/django-admin migrate But the error at https://pastebin.ubuntu.com/p/vM2c5WYyJ4/ persists. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v "^$|^.*#" :-)

4 years, 11 months

Re: Can login at /admin, but cannot login at the account/login page.

by Stephen J. Turnbull

Gonzalo Cardenas writes: > Actually it doesn't let me in to the login page / sign up page (the > HTTP requests hangs until it times out). The URL I'm trying to > access is http://localhost/accounts/login/?next=/mailman3/lists/ or > http://localhost:8002/accounts/signup/?next=/mailman3/lists/ > eventually Nginx returns a "502 Gateway timeout error" The second URL appears to presume Postorius is actually running on port 8002, but this > location / { > proxy_pass http://127.0.0.1:8000; > proxy_set_header Host $host; > proxy_set_header X-Forwarded-For $remote_addr; tells nginx to proxy to port 8000. I don't use nginx or uwsgi myself (I use Apache and mod_wsgi) so I am not very confident. But you need to make sure that all of the configuration files use the same port. I don't remember if any of the webservers suffered from this, but some programs don't map 127.0.0.1 to localhost. If any of the configs specify localhost for the Postorius URI, you could try using 127.0.0.1 instead. If making all these port configurations consistent doesn't do the trick, please post your mailman-web settings.py, uswgi config, and nginx config. You can substitute fake domain names and IP addresses if you're worried about privacy of your configs, but make sure that (1) if the configs specify several IPs or several domain names, you distinguish them in your fake versions, and (2) always substitute the same fake IP/name for a given real IP/name. Steve

3 years, 11 months

Re: Changing subscription address

by Stephen J. Turnbull

Andreas Barth writes: > To make it more complex (perhaps?), I'd like to switch django to use > the single sign on-system, which means: mail adresses and user > accounts are managed elsewhere, and djano / mailman / whatever > component consumes accounts (and verified mail adresse) from the > central account store. Django *is* our single-sign-on system, and Mailman core *is* our central account store. That's why it's possible to mix and match Mailman core with other UI applications. This has been proved in practice by at least one commercial service. That is, we don't do *any* authentication in Mailman core. And because authenticating general Internet connections is *hard*, we want to keep it that way![1] ;-) The single exception is the mail address verification dance, which is an extremely simple protocol with a well-known threat model that nobody can do anything about (somebody who can read your mail).[2] So we delegate authentication and credentials management to Django, which already knows how to do passwords, OAuth and friends, and probably multifactor, too. That's *all* that the Django account functionality does for Postorius.[3] All the other user and admin information that Postorius exposes are ultimately backed by queries to Mailman core's REST API, not by Django's internal database. This subthread is 100% about how to initialize the Mailman core user record in a way more consistent with user expectations. The other, closely related subthread is about presenting tables of subscriber data for multiple subscriptions, instead of requiring people to visit per-subscription pages. There's no need to change the division of labor between core and Postorius to implement either. Steve Footnotes: [1] We probably can't, in the long run. People definitely want Mailman systems distributed across multiple hosts, and there are limits to how well that can work with all the hosts behind a firewall. That implies authenticating connections to the REST API endpoints. [2] Technically, in theory we could encrypt the verification email in case there's a miscreant-in-the-middle who can read plain text, but then we've got a key distribution problem and a user education problem. Encryption is like regexps but worse: whenever you have a problem and you adopt encryption as the answer, now you have *three* problems! :-P [3] I'm not sure about HyperKitty. Mailman core doesn't know or care about web preferences, so I suppose HyperKitty has to store them somewhere.

5 years, 1 month

Mailman-users search results for query "Postorius"