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

[MM3-users] Re: moving lists to another server

by Odhiambo Washington

On Sat, Nov 18, 2023 at 1:42 AM Mark Sapiro <mark(a)msapiro.net> wrote: > On 11/17/23 00:51, Odhiambo Washington wrote: > > > I am scratching my head bald trying to figure out how to bring in this > > other MM3 site and list into my existing server, especially with regard > to > > the DB backend. > > > > The list - let's call it users(a)domainX.name was using MySQL backend and > > had a separate DB for Mailman core and Mailman web. > > I believe combining these into one isn't a problem. But getting to merge > > this DB into my current one is what I am not sure about. > > This is https://gitlab.com/mailman/postorius/-/issues/13 which is a real > need, but doesn't yet exist. > > I think the easiest thing for the archives is to forget the Mailman web > DB and just export the archive as a mbox from the other site (if it's > large, exporting the entire archive will time out so you have to do it > in pieces). Then you can use hyperkitty_import to import it. > What is the command to export the archive as a mbox from the DB? I can't figure out which option it is by looking at 'mailman-web -h'. > For the list data, it's probably easiest to just create the list > manually and go through the settings in Postorius and make them match, I want to go with the above. although you could dump the mailinglist table entry where list_id = > 'users(a)domainx.name' and load that, but you'd need to edit the id field > in the dump to match the id on your server. Not going with that. > That leaves the members. Given that I have a dump of the two DBs (mailman and mailman-web) I just created one DB and imported them. I have been able to dump the members into a text file. Now importing is not a problem. BTW, how will ' mailman addmembers' treat a file containing: ``` Firstname Lastname <email@address> Onlyname <email2@address> ``` ? > Doing this with a DB dump/load would be very complex because while the > member table has a list_id field which is the id of the list's entry in > the mailinglist table and can be used to select the relevant members, > these records also link to entries in the address, preferences and user > tables and matching them would be an issue. > I am also not taking that path. I think a custom script would be required. If I were doing this, I would > make a separate database on my server with a copy of the data from the > other server and then try to make a script that would extract data from > the other database and add it to mine. Alternatively you could just dump the members from the other servers > with the `mailman members` command perhaps separately for regular and > the different digest types and then add them with the `mailman > addmembers` command. This wouldn't get all their attributes, but it > could work. > I have opted for the simple way to do this: 1. Create the site in Django Admin and create/configure the list in Postorius 2. Add the members from the file dump, with delivery set to regular. 3. Send the members an email informing them that they need to set their delivery preferences. I am stuck on the issue of exporting the archives to mbox file as already stated above. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]

2 years, 5 months

[MM3-users] GNU Mailman condemns reinstatement of RMS

by Abhilash Raj

To the Mailman community, The GNU Mailman Steering Committee condemns the reinstatement of Richard M. Stallman (RMS) to the Board of the Free Software Foundation (FSF), and has taken the following actions: 1. On behalf of the GNU Mailman project, signed the letter on GitHub[1] calling for the removal of the entire FSF Board, as well as RMS himself. 2. Started exploring ways to move our financial assets, for decades managed by the FSF, to new management. The management fees are small, but this is an important symbolic protest. 3. Started exploring how to leave the GNU Project. On the one hand, if we leave but GNU wants to maintain a "GNU Mailman" project, we cannot stop them, confusing users. On the other hand, RMS is leader of the GNU Project, and has intervened in Mailman affairs on many occasions. We should forestall this in the future. We wish to explain our actions to the community. Although free exchange of software among users is a practice that goes back to days of the earliest general purpose computers, RMS was the first to propose a complete free software distribution, and is the acknowledged founder of the Free Software movement. Even leaders of the Berkeley Software Distribution (BSD) acknowledge this. We all owe him a debt for this. Nevertheless, the movement has matured and thrived, spawning the competitive open source movement, with whose philosophy Mailman is more closely aligned. While we acknowledge our debt to RMS, we don't need him any longer. And unfortunately, he has become both a symbol and a source of the toxicity in tech communities. The FSF Board did the right thing by accepting RMS's resignation. They did the wrong thing by reinstating him. RMS has a long history of abusive behavior and toxic political positions. A small part of it is described in the open letter on GitHub[1] and its references[2], and several members of the Steering Committee have observed it directly. All of us have heard stories directly from those who were abused or observed it directly. His political positions are public, for example his support of pedophiles. He claims that he in no way supports abusive relationships with children, yet refuses to acknowledge that children are generally in no position to provide consent, an evasive and highly toxic position. There is no question: RMS is toxic. We came for mailing list management, but we stayed for the community. We have a right to protect our community by dissociating it from toxic influences. We do not want our project associated with such a person, nor to provide economic resources to organizations that promote him to leadership positions. We are taking these actions to protect our community, both the narrow community of Mailman developers and users, and the broader open source community, from his toxic behavior and from the reputational damage that will come from helping to enable him. While we have no information suggesting that other members of the FSF Board are similarly toxic as individuals, as a group they enabled RMS for decades, and now have taken an explicit step in enabling him again. If they want to regain their position of respect and acceptance in our community, they must acknowledge their error, and we don't see -- given their reinstatement of RMS himself -- how they can do so convincingly while maintaining their positions on the Board. They must resign, and a new Board composed, to demonstrate their sincerity. What they do is up to them, of course, but if they do not take radical steps, we will continue to consider association with the FSF a threat to our community. For the Mailman community, Abhilash Raj (project leader) Mark Sapiro Stephen J. Turnbull Aurélien Bompard Terri Oda Barry Warsaw John Viega (founder) [1] Text and signatures: https://rms-open-letter.github.io [2] Appendix to the letter: https://rms-open-letter.github.io/appendix Related statements: https://rms-open-letter.github.io/statements

5 years

[MM3-users] Custom templates (was: Re: Re: nginx configuration on a multitasking server)

by David Newman

On 12/23/21 10:39 AM, Mark Sapiro wrote: > On 12/23/21 9:57 AM, David Newman wrote: >> >> The task-pending message that MM3 sends to list owners and moderators >> just says generically to check the dashboard, without providing a URL. >> >> Can that be modified to provide an explicit URL, something like this? >> >> https://lists.example.com/mailman3/lists/listname > > > Yes, That particular message is built from the list:admin:action:post > template. You may wish to make custom versions of that and other > templates. The templates and their default values are at > https://gitlab.com/mailman/mailman/-/tree/master/src/mailman/templates/en > > You can make custom versions of templates in two ways. You can create if > necessary a /opt/mailman/mm/var/templates directory (it probably already > exists). Within that directory, sitewide English templates are put in > the site/en/ directory, domain specific English templates are put in the > domains/<domain_name>/en/ directory and list specific English templates > are put in the lists/<list_id>/en/ directory. > > For templates like this, you probably want sitewide ones. E.g., > site/en/list:admin:action:post.txt > --------------------------------------------------------------- > As list administrator, your authorization is requested for the > following mailing list posting: > > List: $listname > From: $sender_email > Subject: $subject > > The message is being held because: > > $reasons > > At your convenience, visit > https://lists.example.com/mailman3/lists/$list_id/held_messages > to approve or deny the request. > --------------------------------------------------------------- > > The other way to create custom templates is via Postotrius, but > Postorius only creates list and domain specific templates. Also, if you > create a template in Postorius, it overrides any in > /opt/mailman/mm/var/templates/ until you delete it in Postorius. > > Info about templates and what substitution variables can be used is at > https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/… Following up on this thread from a few weeks ago, a custom subscribe template I defined is not getting sent out. I created a pending subscription request on a test list. Here is the text I'm using in a file called 'list:admin:action:subscribe.txt' (minus the rows of hypens): ---------- As list administrator, your authorization is required for a mailing list subscription request approval: For: $member List: $listname At your convenience, visit: https://${domain}/mailman/admindb/lists/${short_listname}.${domain}/ to approve or deny the request. ---------- Instead the message that goes out at midnight daily reads like this: ---------- The test(a)lists.domain.tld list has 1 moderation requests waiting. Held Subscriptions: User: letmein(a)domain.tld Please attend to this at your earliest convenience. ---------- On successive nights I have placed copies of the 'list:admin:action:subscribe.txt' file above in these locations: mm/var/templates/lists/test.lists.domain.tld/en /opt/mailman/mm/var/templates/site/en and then in Postorius, with the same contents as above. The file versions are owned by the mailman user, and have 0644 permissions. Not sure this is necessary but I've restarted the mailman3 and mailmanweb services each time after a change. There is no sign of trouble in the MM3 or web logs. The only thing I see is in the Postfix log, where the shorter and less helpful message goes out each night. I don't see anything in the template docs about this. Questions: 1. What to do to get the custom message working? 2. Is there a way to trigger a subscribe reminder for one list only? Asking because there are other lists on this server with other requests pending, and I don't want to bother other moderators with multiple reminders per day. Not a big deal, but it would be nice to test this with one list rather than waiting up to 24 hours after each change. Thank you! dn

4 years, 3 months

[MM3-users] Re: Mails are not archived at all -- how to check if Hyperkitty is running or not?

by Tamas HOLCZER

Hi Franklin, when I installed mailman3 on Debian I had some issues. One was about MAILMAN_ARCHIVER_FROM. It turned out, that the request to Hyperkitty was sent from one of the real IPs of the machine (not from localhost). This depends on the interfaces and the routing of that machine. In my case the solution was something like: MAILMAN_ARCHIVER_FROM = ('127.0.0.1', '::1', '1.2.3.4', '1.2.3.5') , where 1.2.3.4 and 1.2.3.5 are the IP addresses of the machine running mailman3 (I have not debugged if it is using .4 or .5 in reality I left both of them there). Give it a try with your IPs. Tamás 2019. 10. 30. 8:52 keltezéssel, Franklin Weng írta: > Hi, > > It looks like to have some clues now. > > Mark Sapiro <mark(a)msapiro.net> 於 2019年10月30日週三 13:07 寫道： > >> On 10/29/19 8:21 PM, Franklin Weng wrote: >>> Yes, it is checked. >> Have you checked Mailman's logs - Mailman's var/logs/mailman.log in >> particular? >> > I found some hyperkitty URL error: > > The default settings of base_url in mailman-hyperkitty.cfg is defined as > > base_url: http://localhost/mailman/hyperkitty/ > > In the mailman.log there are messages like: > > Oct 30 13:53:43 2019 (14259) HyperKitty failure on > http://localhost/mailman3/hyperkitty/api/mailman/archive: <!DOCTYPE HTML > PUBLIC "-//IETF// > DTD HTML 2.0//EN"> > <html><head> > <title>404 Not Found</title> > </head><body> > <h1>Not Found</h1> > <p>The requested URL was not found on this server.</p> > > I changed it to > > base_url: https://localhost/mailman3/hyperkitty/ > > then the log became > > File "/usr/lib/python3/dist-packages/requests > /adapters.py", line 514, in send > raise SSLError(e, request=request) > requests.exceptions.SSLError: HTTPSConnectionPool(host='localhost', > port=443): Max retries exceeded with url: > /mailman3/hyperkitty/api/mailman/archive?key=xxx (Caused by > SSLError(SSLCertVerification Error("hostname 'localhost' doesn't match ' > lists.slat.org'"))) > > which makes sense because the SSL certificate applied from Letsencrypt is > for lists.slat.org. > > If I use > > base_url: https://lists.slat.org/mailman3/hyperkitty/ > > The log became > > Oct 30 15:25:50 2019 (6256) HyperKitty failure on > https://lists.slat.org/mailman3/hyperkitty/api/mailman/urls: > <html><title>Auth required</title><body> > > <h1>Authorization Required</h1> > </body></html> (401) > > In my mailman-web.py: > > MAILMAN_ARCHIVER_KEY = 'my-key,same as in mailman-hyperkitty.cfg' > MAILMAN_ARCHIVER_FROM = ('127.0.0.1', '::1') > > Not sure what to change here. > > >> Do messages received from the list have an Archived-At: header? >> > Yes, but it's empty > > > List-Id: 測試論壇 <slat-list.lists.slat.org> > Archived-At: <> > List-Archive: <> > List-Help: <mailto:slat-list-request@lists.slat.org?subject=help> > List-Post: <mailto:slat-list@lists.slat.org> > List-Subscribe: <mailto:slat-list-join@lists.slat.org> > List-Unsubscribe: <mailto:slat-list-leave@lists.slat.org> > > > >> What's in /etc/mailman3/mailman-hyperkitty.cfg? In particular does the >> [general] setting base_url define a URL that accesses hyperkitty > > It seems to be the question… > > > and >> does the [general] setting api_key match the MAILMAN_ARCHIVER_KEY >> setting in /etc/mailman3/mailman-web.py, but note that the >> MAILMAN_ARCHIVER_KEY setting is quotes because it is a Python string >> assignment and the api_key setting is not quoted >> > Yes, it's single quoted. > > > Thanks for all your help! > > > Franklin > _______________________________________________ > 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/

6 years, 6 months

[MM3-users]Re: mailman 2 vs. mailman 3: what happened to multipart/digest?

by John Hein

Here's an '02 reference in git to the some heritage for multipart/digest ========== commit 63d2568fe58333f8ca0b7582f74b43e775c581cd Author: bwarsaw <> Date: Thu Jul 11 22:14:25 2002 +0000 send_i18n_digests(): Let's generate MIME digests the correct way, by wrapping each message inside the multipart/digest in a MIMEMessage instance. We also no longer need to initialize the mimedigest instance's payload to the empty list. Also, when sending the digests, be sure to include isdigest=1 in the metadata, otherwise SMTPDirect will try to tack on another footer. ========== John wrote at 16:46 -0600 on May 12, 2016: > Mark Sapiro wrote at 12:18 -0700 on May 12, 2016: > > On 5/12/16 9:16 AM, John wrote: > > > Digest delivery in mailman 2 encapsulated the individual message/rfc822 messages in a multipart/digest container. This allowed email clients to show the messages in the particular digest in a threaded view. > > > > > > This format vs. plain text digests was a user option in Mailman 2. > > > > > > > It seems like the various digest options that I have tried [1] in mailman 3.1.0 (as implemented for the fedora-users mailing list) no longer encapsulate messages in multipart/digest. > > > > > > The core still supports the same plain text and MIME format digests and > > the same individual subscriber and per-list default formats as did > > Mailman 2. The issue is none of these things are exposed in Postorius. > > > > If you subscribe to digests on this list, you will receive the > > 'encapsulated' MIME format because the lists mime_is_default_digest > > setting is True, but currently that has to be set through the > > bin/mailman shell tool. > > > > > > > Is this intentional? Is it a bug - feature that was lost in translation from 2 to 3? Is there a delivery option I'm missing that will turn that back on? > > Thanks for the info - and Barry's reply as well. I understand that > MIME digests are supported in Mailman 3 - that's what I'm using (and > thanks, Barry, for the info that Summary Digests is the same right > now). My quibble is that the multipart/digest encapsulation level is > gone. > > Barry Warsaw wrote at 15:16 -0400 on May 12, 2016: > > The MIME format of MIME digests should roughly be: > > > > multipart/mixed > > text/plain (the digest heading) > > text/plain (the TOC) > > message/rfc822 > > message-1 > > message/rfc822 > > message-2 > > ... > > text/plain (footer) > > > But mm 2 had: > > multipart/mixed > text/plain (the digest heading) > text/plain (the TOC) > multipart/digest <--- this is the part that's gone in mm3 > message/rfc822 > message-1 > message/rfc822 > message-2 > ... > text/plain (footer) > > So was that removal intentional, a bug or ?? > > Maybe you're saying there is definitely an unexposed (in Postorius) > knob for that in mm3. > > > > > It is the intent that Postorius will eventually expose all these > > settings. We're not there yet. At present you could possibly do this by > > interacting with mailmanclient, although I'm not certain the settings > > are exposed there. You can do it via bin/mailman shell if you have > > access and know what you're doing (see > > <http://mailman.readthedocs.io/en/release-3.0/src/mailman/runners/docs/diges…>) > > > > If you file an issue at > > <https://gitlab.com/mailman/postorius/issues/new>, it might help > > expedite this. > > Okay. > _______________________________________________ > Mailman-users mailing list > mailman-users(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/

9 years, 11 months

[MM3-users] Re: Wrong info in moderation mail when held due to match of a header rule

by tlhackque

On 17-Oct-20 18:40, Mark Sapiro wrote: > On 10/17/20 1:31 PM, tlhackque via Mailman-users wrote: >> I might also add the rule number or config filename:line, as in >> >> Header "{name}": rule in {file}:{n} matched value "{value}" >> >> This would be helpful when backtracking from a rejected message to the >> cause. >> >> A sample expansion might be: >> >> Header "X-Spam": rule in foo.conf:83 matched value "yes" > > These rules are not in a configuration file. They are in the headermatch > table in the database and the rules for a particular list are exposed on > the Header filters tab in Postorius or at the REST > lists/LISTNAME/header-matches endpoint. > > Perhaps something like > > {name}: header match rule, pattern "{pattern}" matched value "{value}" > > example: > > subject: header match rule, pattern "sex|long|list|of|other|bad|words" > matched value "This is a post about filtering based on words like sex in > the subject." > > but that could be just adding more clutter. > I considered including the regex in each message, but that seemed redundant - and potentially long. Thus the pointer. Perhaps number the rules for each list, and use that index? The ROWID would seem to be a candidate for the number. Then Postorius could simply number the rules in its tab; the REST API can add the ROWID as a rule_ID field in the returned JSON. (The fact that it's a ROWID rather than an index or unique name is an implementation detail.) If many rules are anticipated, it might want an endpoint or option to fetch a rule by ID. Then it would be easy to drill down on a specific event for diagnosis. e.g. shunt_reason: (or whatever) { cause: "header_match" header: "subject" header_value: "This is a post about filtering based on words like sex in the subject." rule_id: 47 /* or pattern_id? */ } displays as subject: header match rule 47, matched value "This is a post about filtering based on words like sex in the subject." and lists/LISTNAME/header-matches/47 returns { rule_id: 47 pattern: "sex|long|list|of|other|bad|words" position: 3 /* Whatever else is in your table... I haven't looked since I postponed using MM3. eg */ comment:"Required by policy 869.202" last_updated_by: "Corporate Prude" last_updated_on: "1-Apr-1762" }, while lists/LISTNAME/header-matches returns an array of those structures, presumably as today. With those capabilities, the UI can be enhanced so that clicking on a shunted message gives the summary reason, and clicking on the summary gives the regex. I expect that the header and value will be sufficient for understanding an issue most of the time. Looking at the regex is less common, and only necessary when it needs to be updated... I still think that it is more readable and less verbose to order the message as a declarative sentence: Header "subject": rule 47 matched value "sex" but that may be a matter of personal taste. The UI can sort that out... Note that from your description, using ROWID may cause rules in a particular list to have gaps in the rule numbering. I don't think that's a big issue, though Postorious could paper that over - perhaps use the position attribute. Doesn't seem worth doing something more complex. The advantage is that it doesn't require any DB change now. But aliasing it to "rule_id" allows for any future demand to name the rules or use some other numbering scheme. I may have some details wrong - I found mm3 not ready for my needs and am thus out of date - but I hope the high level approach that I outlined is useful.

5 years, 6 months

[MM3-users] Re: Mailman stopping message distribution because of SMTP errors

by Victoriano Giralt

El mié, 12-02-2020 a las 13:28 -0800, Mark Sapiro escribió: > On 2/11/20 10:28 PM, Victoriano Giralt wrote: > > > > I have recently migrated some lists from Mailman 2 to Mailman 3. Users > > have > > been added using the mailman client as pre-verified addresses so the > > migration happened "silently". Thus, there was a dozen "bad" addresses > > (domains that did not exist anymore). > > > It seems you rolled your own instead of using `mailman import21`. Is > there a reason for this? Yes, no access to the previous server command line. So, to tell the truth it was not a "real" migration, my excuses. > > Unfortunately, Mailman got some of the "bad" addresses in the first > > message > > batch for sending out, so, Postfix closed the connection because of > > "too > > many errors" and this stopped the process completely, i.e. Mailman did > > not > > continue sending messages to the rest of the list over 600 addresses. > > > Is the message shunted? Is there a traceback and a shunting message in > mailman.log? > > Normally, I would expect the message to be queued in Mailman's retry > queue and retried by Mailman Yes, it was being retried every 15 minutes with the same result: stopped distribution after the first attempt with the first address batch. Also reprocessing the "retry" files with mailman command interface. > > There was no more information in the logs than the Postfix error > > messages > > in smtp.log. My bad, the errors where in the system maillog where Postfix complains. > What was in the smtp.log? This (redacted to protect the innocent): Feb 05 16:29:44 2020 (86791) ('127.0.0.1', 51146) recip: listname @example.org Feb 05 16:30:16 2020 (86797) <messageid(a)example.com> smtp to listname @example.org for 634 recips, completed in 29.087315797805786 seconds Feb 05 16:30:16 2020 (86797) <messageid(a)example.com> post to listname @example.org from sender(a)example.com, 4354 bytes, 9 failures Feb 05 16:30:20 2020 (86791) ('127.0.0.1', 51642) Data: b'RCPT TO:<listname -bounces(a)example.org>' Feb 05 16:30:20 2020 (86791) ('127.0.0.1', 51642) recip: listname -bounces(a)example.org Feb 05 16:30:43 2020 (86791) ('127.0.0.1', 51870) Data: b'RCPT TO:<listname -bounces(a)example.org>' Feb 05 16:30:43 2020 (86791) ('127.0.0.1', 51870) recip: listname -bounces(a)example.org ... rinse and repeat every 15 minutes ... > Nothing in mailman.log? Nothing at all about SMTP/LMTP > Nothing in var/queue/shunt? Nothing there, a .psv file in var/spool/mailman/bad/ and two .pck files in retry/ > Once the "bad" addresses were removed, the list started working as > > expected. > > > > I consider this a bug. The bouncing addresses should have been marked > > as > > "non deliverable" and the subscriptions "paused" and the rest should > > have > > been delivered. Or, the list owner should have been notified that there > > was > > a problem with message distribution. None of these happened. > > > The HEAD of the https://gitlab.com/mailman/mailman master branch > implements bounce processing. This will be in 3.3.1 which is not yet > released. > > The place for a bug report is <https://gitlab.com/mailman/mailman/issues> Well, if 3.3.1 has bounce processing, I'd rather wait and test when it is released instead of adding "noise" in the bug tracker, right? My problem was solved with a workaround: find and remove the "bad" addresses. Let's leave this as reference in the archives in case someone hits the same problem. -- Victoriano Giralt CIO University of Malaga +34952131415 SPAIN ================================================================== Note: signature.asc is the electronic signature of present message A: Yes. > Q: Are you sure ? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email ?

6 years, 2 months

[MM3-users] Re: Mailman, etc. upgrade woes and persistent bugs

by Abhilash Raj

On Sun, Feb 14, 2021, at 8:59 AM, Allan Hansen wrote: > Mark, > > Thank you for this reminder, but it’s not really sufficient for most. > The ‘Mailman Settings’ dialog does, indeed show the other preferences > tags, and yes, as you say, the dialog for ‘List-based preferences’ only > shows values that are not inherited and when you set a value there, it > shows. > > There a two problems with this: > > a. Once a value is overridden on the ‘List-based preferences’ dialog, > you cannot go back to it being inherited by removing the override. Yes! This is something we've known for a while and haven't been able to fix properly. https://gitlab.com/mailman/postorius/-/issues/414 https://gitlab.com/mailman/postorius/-/issues/195 There more than one open issue for this. And one of the reasons it hasn't been fixed yet is that it is larger problem than most low hanging fruits that gets fixed in the available time window for the us to work on issue. This is a long weekend for me, so I'll start some work on this, but not sure if that would be enough to finish. > b. You cannot see, on this dialog, what the inherited value is. https://gitlab.com/mailman/postorius/-/issues/476 I opened an issue for this too, but this might be a little bit longer of a task because the whole inheritance and calculation of effective preference/setting happens in Core. It would require that Core expose the effective values. We do have some calculation of preferences in Postorius to display the "Global Mailman preferences" page for a User. > This is not user-friendly. > > May I suggest the following: > > That each option shows the following: > > o Value 1 > o Value 2 > (or the equivalent for pull-down menus) > > A box showing inheritance status: > [ ] Use inherited value from address-based preference: Value2 > > If the ‘Use inherited value’ is chosen, then the inherited value shows. > but the value radio buttons become non-selectable. It is a good idea, might need Javascript skills that I don't have ;-) I'll still try to take a stab at implementing such a view. > If not, then whatever value the value radio box has become the value > for the list, > > From what I see, the ‘Use inherited value’ is the default for new > lists/addresses. To change a value, the user would > uncheck this box, making the radio buttons selectable, and then set the > desired value. > > Yours, > > Allan > > > > On Feb 12, 2021, at 11:52 , Mark Sapiro <mark(a)msapiro.net> wrote: > > > >> I then looked at several of the disabled accounts, but the subscription info page in Postorius had no information about whether an account was enabled or disabled. Why is this not displayed???. The members can't see if their account is enabled. Is this another example of the disconnect between Mailman and Postorius? > > > > > > If the user has a Django account, she can see all that info at (e.g. for > > this list) <https://lists.mailman3.org/mailman3/accounts/subscriptions/ <https://lists.mailman3.org/mailman3/accounts/subscriptions/>> > > She gets there from `Mailman settings` in the dropdown under her user > > name. She can also get there via the `Manage Subscription` button on the > > list's Info page. That takes her to `List-based preferences` for the > > list. Any setting not selected there is inherited from the Address-based > > preferences or Global Mailman preferences > > _______________________________________________ > 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, 2 months

[MM3-users] Re: Mailman3 without Hyperkitty in docker

by Abhilash Raj

On Sat, Mar 2, 2019, at 1:09 AM, Danil Smirnov wrote: > Thank you very much Abhilash! > > Could you set up 'latest' tag in postotius repo <https://hub.docker.com/r/maxking/postorius/tags> please - as it exists for core/web? > I'd like to have consistent approach across the images... Done, triggered a build on Dockerhub. docker.io/maxking/postorius:latest This should be available when the build is done. > > Also it would be really great to extend image labelling used for *quay.io/maxking/mailman-*:rolling* images to Docker Hub ones... Version identification is quite hard for Docker... rolling tags should be available on DockerHub too. They are replicated on both registries. > > With my best regards, > Danil > > сб, 2 мар. 2019 г. в 03:19, Abhilash Raj <maxking(a)asynchronous.in>: >> __ >> >> >> On Thu, Feb 28, 2019, at 10:18 PM, Danil Smirnov wrote: >>> Hi Abhilash, >>> >>> Thank you very much - the previous error is fixed now. >>> >>> But I have another one now, which causes the same 500 Server Error: >>> >>> bash-4.3# cat /opt/mailman-web-data/logs/uwsgi-error.log >>> *** Starting uWSGI 2.0.18 (64bit) on [Fri Mar 1 05:42:09 2019] *** >>> compiled with version: 6.3.0 on 01 March 2019 01:52:42 >>> os: Linux-3.10.0-693.11.1.el7.x86_64 #1 SMP Mon Dec 4 23:52:40 UTC 2017 >>> nodename: mailman-web >>> machine: x86_64 >>> clock source: unix >>> detected number of CPU cores: 2 >>> current working directory: /opt/mailman-web >>> detected binary path: /usr/local/bin/uwsgi >>> !!! no internal routing support, rebuild with pcre support !!! >>> setgid() to 101 >>> setuid() to 100 >>> chdir() to /opt/mailman-web >>> your memory page size is 4096 bytes >>> detected max file descriptor number: 1048576 >>> building mime-types dictionary from file /etc/mime.types...1168 entry found >>> lock engine: pthread robust mutexes >>> thunder lock: disabled (you can enable it with --thunder-lock) >>> uwsgi socket 0 bound to TCP address 0.0.0.0:8080 fd 8 >>> uwsgi socket 1 bound to TCP address 0.0.0.0:8000 fd 9 >>> Python version: 3.6.8 (default, Jan 30 2019, 23:58:16) [GCC 6.3.0] >>> Python main interpreter initialized at 0x55a2df7f57e0 >>> python threads support enabled >>> your server socket listen backlog is limited to 100 connections >>> your mercy for graceful operations on workers is 60 seconds >>> mapped 166752 bytes (162 KB) for 2 cores >>> *** Operational MODE: threaded *** >>> Traceback (most recent call last): >>> File "/usr/local/lib/python3.6/site-packages/django/utils/module_loading.py", line 20, in import_string >>> return getattr(module, class_name) >>> AttributeError: module 'django.contrib.auth.middleware' has no attribute 'SessionAuthenticationMiddleware' >>> >>> The above exception was the direct cause of the following exception: >>> >>> Traceback (most recent call last): >>> File "wsgi.py", line 38, in <module> >>> application = get_wsgi_application() >>> File "/usr/local/lib/python3.6/site-packages/django/core/wsgi.py", line 13, in get_wsgi_application >>> return WSGIHandler() >>> File "/usr/local/lib/python3.6/site-packages/django/core/handlers/wsgi.py", line 136, in __init__ >>> self.load_middleware() >>> File "/usr/local/lib/python3.6/site-packages/django/core/handlers/base.py", line 34, in load_middleware >>> middleware = import_string(middleware_path) >>> File "/usr/local/lib/python3.6/site-packages/django/utils/module_loading.py", line 24, in import_string >>> ) from err >>> ImportError: Module "django.contrib.auth.middleware" does not define a "SessionAuthenticationMiddleware" attribute/class >>> unable to load app 0 (mountpoint='') (callable not found or import error) >>> *** no app loaded. going in full dynamic mode *** >>> *** uWSGI is running in multiple interpreter mode *** >>> spawned uWSGI master process (pid: 1) >>> spawned uWSGI worker 1 (pid: 37, cores: 2) >>> --- no python application found, check your startup logs for errors --- >>> --- no python application found, check your startup logs for errors --- >>> --- no python application found, check your startup logs for errors --- >>> --- no python application found, check your startup logs for errors --- >>> --- no python application found, check your startup logs for errors --- >>> --- no python application found, check your startup logs for errors --- >>> --- no python application found, check your startup logs for errors --- >>> --- no python application found, check your startup logs for errors --- >>> --- no python application found, check your startup logs for errors --- >>> --- no python application found, check your startup logs for errors --- >>> --- no python application found, check your startup logs for errors --- >>> --- no python application found, check your startup logs for errors --- >>> >>> As per my investigation, this error possibly caused by Django upgrade: >>> >>> *The SessionAuthenticationMiddleware class is removed. It provided no functionality since session authentication is unconditionally enabled in Django 1.10.* >>> >>> See https://docs.djangoproject.com/en/2.0/releases/2.0/ >>> >>> After I've removed the line >>> https://github.com/maxking/docker-mailman/blob/master/postorius/mailman-web… >>> from settings.py, the container is finally working. >>> >>> I've placed PR in github: >>> https://github.com/maxking/docker-mailman/pull/314 >> >> Thank you for your contributions! >> >> I have merged your pull request and it should now be out (hopefully!). >> >>> >>> Thank you for your help. >>> >>> Danil >>> >>> >>> пт, 1 мар. 2019 г. в 04:33, Abhilash Raj <maxking(a)asynchronous.in>: >>>> >>>> >>>> On Thu, Feb 28, 2019, at 5:19 PM, Abhilash Raj wrote: >>>> > On February 27, 2019 11:53:34 PM PST, Danil Smirnov <danil(a)smirnov.la> wrote: >>>> > >Hi Mark, >>>> > > >>>> > >Actually all this stuff happens inside the container after it's started >>>> > >and >>>> > >initialized without errors. I didn't amend the image anyhow. >>>> > > >>>> > >Also I have the configuration based on docker-compose.yaml provided in >>>> > >the >>>> > >repository which works just fine for mailman-web image. >>>> > > >>>> > >The very same config with postorius image (+ UWSGI_STATIC_MAP param) >>>> > >fails >>>> > >with 500 error... >>>> > > >>>> > >Now answering your questions: >>>> > > >>>> > >ср, 27 февр. 2019 г., 22:56 Mark Sapiro <mark(a)msapiro.net>: >>>> > > >>>> > >> do you have django-q in INSTALLED_APPS in your Django settings and >>>> > >what >>>> > >> is set for Q_CLUSTER? >>>> > >> >>>> > > >>>> > >I've checked settings.py inside the container and I haven't found any >>>> > >of >>>> > >the mentioned configurations there. >>>> > > >>>> > >Does the manage.py that's being run here point to the right >>>> > >settings.py? >>>> > >> >>>> > > >>>> > >No clue. >>>> > > >>>> > >Also I wonder why we have some Hyperkitty-related cronjobs in non-HK >>>> > >configured image? >>>> > > >>>> > >https://github.com/maxking/docker-mailman/blob/master/postorius/mailman-web… >>>> > >>>> > Because I am a dum dum ;-) >>>> > >>>> > Will work on removing those crons and stuff. Would be nice if you >>>> > opened an issue on Github so that I don't forget. >>>> >>>> Should now be fixed in the latest image. >>>> >>>> > >>>> > >Danil >>>> > > >>>> > > >>>> > > >>>> > >> -- >>>> > >> Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, >>>> > >> San Francisco Bay Area, California better use your sense - B. >>>> > >Dylan >>>> > >> _______________________________________________ >>>> > >> Mailman-users mailing list -- mailman-users(a)mailman3.org >>>> > >> To unsubscribe send an email to mailman-users-leave(a)mailman3.org >>>> > >> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ >>>> > >> >>>> > >_______________________________________________ >>>> > >Mailman-users mailing list -- mailman-users(a)mailman3.org >>>> > >To unsubscribe send an email to mailman-users-leave(a)mailman3.org >>>> > >https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ >>>> > >>>> > >>>> > -- >>>> > Sent from my Android device with K-9 Mail. Please excuse my brevity. >>>> >>>> -- >>>> thanks, >>>> Abhilash Raj (maxking) >> >> -- >> thanks, >> Abhilash Raj (maxking) >> >> -- thanks, Abhilash Raj (maxking)

7 years, 2 months

[MM3-users] Re: Timeouts

by tlhackque

On 25-Apr-21 20:34, Mark Sapiro wrote: > On 4/25/21 4:37 PM, tlhackque via Mailman-users wrote: > >> 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. > It is not the web server that times out. I'm not sure about uwsgi > because I don't use it, but the timeouts I see are on servers that use > gunicorn as the WSGI interface to Django and the timeout is in a > gunicorn worker. This is controlled by the timeout setting in the > gunicorn config. <https://docs.gunicorn.org/en/stable/settings.html#timeout> > > Note that even 300 seconds is not enough to download the entire > <https://mail.python.org/archives/list/python-dev@python.org/> archive. > > It may be possible to get HyperKitty to chunk the output to avoid this, > but it doesn't currently do that. Care to submit an MR? > > I'm afraid (u)WSGI, Django, and gunicorn are not technologies that I work with. It sounds as if hyperkitty is compiling the entire archive before sending the first byte. The gunicorn doc that you pointed to says Workers silent for more than this many seconds are killed and restarted. Setting it to 0 has the effect of infinite timeouts by disabling timeouts for all workers entirely. "Silent" sounds like the standard webserver "you have to push some bits, or we assume you're stuck". My understanding is that gunicorn is a Python persistence server that is run behind a webserver proxy. So the (proxy) webserver (apache, nginx, ...) timeouts also apply and would need to be increased. Might be interesting to try 0 (gunicorn) / 1200 (webserver) with your python-dev archive, time it and see how much (encoded) data is transferred... (I would expect most mailing list archives to compress nicely, though those with binary attachments wont.) But fiddling with timeouts is treating the symptom, not the root cause. The right solution is to stream, segment (or chunk) the output, because in the general case, no timeout is long enough. It'll always be possible to find an archive that's just one byte (or second) longer than any chosen timeout. (See the halting problem.) You want the timeout to catch a lack of progress, not total time that's a function of transaction size. (Webservers may also have limits on transaction size - e.g. mod_security, but they're only useful when the upper bound on a response is knowable.) Thus, the timeout(s) should be roughly independent of the archive size; on the order of time-to-first-byte (which ordinarily is longer than time between segments/chunks). Also note that streaming requires fewer server resources than compiling a complete archive before sending, since you don't need to create the entire archive in memory (or in a tempfile). You only need enough memory to efficiently buffer the file I/O and to contain the compression tables/output buffer. Except for trivial cases, this will be independent of the archive size. The only downside is that if the comm link is slow, you may hold a reader lock on the source data for longer than necessary with the current scheme. Seems as though this deserves an issue. I guess I could open one - but you have the experience/test cases.

5 years

Search results for query "sapiro"