Search results for "Postorius" - Mailman-users

Re: Accept these non-members

by Stephen J. Turnbull

Lars Bjørndal writes: > All addresses, both addresses that I know has sent messages to the > list and others, are marked as MemberRole.nonmember> Action.defer Post from these nonmembers go through normal checks (spam, for example) before being distributed. > When I view non-members in postorius, I get some differences: > > Some ar marked: Regular List default, and others Regular Default > processing. "List default" means "this user has not made a choice, so Mailman will check what is 'normal' for the list in the list's configuration". In detail, Postorius is intended to allow users and list administrators to *modify* configurations. At delivery time, these configurations "cascade", typically in this way: - if this subscription has a setting, apply it, and return; if not - if the address this subscription delivers to has a setting, apply it, and return; if not - if the user who owns that address has a setting, apply it, and return; if not - if the list that is subscribed to has a setting, apply it, and return; - otherwise, use the fallback setting from the source code. In Postorius, the "no setting" option is displayed in such a way that the person considering changing the setting knows what the next level of the cascade is. "List default" means "this user has not made a choice, so Mailman will check what is 'normal' for the list in the list's configuration". "Default processing" is a regular option, that can be applied to this post. It means "check if the user is allowed to post at all, then check for reasons (eg, spam) why this post might not be OK". Usually "list normal" is also "Default processing", but it might be "Hold for moderator", for example. On the other hand, Mark's script will return the option that will be applied using the logic of the cascade. > The list is imported from Mm 2.1 a long time ago. I don't know if > that matters. I don't think it does. > Hm, this is a mystery to me. Is there othere places I can search > for addresses that are aloud to send to the list? I don't understand what you want. The "mailman shell interaction" that Mark posted earlier gives you exactly the list of members who can post to the specified list. If some are "trusted users" who don't go through the spam checker, etc, they are displayed with Action.accept. Other posters are displayed with Action.defer. But both will automatically be distributed as long as they appear to be legit posts (not spam, etc). Steve -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

3 months, 2 weeks

Re: Change the default value for the General Archive Policy

by Stephen J. Turnbull

Markus Grandpré writes: > many thanks for your reply. When I create a mailing list without an > archive, You cannot do that in Postorius. All of the "style" options provide for an archive. "Ordinary discussion" and "announce" have public archives, and the last option is "discussion with private archives". How are you doing this? > "Settings > Archiving > Archive policy" is always set to "Public > archives". I was wondering if it's possible to change the default > to "Do not archive this list" instead. The choices for setting are defined at line 386 (or so) of postorius/forms/list_forms.py: archive_policy_choices = ( ('public', _('Public archives')), ('private', _('Private archives')), ('never', _('Do not archive this list')), ) This is implemented as a line of radio buttons. There is no default for a *new* list, it's implied by the style choice. For an existing list you are shown the current setting -- there's no default to change to, you have to click on a button. If by "default" you mean "first in the list", you can patch the form in Postorius, but we're not going to change the order, since our primary audience is public discussion lists. In theory we could provide a mechanism to configure the order, but I think that's very unlikely to happen -- Mailman isn't and doesn't want to be Emacs. -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

11 months, 4 weeks

Re: moving list from mm3 -> mm3

by Mark Sapiro

On 12/8/23 08:01, Jens Günther wrote: > > This is a nice collection of the configuration of a certain list. Does > anybody know how I would get this data back to the newly created list in > the second working mm3-instance? Shouldn't it be possible via POST > command? I thought of something like: > > curl -u restadmin:restpass -d @short.domain -H "Content-Type: > application/json" localhost:8001/3.1/lists/&short.&domain/config > > But it returns {"title": "405 Method Not Allowed"} and I don't know > where to look in the docs, since it shows almost always a way through > mailman shell. You need a PUT command, not POST. Try the above with `-X PUT`. > ## Members, moderators, owners > > To export all members I normally run within mm-core-container as user > mailman the following command: > > mailman members &short.&domain > &short.txt > > To fill them back in, it can be done in Postorius (or is there a way > through API?). You can use Postorius -> Mass operations -> Mass subscribe to add the members, but you can't do that for owners and moderators. Also you lose information about the members such as Delivery status, Delivery mode and other user settings. > What I would love to know is how to get out Owners of the corresponding > lists and reimport them in the new one (which will be the same at the > end :-D but different instance). You can use the --role option with `mailman members` to get owners and moderators, but short of a custom script, you have to add them manually. > ## registered users > > This part is somehow tricky, since I have no clue how to do it. Some of > the mailinglist-admins don't want to bother their list-owners again with > registering newly on the other system. Is there a way to export all > users (I think I found them in the DB in the table auth_users, somehow > in combination with account_emailaddress) and get them over to the new > instance (actually I just need part of them, but that's another question > that I might solve lateron on my own). > > Maybe the answer is already here: > https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/… > -> but can somebody help to get this working (import/export)? That is not the answer. Those are Mailman core users, not Django (web login) users. You need to get the relevant entries from the auth_users and account_emailaddress tables and add them to the new DB. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 6 months

Re: mailing list aliases

by Abhilash Raj

On Fri, 2018-01-19 at 16:30 -0800, Mark Sapiro wrote: > On 01/19/2018 03:09 PM, Dmitry Makovey wrote: > > Not sure whether to mark this "SOLVED" yet - but when I manually updated > > postgres DB with the aliases I wanted - everything started to work as > > expected. > > > > so it does sound like a bug in mailman-core 3.3.0 . Shall I file it or > > was it already fixed in 3.3.1 (anouncement page didn't list that fix) > > > As far as I know, this is not a bug in core. It is > <https://gitlab.com/mailman/postorius/issues/58> however, this may in > fact be a bug in the REST API in which case I don't think it's fixed in > API 3.3.1 I guess we are all talking about the same thing, but just to mention, 3.1.1 is the latest release (instead of 3.3.1). > > > > 2. Related to #1 - we've migrated our mailing lists from foo(a)my.com to > > > foo(a)lists.my.com however we've preserved old addresses. But in new setup > > > mail sent in gets stopped for moderation with: "X-Mailman-Rule-Hits: > > > implicit-dest" . What's the best course of action here to get mailing > > > list respond to multiple email addresses? > > > acceptable_aliases is the way to address this, but as you note, it can't > be properly set via Postorius and possibly via REST. > > _______________________________________________ > Mailman-users mailing list > mailman-users(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ -- thanks, Abhilash Raj

8 years, 5 months

Re: Deactivate list without deleting it?

by Colin Watson

On Tue, Jan 16, 2018 at 10:59:28AM +0900, Stephen J. Turnbull wrote: > Colin Watson writes: > > > Ideally, I'd like mailing lists to have a "deactivated" state in > > addition to full deletion. In this state, the list would appear > > nonexistent for most purposes: incoming email would be rejected, > > Postorius would deny its existence, etc. > > [...] > > > Has there been any discussion of this in the past, or any advice as to > > implementation strategy? > > I don't recall anybody discussing this. Your use case is your use > case, but I think if we were going to implement this I'd probably want > "partial" deactivation where the archives remain available but no mail > is delivered, can't subscribe, etc. I'm also not sure I'd want > Postorius to deny it ever existed. That seems rather unfriendly > (again, I don't understand your use case, so that is not a comment on > your requirements). I possibly should have explained our situation in a little more detail. The way we have things set up with Mailman 2.1 is that any team in Launchpad (teams are basically just a collection of people, with varying policies on who can join them etc.) can have a mailing list if its administrators want one, and they enable it in the Launchpad web UI. If you want to subscribe to one of these lists, you join the team in question and you press the "Subscribe to mailing list" button. Launchpad runs the show and tells Mailman exactly what to do. So in fact we have all of Mailman's user interface disabled except for the list archives, and Postorius wouldn't come into it in our case - I probably shouldn't have confused things by bringing it up hypothetically. We'd probably want to do roughly the same kind of thing with Mailman 3, at least to start with, though we may well want to make some of HyperKitty's advanced features work with single-sign-on integration. I haven't looked into that in any detail yet. I can definitely see that both "preserve archives" vs. "hide archives" are potentially useful things to do. > It seems to me that dump, delete, and restore may be the best approach > for the HyperKitty side because HyperKitty maintains all that state. > Of course this could be done inside the database. Also, perhaps you > can (ab)use the ArchivePolicy enum by adding an "inactive" element, > but core has no way to enforce those on the archiver (which can be a > third party host like mail-archive.com) and I'm not sure HyperKitty > ever consults core about that once the archive is created. I'd been thinking more of a new enum in HyperKitty for the visibility state, since it does seem like quite an archiver-specific thing. (Dump/delete/restore would of course be possible, but it's somewhat cumbersome to do externally and it seems like an odd way to go about things internally given the ability to change the DB schema.) I agree that not all archiver implementations can support this. > I'm not sure what you mean about IArchiver; as far as I can see that > interface is sort of half-duplex: it provides the information core > needs *about* the archiver to do core's side of archiving, not for > core to communicate *with* the archiver. In fact all of the concrete > code is callbacks provided by the archiver, and once a message is > archived the core forgets about it. So this isn't "just" an > extension; it's a fundamental redesign of IArchiver. Well, IArchiver.archive_message sends a message from core to the archiver. I'd been thinking of something like IArchiver.set_list_visibility(mlist, visibility) which would send a message from core to the archiver to instruct it to show/hide the archives. It doesn't seem too out of line, though I'm not wedded to it either. I suppose that one alternative could be that we handle this in a Launchpad-specific add-on to HyperKitty, since at a minimum we'll need some of our own code there to deal with sign-in for private lists. So the same bit of custom code that determines whether a list's archives are private could hide them from everyone except their owner, or even deny their existence entirely. It sounds like maybe we'd be better off pursuing that? > I'm not sure that's not a good thing, but we do need to think about > it. ISTM we're gradually converging back on the monolithic approach > to MLM, with the distribution, administration, and archiving quite > tightly interwoven, and I'm not sure I like that. OTOH, we do get a > lot of requests for ever more bundling. Given our requirements, the decreased coupling in Mailman 3 is a very good thing, and I'm definitely not looking for more bundling. I hope I've clarified that above. Thanks, -- Colin Watson [cjwatson(a)ubuntu.com]

8 years, 5 months

Re: Another interesting error...

by Mark Sapiro

On 04/23/2018 01:31 PM, Darren Smith wrote: > So it appears that there was a message sent to one of our mailing lists > that was put into the held message queue. However, when attempting to go to > the message to do the moderation, the web page returns and Error 500. > > Looking in the mailman log, I found this: > > Apr 23 14:21:02 2018 (17878) REST request handler error: > Traceback (most recent call last): > File "/opt/mailman3/conda/lib/python3.6/wsgiref/handlers.py", line 137, > in run > self.result = application(self.environ, self.start_response) > File > "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/database/transac > tion.py", line 50, in wrapper > rtn = function(*args, **kws) > File > "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/rest/wsgiapp.py" > , line 214, in __call__ > return super().__call__(environ, start_response) > File "/opt/mailman3/conda/lib/python3.6/site-packages/falcon/api.py", > line 227 , in __call__ > responder(req, resp, **params) > File > "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/rest/post_modera > tion.py", line 167, in on_get > resource = self._make_collection(request) > File > "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/rest/helpers.py" > , line 159, in _make_collection > for resource in collection] > File > "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/rest/helpers.py" > , line 159, in <listcomp> > for resource in collection] > File > "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/rest/post_modera > tion.py", line 157, in _resource_as_dict > resource = self._make_resource(request.id) > File > "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/rest/post_modera > tion.py", line 100, in _make_resource > make_header(decode_header(resource['subject']))) > File "/opt/mailman3/conda/lib/python3.6/email/header.py", line 174, in > make_he ader > h.append(s, charset) > File "/opt/mailman3/conda/lib/python3.6/email/header.py", line 295, in > append > s = s.decode(input_charset, errors) > UnicodeDecodeError: 'gb2312' codec can't decode byte 0x87 in position 2: > illegal multibyte sequence > > It LOOKS as if there might be a character in the email somewhere - possibly > in the subject or sender fields? - that is somehow unexpected. It appears that the Subject: header is RFC 2047 encoded and there is an encoded word with charset gb2312 that contains an invalid encoding. The message is apparently defective, but this kind of defect shouldn't cause a 500 error. I can't tell for sure from the traceback if this is Postorius or some other application accessing the REST api. Is it Postorius or something else? > I am attempting to find the held message - can someone point me where I can > go to see the message so that I can see what might be causing the problem? It's in Mailman's database in the 'message' table. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

8 years, 2 months

Re: One-click unsubscribe?

by Stephen J. Turnbull

Jered Floyd writes: > I'm not going to defend Google's implementations and policies here, I'm not asking anybody to do it one way or the other, I'm just generally pissed off that mailing lists have to bear the burden of the abuse of mail protocols by large monopolistic companies, who won't impose sensible restrictions on their users (a domain with p=reject should not be sending to mailing lists). > but the RFC 2369 fields are regularly insufficient. You're right. I misread the code to say that the List-Unsubscribe field would contain the subscribed address if the distributed post was personalized, but it doesn't. We can fix that (in the case of a personalized list), and we should fix it with RFC 8058. I'll need to check, but I think we want to add a full configuration section on Postorius for all the List-* fields (RFCs 2369, 2919, and now 8058). Besides the options to include the fields and set their content, there should be options for "Mailman standard" mailto and http(s) URIs, as well as an option to edit the http(s) URI for folks who use something other than Postorius. I need to go back and read RFC 8058, but I think that the address information in the RFC 8058 URI can be completely opaque. I'm not sure if that's the best approach. > Regardless of that, the little box that says "this message is from > a mailing list; would you like to unsubscribe?" that appears on my > iDevice is extremely useful and a great user affordance. RFC 2369 is a standard. Every serious MUA should provide that button for every list that provides a List-Unsubscribe field, along with help for the case where the address to unsubscribe is not provided. > RFC 8058 is a standard; there's no reason for us to be needlessly > hostile to implementing it. (That's independent from prioritizing > it or finding someone with the time, of course.) I haven't noticed needless hostility. It's a LOT of work to do properly, though. Among other things, RFC 8058 requires "The List-Unsubscribe header field MUST contain one HTTPS URI." We don't necessarily control the implementation of that -- Postorius is an optional component, and Mailman core does not expose an HTTP port to the Internet by design. It's going to require changing several schemas in Mailman configuration, data models, and databases. > Are you suggesting just adding bogus RFC 8058 headers to appease > GMail? No, as explained above, I thought that Mailman was already adding subscription information to the "leave" field. The risk in what I was thinking was entirely DOS attacks on the list's subscribers via an insecure 1-click implementation. > The leave address is not sufficient for this, and as per up-thread > cannot be applied in rfc_2369.py because it is pre-personalization. That doesn't matter, since it's an easy-to-implement personalization. Just go to the end of the field, backspace past the ">", and insert a query providing the address and/or RFC 8058 token. > > I see in your later message that you haven't enabled > > personalization in Mailman. [...] Again, this was from misreading the code. My bad, I apologize. > don't think there's really any case in which personalization should > be disabled in the modern internet mail world, and would argue (but > not very strongly) that the options to turn this off probably ought > be removed from Mailman. I would oppose that. There are use cases where broadcast of generic messages make sense and unsubscribe does not, such as addresses and lists provided as a condition of organization membership. > (At the very least, personalization ought be the default.) That's plausible. -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

6 months, 3 weeks

Re: Protocol version

by David Krantz

Hi, I decided to investigate this a bit more... I find the following in mailman.log (I have removed the dates and my domain names but otherwise it is unchanged. I find it strange that postorius calls the 3.0 api version to get versions and otherwise uses the 3.1 version. This probably is the explanation for it displaying API version 3.0 when it actually uses 3.1. GET /3.1/domains HTTP/1.1" 200 1658 "-" "GNU Mailman REST client v3.3.0" GET /3.1/domains/example.com HTTP/1.1" 200 216 "-" "GNU Mailman REST client v3.3.0" POST /3.0/lists/find HTTP/1.1" 200 19177 "-" "GNU Mailman REST client v3.3.0" GET /3.0/system/versions HTTP/1.1" 200 286 "-" "GNU Mailman REST client v3.3.0" GET /3.1/domains HTTP/1.1" 200 1658 "-" "GNU Mailman REST client v3.3.0" GET /3.1/domains/lists.example.com HTTP/1.1" 200 230 "-" "GNU Mailman REST client v3.3.0" POST /3.0/lists/find HTTP/1.1" 200 19177 "-" "GNU Mailman REST client v3.3.0" GET /3.1/domains HTTP/1.1" 200 1658 "-" "GNU Mailman REST client v3.3.0" GET /3.1/domains/example.com HTTP/1.1" 200 216 "-" "GNU Mailman REST client v3.3.0" POST /3.0/lists/find HTTP/1.1" 200 19177 "-" "GNU Mailman REST client v3.3.0" GET /3.0/system/versions HTTP/1.1" 200 286 "-" "GNU Mailman REST client v3.3.0" GET /3.1/domains HTTP/1.1" 200 1658 "-" "GNU Mailman REST client v3.3.0" GET /3.1/domains/lists.example.com HTTP/1.1" 200 230 "-" "GNU Mailman REST client v3.3.0" GET /3.1/domains/example.com HTTP/1.1" 200 216 "-" "GNU Mailman REST client v3.3.0" GET /3.1/users/0039b9f69d624016bbedfddebc11f1e4/addresses HTTP/1.1" 200 467 "-" "GNU Mailman REST client v3.3.0" GET /3.1/domains/example.com/owners HTTP/1.1" 200 396 "-" "GNU Mailman REST client v3.3.0" GET /3.0/system/versions HTTP/1.1" 200 286 "-" "GNU Mailman REST client v3.3.0" GET /3.1/domains HTTP/1.1" 200 1658 "-" "GNU Mailman REST client v3.3.0" GET /3.1/domains/lists.example.com HTTP/1.1" 200 230 "-" "GNU Mailman REST client v3.3.0" GET /3.1/domains/example.com HTTP/1.1" 200 216 "-" "GNU Mailman REST client v3.3.0" POST /3.0/lists/find HTTP/1.1" 200 19177 "-" "GNU Mailman REST client v3.3.0" Thanks // David On Fri, Mar 6, 2020 at 9:42 PM David Krantz <gazorg(a)gmail.com> wrote: > > Hi. > > I have the following displayed when I look at the "System Information" > in Postorius: > > Mailman Core Version GNU Mailman 3.3.0 (La Villa Strangiato) > Mailman Core API Version 3.0 > Mailman Core Python Version 3.7.6 (default, Dec 19 2019, 23:49:42) > [GCC 5.4.0 20160609] > > What surprises me is the protocol version. I have tried to set the > protocol version to 3.1 in mailman core (which should be the latest > according to the documentation) and restarting both core and web but > that gives no effect. Normally I have not had any protocol version > defined. Everything seems to work just fine but something is strange, > either the documentation, my setup or mailman/postorius. > > // David

6 years, 2 months

Re: How to remove a nonmember from a list

by skenny＠scss.tcd.ie

Abhilash Raj wrote: > Could be, I am not sure which operation is it stuck at. Can you check logs to see > where is it breaking? Sure. I'm doing all this under Docker; below is what I see in /opt/mailman-web-data/logs/mailmanweb.log when I try to delete a nonmember via the web interface. Thediagnostics appear 30 seconds after I click on 'delete': ERROR 2020-04-09 20:35:51,482 19 postorius.middleware Mailman REST API not available Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", line 672, in urlopen chunked=chunked, File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", line 421, in _make_request six.raise_from(e, None) File "<string>", line 3, in raise_from File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", line 416, in _make_request httplib_response = conn.getresponse() File "/usr/lib/python3.6/http/client.py", line 1346, in getresponse response.begin() File "/usr/lib/python3.6/http/client.py", line 307, in begin version, status, reason = self._read_status() File "/usr/lib/python3.6/http/client.py", line 276, in _read_status raise RemoteDisconnected("Remote end closed connection without" http.client.RemoteDisconnected: Remote end closed connection without response During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/requests/adapters.py", line 449, in send timeout=timeout File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", line 720, in urlopen method, url, error=e, _pool=self, _stacktrace=sys.exc_info()[2] File "/usr/lib/python3.6/site-packages/urllib3/util/retry.py", line 400, in increment raise six.reraise(type(error), error, _stacktrace) File "/usr/lib/python3.6/site-packages/urllib3/packages/six.py", line 734, in reraise raise value.with_traceback(tb) File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", line 672, in urlopen chunked=chunked, File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", line 421, in _make_request six.raise_from(e, None) File "<string>", line 3, in raise_from File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", line 416, in _make_request httplib_response = conn.getresponse() File "/usr/lib/python3.6/http/client.py", line 1346, in getresponse response.begin() File "/usr/lib/python3.6/http/client.py", line 307, in begin version, status, reason = self._read_status() File "/usr/lib/python3.6/http/client.py", line 276, in _read_status raise RemoteDisconnected("Remote end closed connection without" urllib3.exceptions.ProtocolError: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response',)) During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/mailmanclient/restbase/connection.py", line 96, in call headers=headers) File "/usr/lib/python3.6/site-packages/requests/api.py", line 60, in request return session.request(method=method, url=url, **kwargs) File "/usr/lib/python3.6/site-packages/requests/sessions.py", line 533, in request resp = self.send(prep, **send_kwargs) File "/usr/lib/python3.6/site-packages/requests/sessions.py", line 646, in send r = adapter.send(request, **kwargs) File "/usr/lib/python3.6/site-packages/requests/adapters.py", line 498, in send raise ConnectionError(err, request=request) requests.exceptions.ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response',)) During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/django/core/handlers/base.py", line 113, in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/usr/lib/python3.6/site-packages/django/contrib/auth/decorators.py", line 21, in _wrapped_view return view_func(request, *args, **kwargs) File "/usr/lib/python3.6/site-packages/postorius/auth/decorators.py", line 38, in wrapper return fn(*args, **kwargs) File "/usr/lib/python3.6/site-packages/postorius/views/list.py", line 943, in remove_role roster = getattr(the_list, '{}s'.format(role)) File "/usr/lib/python3.6/site-packages/mailmanclient/restobjects/mailinglist.py", line 86, in nonmembers response, content = self._connection.call(url, data) File "/usr/lib/python3.6/site-packages/mailmanclient/restbase/connection.py", line 119, in call raise MailmanConnectionError('Could not connect to Mailman API') mailmanclient.restbase.connection.MailmanConnectionError: Could not connect to Mailman API ERROR 2020-04-09 20:35:51,509 19 django.request Service Unavailable: /postorius/lists/scss-sysadmins.lists.scss.tcd.ie/remove/nonmember/skenny(a)scss.tcd.ie ERROR 2020-04-09 20:35:51,509 19 django.request Service Unavailable: /postorius/lists/scss-sysadmins.lists.scss.tcd.ie/remove/nonmember/skenny(a)scss.tcd.ie The file /opt/mailman-web-data/logs/uwsgi.log contains just one line: [pid: 19|app: 0|req: 82/96] 172.19.199.5 () {46 vars in 1233 bytes} [Thu Apr 9 20:35:20 2020] GET /postorius/lists/scss-sysadmins.lists.scss.tcd.ie/remove/nonmember/skenny(a)scss.tcd.ie => generated 5583 bytes in 31411 msecs (HTTP/1.0 503) 5 headers in 180 bytes (1 switches on core 0) > Can you try doing the same with the REST API, just to verify if it is the Core which > has the issue or it is the web frontend. Using the REST API, I can successfully remove a named nonmember from the list. But I see the same pause-then-fail behaviour when I try to simply list all the nonmembers. My snippet of code can happily produce a listing of the members, but it gets stuck trying to list nonmembers, and then 30 seconds later it crashes out with exactly the same error messages as when I tried to delete a user in the web interface (see above). My piece of code appears below (II invoke it like this: docker exec -it mailman-core bash -c 'python3 /opt/mailman/local/probe.py scss-sysadmins(a)lists.scss.tcd.ie'). from mailmanclient import Client from mailmanclient import MailingList import sys my_list = str(sys.argv[1]) client = Client('http://172.19.199.2:8001/3.0', 'restadmin', 'restpass') this_list = client.get_list(my_list) print("\n\nMembers:\n-------------------------------------------------") for i in this_list.members: print(i) print("\nNonmembers:\n-------------------------------------------------") for i in this_list.nonmembers: print(i) Thanks again Stephen

6 years, 2 months

Re: Template path

by Mark Sapiro

On 9/17/20 9:33 AM, Seth Seeger wrote: > Hello everyone, > > I’m running Mailman from Docker containers, without much customization. (Postorius 1.3.3, Core 3.3.1, API 3.1, Python 3.8.5). I’ve created a list:user:notice:welcome template, and when I try to confirm a subscription, I get an error. > > I followed previous emails on this list which told me to set POSTORIUS_TEMPLATE_BASE_URL in /opt/mailman/web/settings_local.py, but that doesn’t seem to make any difference. (I set it to a different value and the error message didn’t change. I also tried setting it in /opt/mailman/core/settings_local.py to no effect. After each change, I restarted mailman-web and mailman-core containers.) How did you create the template? In Postorius or by manually creating a file somewhere? If by creating a file, POSTORIUS_TEMPLATE_BASE_URL is not relevant, but ensure that the file is findable and readable by Mailman. > From within mailman-web and mailman-core containers, I can reach “mailman-web:8000”. > > In the webpage, I see: Mailman REST API not available. Please start Mailman core. The REST APT is normally exposed on port 8001, not 8000 (See `port` in `mailman conf -s webservice`. What is your setting for MAILMAN_REST_API_URL? does the port match? > In /opt/mailman/core/var/logs/mailman.log, I get: > > [17/Sep/2020:16:23:29 +0000] "GET /3.1/lists/xxx.example.com HTTP/1.1" 200 416 "-" "GNU Mailman REST client v3.3.1" It appears you are connecting to the REST API, but ... ... > urllib3.exceptions.ReadTimeoutError: HTTPConnectionPool(host='mailman-web', port=8000): Read timed out. (read timeout=5) Something appears to be trying to connect to REST on port 8000 -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 9 months

Mailman-users search results for query "Postorius"