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

[MM3-users] Re: Turn off social logins?

by Torge Riedel

Am 16.02.19 um 13:50 schrieb Stephen J. Turnbull: > Mark Sapiro writes: > > On 2/14/19 11:10 PM, Stephen J. Turnbull wrote: > > > Torge Riedel writes: > > > > > > > - there is a way to do this now via settings_local.py, but feels > > > > a little bit risky if default configuration changes on update of > > > > mailman > > > > > > This should not be true. If it is, we need to fix that. Will check. > > > > > > It is more or less true [...] the only way settings_local.py can > > change something like INSTALLED_APPS is to redefine INSTALLED_APPS > > in it's entirety which leads to the possibility of INSTALLED_APPS > > changing in settings.py and those changes not being picked up in > > settings_local.py. > > That's a different issue from the one I believe Torge is worried > about, which is an update overwriting settings_local.py. But it's not > good. Well, Mark got it what I was meaning. Maybe my explanation was not precise enough. Hopefully an update is not overwriting settings_local.py in any case. Is it part of delivery and then changed afterwards? Haven't checked that yet. I personally like the way other services are importing custom settings by including all config files from a given directory. Maybe it is not worth for mailman cause custom settings will not grow very big - so no need to split it in tiny files. > > > The way around this is to remove the import of settings_local from > > settings.py and then put > > > > from settings import * > > > > at the beginning of settings_local.py and then point Django at > > settings_local rather than settings. > > I don't understand the ramifications of making this change (presumably > Barry or somebody had a reason for the change from Mailman 2's > method), but at first glance it looks like a big step in the right > direction. > > > Then you can do things like > > > > try: > > INSTALLED_APPS.remove('allauth.socialaccount.providers.google') > > except ValueError: > > pass > > > > in settings_local.py except there are still issues because, e.g., > > INSTALLED_APPS is defined as a tuple (immutable) and not a list in > > settings.py. > > Given the concerns of privacy advocates, I would say that it would be > better to have a separate > > AUTH_PROVIDERS = ['allauth.socialaccount.providers.google', ...] > > in settings_local.py, and merge that in to INSTALLED_APPS. Of course > removing specific providers would be OK too, but I think that this is > a place where "deny all / accept what you want" is appropriate. > > Steve >

6 years, 8 months

[MM3-users] Re: Mailman web interface / uwsgi

by Jan Eden

On 2022-11-26 12:02, Mark Sapiro wrote: > On 11/25/22 23:00, Jan Eden via Mailman-users wrote: > > > > proxy_pass http://127.0.0.1:8000; â†’ proxy_pass http://unix:/opt/mailman/mm/var/mailman.sock; > > > > and received an error message (as expected): > > > Because that won't work. You can't http to a unix socket in that way. > > Use > ``` > uwsgi_pass unix:/opt/mailman/mm/var/mailman.sock; > ``` > > > There are obviously a couple of places where the http-socket on port > > 8000 is referenced (e.g. mailman_web/settings/mailman.py, > > /opt/mailman/mm/hyperkitty.cfg). Is there an overview of the > > required changes when using a different (file) socket? > > > If you configure uwsgi with only a unix `socket` and no `http-socket`, > nothing will be listening on port 8000. Thus, you need to configure those > references to public facing URLs and let ngnix determine where to go. > > e.g., for mailman-hyperkitty.cfg > ``` > [general] > base_url: http://example.com/archives/ > ``` > and in settings.py > ``` > POSTORIUS_TEMPLATE_BASE_URL = 'https://example.com' > ``` > to override the `localhost:8000` reference in > mailman_web/settings/mailman.py. Thank you! This all makes sense, but uwsgi logged the following error after applying the changes above: > Traceback (most recent call last): > File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/handlers/wsgi.py", line 130, in __call__ > request = self.request_class(environ) > File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/handlers/wsgi.py", line 78, in __init__ > self.method = environ["REQUEST_METHOD"].upper() > KeyError: 'REQUEST_METHOD' > Traceback (most recent call last): > File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/handlers/wsgi.py", line 130, in __call__ > request = self.request_class(environ) > File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/handlers/wsgi.py", line 78, in __init__ > self.method = environ["REQUEST_METHOD"].upper() > KeyError: 'REQUEST_METHOD' So I checked my local Django configuration and found an include directive in mysite_nginx.conf (include /etc/nginx/uwsgi_params;) where the referenced file uwsgi_params contained the following: > uwsgi_param QUERY_STRING $query_string; > uwsgi_param REQUEST_METHOD $request_method; > uwsgi_param CONTENT_TYPE $content_type; > uwsgi_param CONTENT_LENGTH $content_length; > > uwsgi_param REQUEST_URI $request_uri; > uwsgi_param PATH_INFO $document_uri; > uwsgi_param DOCUMENT_ROOT $document_root; > uwsgi_param SERVER_PROTOCOL $server_protocol; > uwsgi_param REQUEST_SCHEME $scheme; > uwsgi_param HTTPS $https if_not_empty; > > uwsgi_param REMOTE_ADDR $remote_addr; > uwsgi_param REMOTE_PORT $remote_port; > uwsgi_param SERVER_PORT $server_port; > uwsgi_param SERVER_NAME $server_name; Replicating this setup on the server solved the KeyError problem, everything works now! I just wonder why these uwsgi parameters need to be passed explicitly when using a file socket, but not with a http socket. Another (unrelated) question: Why is mailman_hyperkitty.cfg placed in /opt/mailman/mm and not in /etc/mailman3 with the other configuration files when using the virtualenv installation instructions (https://docs.mailman3.org/en/latest/install/virtualenv.html#virtualenv-inst… Thanks again for all your help (and patience)! - Jan

2 years, 10 months

[MM3-users] Re: Digests not working correctly

by Joel Lord

The May 4th digest that went out was _also_ size-triggered, so this may have nothing to do with periodic digests at all, and possibly my periodic digests aren't working. I'm not on any of my own lists in digest mode, I'm slowly extracting diagnostic information out of people who are. Also, since this is a ~2 month cycle, it's really difficult to get data points to work with. I'll need to remember to go in and look when this settles down again (new cycle of activity started last night) to see if there's anything left pending. (venv) root@host2:/home/lists/mailman/venv/bin# pip freeze | grep -i hyper HyperKitty==1.3.7 On 6/4/2023 10:05 PM, Mark Sapiro wrote: > On 6/4/23 18:35, Joel Lord wrote: >> >> The periodic digests do seem to be coming out. I also now have >> confirmation that the one message in this morning's digest that was >> from May 4th was also included in the last digest back on May 4th, so >> it seems that the one message was left behind in the digest queue when >> the periodic digest was sent. > > I don't see how that can happen. The process that sends a digest renames > the var/lists/<list-id>/digest.mmdf mailbox file in which the messages > are accumulated to var/lists/<list-id>/digest.<volume>.<issue>.mmdf, > where <volume> and <issue> are the volume and issue numbers of that > digest, and then queues a message in the `digest` queue to tell the > digest runner to create the digest from the messages in that mbox and > send it. Thus, it leaves no var/lists/<list-id>/digest.mmdf mailbox file > behind and that is created anew when the next post arrives. Further, if > there is a non-empty digest.mmdf file, its messages should be sent no > later than the next 11 PM `cron digests`. > > >> There was one earlier message to the list back on May 4th, before the >> one that got duplicated, but I can't tell if that triggered a >> size-based digest to be sent: the logs aren't clear enough on that >> detail for me to tell > > > OK > > >> Just to inform things: >> >> (venv) lists@host2:~/mailman/venv/bin$ pip freeze | grep mailman >> django-mailman3==1.3.9 >> mailman==3.3.8 >> mailman-hyperkitty==1.2.1 >> mailman-web==0.0.6 >> mailmanclient==3.3.5 >> (venv) lists@host2:~/mailman/venv/bin$ pip freeze | grep hyper >> mailman-hyperkitty==1.2.1 > > Actually, it's HyperKitty, not hyperkitty, but I assume HyperKitty is up > to date as are the others. > >> (venv) lists@host2:~/mailman/venv/bin$ pip freeze | grep post >> postorius==1.3.8 >> >> > -- Joel Lord

2 years, 4 months

[MM3-users] Re: migrate MM3 list from an old server to a new one

by Odhiambo Washington

On Wed, Aug 7, 2024 at 11:52 AM IEM Network Operation Center (IOhannes m zmölnig) <noc(a)iem.at> wrote: > thanks both Mark and Odhiambo (who replied off-list) for your answers. > > On 8/6/24 18:40, Mark Sapiro wrote: > > On 8/6/24 01:43, noc(a)iem.at wrote: > >> > >> but how can i export an entire MM3 list (including 20 years of > >> archives) to some serialization format, and import it again in another > >> instance? > > > > > > With the dump and other utilities from your database manager. Almost > > everything is in the database. There are some things in Mailman's var/ > > directory, but those can simply be moved. > > > > urgh. > while this will (hopefully) work with a fresh installation, i'm somewhat > afraid whether this will also work for: > - migrating a single list from one instance to another (at least, if you > (like me) do not have have an intimate knowledge about the db layout) > Hmm.. I think I did something like this in the recent past. I need to remember how I went about it though, but it could be something like: (Assuming a virtualenv install) I believe you could: 1. Make a full backup of the old MM2 install - I mean the DB and the MM3 files. 2. update the install to the latest version corresponding to the one on the new server. 3. Delete all lists with their archives EXCEPT that one list you want to migrate. 4. Export the DB(s) 6. !! Backup the DBs on the new server (just in case something bad happens!! 7. Import the DB dumps from the old server into the new one. Hopefully, there are no conflicts with the sites - importing lists into an instance that is already populated with other > lists (things like changed db schemas come to my mind) > Here again, you should have both sites running at the same software level. right now my task is to move both some MM3 lists (from an old MM3 > instance) and some MM2 lists onto a single server with a fresh > installation, so i guess i will be fine. > Okay. > my worries are mostly about future migrations. > Sit down and write down your plans. Always come back here for 'sanity checks' on those plans. > is a feature-request warranted, or am i worrying too much? > A feature to automate your migrations? Have you consulted ChatGPT yet? :-) -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]

1 year, 2 months

[MM3-users] Re: MM2.1 -> MM3.3 migration. To hold or not hold

by mark＠suburbia.org.au

Mark Sapiro wrote: > To diagnose this further, can you create a test list, set Default action > to take when a member posts to the list to Hold, mass subscribe an > address and send a post from that address and see if it's held. It > should be, and if it is, I think things are working as they should be > and a test post to the original list from one of these mass subscribed > members will be held. I've done some testing as follows: - Created a test list - Migrated the existing list in question from its mm21 config.pck to the test list - Changed the display name to avoid confusion :-) - Checked moderator settings for the list: - Default action to take when a member posts to the list: Hold for moderation - Default action to take when a non-member posts to the list: Discard (no notification) - Emergency moderation: No - Accept/Hold/Reject/Discard non-members: all blank - CSV exported the 247 existing list members - Pasted all exported member addresses from the CSV into the mass removal web page, *except* for the list-owner. After doing so hoped that they didn't all get an unsubscribe mail. Given that "Send goodbye message" was set to yes, I suspect I did. :-\ - Confirmed List members only had the list owner - Added a first new test user (me) via mass subscribe, ticked Pre confirm, Pre approved, Pre verified. Received welcome email - Confirmed List members; list owner "Hold for moderation", test user "None" - Added a second new test user (me with a second email address) via mass subscribe with same settings as above. Received welcome email - Modified second test user to "Hold for moderation" in Members list. Noted the Moderation was set to "List default" before changing it to "Hold for moderation" - Sent an email from test user 1 to the list - Sent an email from test user 2 to the list - Sent an email from a third email address that isn't on the list - Looked at Held messages: - test user 1 email was held for moderation in Web UI. User 1 received an email indicating as such. - test user 2 email was held for moderation in Web UI. User 2 received an email indicating as such. - non-member email was neither held for moderation, nor sent to the list. > If that is true, I can only think that at the time of that post, > settings weren't as they are now. I think for now I will have to assume that's the case, until the next email can be readied against the proper list. If you hear nothing further, assume that this was all based on some random quirk (by humans or machines). I'll update if it happens again. Cheers, Mark

10 months, 3 weeks

[MM3-users] Re: SPF check fails for lists subdomain

by Jan Eden

On 2023-01-04 12:40, Mark Sapiro wrote: > On 1/4/23 11:39, Jan Eden via Mailman-users wrote: > > Hi, > > > > my question is not related to Mailman directly, apologies for using this > > list. I configured the DNS records for my base domain and my lists > > subdomain identically (the DMARC policy records are also identical, but > > not listed here): > > > > MX @ mail.eden.one > > TXT @ "v=spf1 mx ~all" > > MX lists mail.eden.one > > TXT lists "v=spf1 mx ~all" > > > > A mail 123.123.123.123 > > > > But both Yahoo and Google report different SPF results for the two domains: > > What could possibly cause this difference? The SPF test also fails for a > > [...] > > different base domain with the same MX and SPF records. > > Your spf for lists.mail.eden.one specifies its MX which is also > lists.mail.eden.one, however mail from that domain arrives from IP > 123.123.123.123 and presumably an rDNS lookup returns mail.eden.one which is > not lists.mail.eden.one, thus the failure. > > Add the IP 123.123.123.123 to the spf and drop the MX since it doesn't work > > TXT lists "v=spf1 123.123.123.123 ~all" This would explain a lot, but it also invalidates everything I thought to have understood about DNS records. Maybe the abbreviated records above (quoted from my provider's web interface) were misleading, so here's the output of dig: eden.one. 60 IN MX 10 mail.eden.one. eden.one. 60 IN TXT "v=spf1 mx ~all" lists.eden.one. 60 IN MX 10 mail.eden.one. lists.eden.one. 60 IN TXT "v=spf1 mx ~all" mail.eden.one. 60 IN A 123.123.123.123 So an MX lookup for both eden.one and lists.eden.one returns the hostname mail.eden.one, which points to the address 123.123.123.123. The SPF records for eden.one and lists.eden.one refer to the respective MX records (with the same target hostname). According to RFC 7208[1], the mx mechanism "matches if <ip> is one of the MX hosts for a domain. [...] check_host() first performs an MX lookup on the <target-name>. Then it performs an address lookup on each MX name returned. The <ip> is compared to each returned IP address. [...] If any address matches, the mechanism matches." So in both cases, the MX mechanism should first retrieve mail.eden.one, and then 123.123.123.123 via DNS queries, and should match accordingly when the message was sent from mail.eden.one/123.123.123.123. Although I could specify the IP address in my SPF records directly (as you suggested), I do hope that my understanding of DNS records laid out above is not entirely misguided. My current setup does work as expected for eden.one, after all. - Jan [1] https://www.rfc-editor.org/rfc/rfc7208#section-5.4

2 years, 9 months

[MM3-users] Timeouts

by tlhackque

On 25-Apr-21 18:08, Mark Sapiro wrote: > On 4/25/21 2:20 PM, Andrew Hodgson wrote: >> Hi, >> >> Hyperkitty 1.3.4. >> >> I am trying to download a complete list mbox by going to all threads view >> and using the download option. I have tried a couple of tools (Gunzip and >> Winrar) and both are giving me an unexpected end of file when trying to decompress the gz file. >> >> Here is the list URL I am using: https://lists.hodgsonfamily.org/hyperkitty/list/plextalk@lists.hodgsonfamil… > Depending in the web server configuration, timeouts can occur when > downloading large archive mboxes. instead of downloading the entire mbox > with > <https://lists.hodgsonfamily.org/hyperkitty/list/plextalk@lists.hodgsonfamil…>, > do it in pieces by adjusting start and end. e.g. > > <https://lists.hodgsonfamily.org/hyperkitty/list/plextalk@lists.hodgsonfamil…> > > <https://lists.hodgsonfamily.org/hyperkitty/list/plextalk@lists.hodgsonfamil…> > > <https://lists.hodgsonfamily.org/hyperkitty/list/plextalk@lists.hodgsonfamil…> > > > Although, I don't think timing out is the issue, and I'm not sure what > is, but I think it has something to do with messages in the archive. If > I try to get the 3 pieces as above, the first piece with > start=2008-02-19&end=2012-12-31 works but the others don't and even the > smaller > > <https://lists.hodgsonfamily.org/hyperkitty/list/plextalk@lists.hodgsonfamil…> > > fails the same way. > > If I try to get 2013 month by month, all work except December which > gives me an internal server error. What's the traceback from that error. > The described timeouts are something that hyperkitty ought to be able to avoid. For apache, the timeout is idle time between blocks of output. Hyperkitty can avoid this by generating the archive in segments (based on size, or elapsed time), flushing its output buffer, generating a multi-file archive, and/or using Transfer-Encoding: chunked (chunked doesn't work for http/2). It ought to be able to break the work into blocks of "n" messages & do something to generate output. Besides avoiding timeouts, working in segments allows the GUI to display meaningful progress (e.g. if you're loading with XMLHttpRequest, "onprogress") It really oughtn't be up to the user to break up the request. Until then: the apache directive is "TimeOut" (or "ProxyTimeout"), with a default value of 60 (seconds). It's a server config/virtual host parameter, so if you're running in an environment where you only have .htaccess, you need admin help or you're out of luck. Other webservers (especially those with accelerators) may have more granular timeouts.

4 years, 5 months

[MM3-users] Re: Attack on Mailman Server?

by Eggert Ehmke

In the log file there are several entries like this: ERROR 2023-03-09 13:09:34,066 53357 django.request Internal Server Error: /accounts/ signup/ Traceback (most recent call last): File "/opt/mailman/venv/lib/python3.9/site-packages/django/core/handlers/exception.py", line 47, in inner response = get_response(request) File "/opt/mailman/venv/lib/python3.9/site-packages/django/core/handlers/base.py", line 181, in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/opt/mailman/venv/lib/python3.9/site-packages/django/views/generic/base.py", line 70, in view return self.dispatch(request, *args, **kwargs) File "/opt/mailman/venv/lib/python3.9/site-packages/django/utils/decorators.py", line 43, in _wrapper return bound_method(*args, **kwargs) File "/opt/mailman/venv/lib/python3.9/site-packages/allauth/decorators.py", line 18, in wrap resp = ratelimit.consume_or_429(request, action=action, **rl_kwargs) File "/opt/mailman/venv/lib/python3.9/site-packages/allauth/ratelimit.py", line 77, in consume_or_429 return render(request, "429." + app_settings.TEMPLATE_EXTENSION, status=429) File "/opt/mailman/venv/lib/python3.9/site-packages/django/shortcuts.py", line 19, in render content = loader.render_to_string(template_name, context, request, using=using) File "/opt/mailman/venv/lib/python3.9/site-packages/django/template/loader.py", line 61, in render_to_string template = get_template(template_name, using=using) File "/opt/mailman/venv/lib/python3.9/site-packages/django/template/loader.py", line 19, in get_template raise TemplateDoesNotExist(template_name, chain=chain) django.template.exceptions.TemplateDoesNotExist: 429.html So what is special about this 429.html? Am Donnerstag, 9. März 2023, 21:26:03 CET schrieb Mark Sapiro: > On 3/9/23 11:34, Eggert Ehmke via Mailman-users wrote: > > I had some attacks on my wordpress homepage today, I added some IPs to the > > blacklist of my firewall. At the same time, I got several reports like > > this: > > > > Internal Server Error: /accounts/signup/ > > > > TemplateDoesNotExist at /accounts/signup/ > > 429.html > > I suspect that's a coincidence. > > > Request Method: OPTIONS > > Request URL: https://lists.eehmke.de/accounts/signup/ > > Django Version: 3.2.16 > > Python Executable: /opt/mailman/venv/bin/uwsgi > > Python Version: 3.9.2 > > Python Path: ['.', '', '/etc/mailman3', '/usr/lib/python39.zip', > > '/usr/lib/ > > python3.9', '/usr/lib/python3.9/lib-dynload', '/opt/mailman/venv/lib/ > > python3.9/site-packages'] > > Server time: Thu, 09 Mar 2023 13:09:34 +0100 > > > > So it seems there were attempts to register new users but this caused this > > internal error. Where can I send the complete error message? > > I would look in the web server logs to see what the actual accesses > were. I'm guessing you'll find that some bot or script kiddies did a GET > of /accounts/signup/429.html. > > You could also look for more detail in whatever log Django writes. This > is defined in Django's settings as > LOGGING['handlers']['file']['filename'] and is often Mailman's > var/logs/mailmansuite.log. If you followed > https://docs.mailman3.org/en/latest/install/virtualenv.html#initial-configur > ation it is /opt/mailman/web/logs/mailmanweb.log.

2 years, 7 months

[MM3-users] Re: old usernames appearing in mailman.log

by Ken Alker

--On Sunday, June 25, 2023 3:26 PM -0700 Mark Sapiro <mark(a)msapiro.net> wrote: > On 6/25/23 2:27 PM, Ken Alker wrote: >> --On Sunday, June 25, 2023 1:14 PM -0700 Mark Sapiro <mark(a)msapiro.net> >> wrote: >> I see this in the logs from just after midnight: >> >> Jun 25 00:13:04 2023 (386086) No cached copy of the public suffix list >> found >> Jun 25 00:13:04 2023 (386086) ACCEPT: >> <7500f0e2-1ae1-309d-60d7-6e592c7abf7a(a)west.net> >> Jun 25 00:13:04 2023 (386090) HyperKitty failure on >> https://lists.netlojix.com/hyperkitty/api/mailman/urls: >> >> Followed by a huge amount of HTML (strange). > > This is all from one post. > > The first is normal it just says that Mailman's > var/public_suffix_list.dat doesn't exist, but it should be retrieved from > https://publicsuffix.org/list/public_suffix_list.dat and then saved at > var/public_suffix_list.dat so it doesn't need to be retrieved from the > web again until the saved copy is older that the configured > dmarc.cache_lifetime (default = 7 days, so that message) after which time > the message will be 'Cached copy of public suffix list is out of date' > > The second is acceptance of the post. > > The third is a failure in archiving the message. Th HTML should contain > an error message with a traceback which should help determine the problem. > > >> Is there a way to kick it into re-running whatever it does at midnight >> so I can test this again after putting the public suffix list back? I >> assume I can just execute "mailman-web runjobs daily", but will this >> mess things up, or is it OK to run it mid-day without stopping anything >> first? > > > Midnight is a coincidence in this case. the above are all due to the post > with Message-ID: <7500f0e2-1ae1-309d-60d7-6e592c7abf7a(a)west.net> > > The cached var/public_suffix_list.dat should now be there with a > timestamp of Jul 02 00:13:04 (7 days from Jun 25 00:13:04) Yes, thanks. >> Is the last (third) log line excerpt simply a result of the first, or do >> I have something else messed up? > > The third is not because of the first. It is because of some issue with > archiving that post. I have studied the output, looked at the code lines referenced in the Traceback, and I can't figure out the problem (I feel like the sad guy on the side of the street with his hood up staring into the engine bay with stream pouring out and not knowing what to do next). I did some analyses on the log file and determined that there are 71 messages it is having problems processing and there are 71 messages "stuck" in /opt/mailman/mm/var/archives/hyperkitty/spool/ (and that it has tried to process each message about 20 times). Since upgrading to V3.3.8 I've not seen new messages get stuck like this (although it's only been running smoothly for 24 hours now and there hasn't been much activity). But I'm suspecting there was something awry between the conversion from V2 to V3 in February and me installing V3.3.8 that caused this (based on message time stamps). It is HIGHLY likely these messages are in the archiving spool as a result of me unshunting the shunt queue and that they are copies of the messages that got delivered to the subscribers when I did that... but are now hung up in the archiving process. Following is an excerpt from mailman.log. Note that the "first section" (from DOCTYPE at top to 404 at bottom) is repeated four times (maybe not identical; but similar) (so I did not include it to save room) before the Traceback appears. Jun 25 00:13:04 2023 (386086) No cached copy of the public suffix list found Jun 25 00:13:04 2023 (386086) ACCEPT: <7500f0e2-1ae1-309d-60d7-6e592c7abf7a(a)west.net> Jun 25 00:13:04 2023 (386090) HyperKitty failure on https://lists.netlojix.com/hyperkitty/api/mailman/urls: <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1"> <title>lists.netlojix.com</title> <link rel="shortcut icon" href="/static/postorius/img/favicon.ico"> <link rel="stylesheet" href="/static/postorius/libs/bootstrap/css/bootstrap.min.css"> <link rel="stylesheet" href="/static/django-mailman3/css/main.css"> <link rel="stylesheet" href="/static/postorius/css/style.css"> <link rel="stylesheet" href="/static/postorius/libs/fonts/font-awesome/css/font-awesome.min.css" type="text/css" media="all" />    </head> <body> <nav class="navbar navbar-expand-md navbar-light bg-light navbar-default"> <div class="container"> <div class="navbar-header"> <button type="button" class="navbar-toggler collapsed" data-toggle="collapse" data-target="#header-nav" aria-expanded="false"> <span class="sr-only">Toggle navigation</span> <span class="fa fa-bars"></span> </button> <a class="navbar-brand" href="/mailman3/lists/"><span><img src="/static/postorius/img/mailman_logo_small_trans.png" alt="Mailman logo"/> Postorius</span></a> </div> <div class="collapse navbar-collapse" id="header-nav"> <ul class="nav navbar-nav mr-auto"> <li class="nav-item"><a href="/mailman3/lists/" class="nav-link"> <span class="fa fa-envelope"></span> Lists </a></li> <li class="nav-item"><a href="/archives/" class="nav-link"> <span class="fa fa-comment"></span> Archives </a></li> </ul> <ul class="nav navbar-nav navbar-right"> <li class="nav-item"><a class="nav-link" href="/accounts/login/?next=/hyperkitty/api/mailman/urls"> <span class="fa fa-sign-in"></span> Login </a></li> <li class="nav-item"><a class="nav-link" href="/accounts/signup/?next=/hyperkitty/api/mailman/urls"> <span class="fa fa-user-plus"></span> Sign Up </a></li> </ul> </div> </div> </nav> <div class="container" role="main"> <h1>Page not found</h1> <div class="alert alert-danger">This page either doesn't exist, or it moved somewhere else.</div> </div> <footer class="footer"> <div class="container"> <p class="text-center"> <a href="https://postorius.readthedocs.org">Postorius Documentation</a> • <a href="http://list.org">GNU Mailman</a> • Postorius Version 1.3.8 </p> </div> </footer> <script src="/static/postorius/libs/jquery/jquery-3.6.0.min.js"></script> <script src="/static/postorius/libs/popperjs/popper-v1.11.0.min.js"></script> <script src="/static/postorius/libs/bootstrap/js/bootstrap.min.js"></script> <script src="/static/django-mailman3/js/main.js"></script> <script src="/static/postorius/js/script.js"></script> <script> // Add the .js-enabled class to the body so we can style the elements // depending on whether Javascript is enabled. $(document).ready(function(){ $("body").addClass("js-enabled"); }); </script> </body> </html> (404) ... above portion of log (or similar) repeats three more times ... Jun 25 00:13:05 2023 (386083) Traceback (most recent call last): File "/opt/mailman/venv/lib/python3.8/site-packages/mailman_hyperkitty/__init__.py", line 158, in _archive_message url = self._send_message(mlist, msg) File "/opt/mailman/venv/lib/python3.8/site-packages/mailman_hyperkitty/__init__.py", line 228, in _send_message raise ValueError(result.text) ValueError:

2 years, 3 months

[MM3-users] Re: MM3 templates

by Odhiambo Washington

On Thu, Feb 16, 2023 at 10:26 AM Mark Sapiro <mark(a)msapiro.net> wrote: > On 2/15/23 23:04, Odhiambo Washington wrote: > > > > The last time I referred to the link, I deliberately duplicated the <LC> > > folder in two locations: > > [09:51 ~ ]$ ls -al /opt/mailman/mm/var/templates/site/en/ > > total 48 > > drwxr-xr-x 2 mailman mailman 512 Feb 14 08:53 . > > drwxr-xr-x 3 mailman mailman 512 Feb 14 08:53 .. > > -rw------- 1 mailman mailman 615 Jan 17 13:57 > domain:admin:notice:new-list.txt > > -rw------- 1 mailman mailman 341 Jan 17 13:54 > list:admin:action:post.txt > > -rw------- 1 mailman mailman 158 Dec 17 13:32 > list:member:digest:footer.txt > > -rw------- 1 mailman mailman 452 Jan 17 13:54 > list:member:digest:masthead.txt > > -rw------- 1 mailman mailman 137 Jan 17 13:55 > list:member:generic:footer.txt > > -rw------- 1 mailman mailman 1219 Dec 8 15:12 > list:member:regular:footer.txt > > -rw------- 1 mailman mailman 944 Jan 17 15:50 > list:user:action:subscribe.txt > > -rw------- 1 mailman mailman 247 Jan 17 13:56 > list:user:notice:post.txt > > -rw------- 1 mailman mailman 802 Jan 17 13:56 > list:user:notice:probe.txt > > -rw------- 1 mailman mailman 639 Jan 17 13:57 > list:user:notice:welcome.txt > > > > Yet, it is NOT being picked. So definitely something is wrong somewhere. > > > If you have the same list:* file in both > /opt/mailman/mm/var/templates/site/en/ and > /opt/mailman/mm/var/templates/lists/kictanet.lists.kictanet.or.ke/en/ > the ones in the lists directory will take precedence for that list over > the ones in the site directory. > In my case, I had the exact same files in the two paths and the list:user:action:subscribe.txt was still not used in my tests. Why? I have now created the directory: mkdir -p /opt/mailman/mm/var/templates/domains/lists.kictanet.or.ke/en/ And I have placed the same files in there. Gearing up for a test to see if the template will be used this time around. > See > > https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/utilities/i18n… > for a discussion of the search order. > Will do. > >> > >> Are the other templates such as list:member:regular:footer.txt used? > >> > > > > I do see that in posts to the list, but I believe that is perhaps only > > working because the list had that footer when it was imported from MM2. > > A template from import21 of the kictanet(a)lists.kictanet.or.ke list will > be stored in the > /opt/mailman/mm/var/templates/lists/kictanet.lists.kictanet.or.ke/en/ > directory. > It wasn't a template per se. It was the regular nondigest msg_footer from MM2. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)

2 years, 8 months

Search results for query "sapiro"