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

[MM3-users] Re: Can't add emails to accept_these_nonmembers

by Ibiam Chihurumnaya

Mark Sapiro wrote: > On 2/26/26 13:20, Ibiam Chihurumnaya via Mailman-users wrote: > > I'm doing it in mailman shell, list_name is a List object, and it seems to have a settings > > attribute as list_name.settings returns > > {'acceptable_aliases': [], ...} > > I would really like to know what Mailman version this is, and how it was > installed? In my case with Mailman core from the head of the GitLab branch: > $ mailman shell -l list.example.com > Welcome to the GNU Mailman shell > Use commit() to commit changes. > Use abort() to discard changes since the last commit. > Exit with ctrl+D does an implicit commit() but exit() does not. > The variable 'm' is the list.example.com mailing list > >>> m.settings > Traceback (most recent call last): > File "<console>", line 1, in <module> > AttributeError: 'MailingList' object has no attribute 'settings' > >>> m.settings['accept_these_nonmembers'] > Traceback (most recent call last): > File "<console>", line 1, in <module> > AttributeError: 'MailingList' object has no attribute 'settings' > >>> Currently running Mailman 3.3.10 and I followed the instructions from https://docs.mailman3.org/en/latest/install/virtualenv.html# to install. This is the output from mine, I get the same output as you do when I try exactly what you do; mailman shell -l systems-logs(a)lists.sugarlabs.org Welcome to the GNU Mailman shell Use commit() to commit changes. Use abort() to discard changes since the last commit. Exit with ctrl+D does an implicit commit() but exit() does not. The variable 'm' is the systems-logs(a)lists.sugarlabs.org mailing list >>> m.settings Traceback (most recent call last): File "<console>", line 1, in <module> AttributeError: 'MailingList' object has no attribute 'settings' I get something else when I do it differently - how I've been doing it so far -. mailman shell Welcome to the GNU Mailman shell Use commit() to commit changes. Use abort() to discard changes since the last commit. Exit with ctrl+D does an implicit commit() but exit() does not. >>> from mailmanclient import Client >>> from mailmanclient import Client >>> client = Client('http://localhost:8001/3.1', '**', '**') >>> sg = client.domains[0] >>> sy = sg.get_lists()[-1] >>> sy <List 'systems-logs(a)lists.sugarlabs.org'> >>> sy.settings {'acceptable_aliases': [], 'accept_these_nonmembers': [], 'admin_immed_notify': True, 'admin_notify_mchanges': False, 'administrivia': True, 'advertised': False, 'allow_list_posts': True, 'anonymous_list': False, 'archive_policy': 'public', 'archive_rendering_mode': 'text', 'autorespond_owner': 'none', 'autorespond_postings': 'none', 'autorespond_requests': 'none', 'autoresponse_grace_period': '90d', 'autoresponse_owner_text': '', 'autoresponse_postings_text': '', 'autoresponse_request_text': '', 'bounces_address': 'systems-logs-bounces(a)lists.sugarlabs.org', 'bounce_info_stale_after': '7d', 'bounce_notify_owner_on_bounce_increment': False, 'bounce_notify_owner_on_disable': True, 'bounce_notify_owner_on_removal': True, 'bounce_score_threshold': 5, 'bounce_you_are_disabled_warnings': 3, 'bounce_you_are_disabled_warnings_interval': '7d', 'collapse_alternatives': True, 'convert_html_to_plaintext': False, 'created_at': '2026-02-04T21:53:10.928951', 'default_member_action': 'defer', 'default_nonmember_action': 'accept', 'description': '', 'digest_last_sent_at': '2026-02-27T11:24:11.916379', 'digest_send_periodic': True, 'digest_size_threshold': 30.0, 'digest_volume_frequency': 'monthly', 'digests_enabled': True, 'display_name': 'Systems-logs', 'discard_these_nonmembers': [], 'dmarc_mitigate_action': 'no_mitigation', 'dmarc_mitigate_unconditionally': False, 'dmarc_addresses': [], 'dmarc_moderation_notice': '', 'dmarc_wrapped_message_text': '', 'emergency': False, 'filter_action': 'discard', 'filter_content': False, 'filter_extensions': [], 'filter_types': [], 'first_strip_reply_to': False, 'forward_unrecognized_bounces_to': 'administrators', 'fqdn_listname': 'systems-logs(a)lists.sugarlabs.org', 'gateway_to_mail': False, 'gateway_to_news': False, 'hold_these_nonmembers': [], 'include_rfc2369_headers': True, 'info': '', 'join_address': 'systems-logs-join(a)lists.sugarlabs.org', 'last_post_at': '2026-02-27T11:32:51.317220', 'leave_address': 'systems-logs-leave(a)lists.sugarlabs.org', 'linked_newsgroup': '', 'list_name': 'systems-logs', 'mail_host': 'lists.sugarlabs.org', 'max_message_size': 40, 'max_num_recipients': 10, 'max_days_to_hold': 0, 'member_roster_visibility': 'moderators', 'moderator_password': None, 'newsgroup_moderation': 'none', 'next_digest_number': 60, 'nntp_prefix_subject_too': True, 'no_reply_address': 'noreply(a)lists.sugarlabs.org', 'owner_address': 'systems-logs-owner(a)lists.sugarlabs.org', 'pass_types': [], 'pass_extensions': [], 'personalize': 'none', 'post_id': 316, 'posting_address': 'systems-logs(a)lists.sugarlabs.org', 'posting_pipeline': 'default-posting-pipeline', 'preferred_language': 'en', 'process_bounces': True, 'reject_these_nonmembers': [], 'reply_goes_to_list': 'no_munging', 'reply_to_address': '', 'request_address': 'systems-logs-request(a)lists.sugarlabs.org', 'require_explicit_destination': True, 'respond_to_post_requests': True, 'send_goodbye_message': True, 'send_welcome_message': True, 'subject_prefix': '[Systems-logs] ', 'subscription_policy': 'confirm', 'unsubscription_policy': 'confirm', 'usenet_watermark': None, 'volume': 1} > > Presumably in your case, you could do > list_name.settings['accept_these_nonmembers'].append('user(a)example.com') > > or > > list_name.settings['accept_these_nonmembers'].extend(['user1(a)example.com', > 'user2(a)example.com', 'user3(a)example.com']) > > but as I've said previously, accept_these_nonmembers is not the > preferred way to do this. Something like > $ mailman addmembers --delivery disabled FILE LIST > Yes, I see now that it's not the preferred way to do it. It's difficult to know that when looking at the documentation. > where FILE contains the addresses to add, one per line and LIST is the > list name would add the addresses as members with delivery disabled. To > add them as nonmembers with moderation_action Defer: > $ mailman shell -l list.example.com > Welcome to the GNU Mailman shell > Use commit() to commit changes. > Use abort() to discard changes since the last commit. > Exit with ctrl+D does an implicit commit() but exit() does not. > The variable 'm' is the list.example.com mailing list > >>> from mailman.app.membership import add_member > >>> addresses = ('user1(a)example.com', 'user2(a)example.com', > ... 'user3(a)example.com') > >>> for addr in addresses: > ... rr = RequestRecord(addr) > ... nm = add_member(m, rr, role=MemberRole.nonmember) > ... nm.moderation_action = Action.defer > ... > >>>commit() Thank you! > > Of course, all of this can be done, perhaps more easily, using the > Postorius web UI. Yes, but like I've mentioned in another thread, I don't have access to the web UI because I can't get a confirmation link. > -- > Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, > San Francisco Bay Area, California better use your sense - B. Dylan

6 months, 2 weeks

[MM3-users] Re: not correct language in subject(s)

by Jens Günther

Thanks Mark for the tests and your thoughts on this matter. Am 23.05.23 um 17:19 schrieb Mark Sapiro: > > That file was for a test only. The German message catalog is at > mailman/messages/de/LC_MESSAGES/. That directory should contain a > mailman.po and a mailman.mo. If there is no mailman.mo, it needs to be > created. The source distribution contains a generate_mo.sh script to > generate these for all languages, but you can do the German one by > changing to the mailman/messages/de/LC_MESSAGES/ directory in the > running installation and doing > > msgfmt mailman.po -o mailman.mo I just checked the mailman/messages/de/LC_MESSAGES directory and there was only a mailman.po. I tried to create the mo-file with the command you provided, unfortunately it doesn't work in the running docker-container (obviously the gettext-package is missing ... and can't install it with apt, but this is another docker-related problem, shall I open another thread?). I did create on OS-level the mo-file, restarted the container and now the welcome- and goodbye-subject is indeed in German, coolio! 2 thoughts on this for me is: - Shall I create all the mo-files (the other folders also only contain the po)? If so, how would it be possible? - How can I make it persistent? (probably it should be included in the repo!? also another thread or an issue regarding maxxking's repo!?) > > I just tested, and the notice to the moderator of a held message is in > the list's preferred language including the Subject: and the moderation > reason, and the notice to the user sending a held message is in the > User's preferred language for that list including the Subject: and the > moderation reason. > > I suspect your issue is you don't have the compiled mailman.mo German > message catalog. The text is in German because it comes from templates > and you presumably do have German language templates. > Exactly. What I was wondering: for the welcome-messages I did not have explicit templates for those lists/domains/site that I wrote in German, it has to be from the predefined templates, which are stored elsewhere the in the mo-files!? (actually I don't get this point exactly but wouldn't bother, if the above works). Thanks again!

3 years, 3 months

[MM3-users] Re: Removing a mail addresses and users

by Abhijith PA

Hi Mark, On 11/06/20 1:16 am, Mark Sapiro wrote: > On 6/10/20 10:23 AM, Abhijith PA via Mailman-users wrote: >> Hello. >> >> I tried to remove random email address signing ups (which I signed up >> while testing) via admin panel. After removing I tried to sign up again, >> but I am getting, >> >> 'A user is already registered with this e-mail address' > > You removed the user's subscription from the list, but you didn't remove > the user from the system. > > Mailman3 has a concept of `user` which didn't exist in Mailman 2.1. > User's have addresses and a user or one of the user's addresses can > belong to a list with one or more roles (non-member, member, moderator > or owner) In my case these user signups were just to test postorious. These mail accounts didn't subscribed to anything. >> Combing through the database, I found auth_user table in mailman3web db >> still contain those mail address. How to wipe email address entirely >> from the db so I can signup again without the 'forget password' method > > There are a couple of things. If you log in to the web UI as a django > superuser, you can go to the django admin UI -> Users section and delete > the User, but I think that will only delete the web user and not delete > the user from Mailman core. > > You can also log in to the web UI as the user and go to > <https://lists.mailman3.org/user-profile/delete>, but that again only > deletes the web user, and if you could do that, you could just subscribe > once you're logged in, so I assume that's what you want to avoid. > > I don't think there is a way for a user as opposed to a site admin to > delete her user record from Mailman core and even for a site admin, > there's no way in Postorius to delete a user from core. It has to be > done via REST > <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/…> > or `mailman shell`. > Thanks for the link, let me try that out. --abhijith

6 years, 3 months

[MM3-users] Re: Confirmation emails aren't sent to users.

by Ibiam Chihurumnaya

Stephen J. Turnbull wrote: > Ibiam Chihurumnaya via Mailman-users writes: > > Mark Sapiro wrote: > > > OK, this is Django. The default EMAIL_BACKEND from > > mailman_web/settings/base.py is > > django.core.mail.backends.smtp.EmailBackend and unless you've changed > > that or added overrides various other defaults are > > EMAIL_HOST = "localhost" > > EMAIL_PORT = 25 > > EMAIL_HOST_USER = "" > > EMAIL_HOST_PASSWORD = "" > > EMAIL_USE_TLS = False > > EMAIL_USE_SSL = False > > EMAIL_SSL_CERTFILE = None > > EMAIL_SSL_KEYFILE = None > > Are those appropriate? Do you have an outgoing MTA listening on > > localhost:25? What's in it's logs? > > I don't have any of those set, didn't realize I needed to have them > > set, the docs didn't make it obvious too. > > Those defaults *are* set in the mailman_web settings files. You can > override them in /etc/mailman3/settings.py, but often you don't need > to. Makes sense, I didn't think I needed to. Couldn't see them with mailman conf though. > > I also didn't notice them in schema.cfg in mailman. > > This is for Django, whose configuration is in > /etc/mailman3/settings.py, with defaults set in the mailmanweb package > in your venv's site-package in the files in .../mailman_web/settings/. > > smtp_port is currently set to 25, and I do have an outgoing MTA > > listening on localhost:25. > > If Mailman can distribute posts that way, Django should be able to > send mail with the default settings. > > Nothing shows up in the MTA logs about this particular email. > > Not sure what to say about that. I'm not sure Postorius or Django log > outgoing mail messages but I think they use the mailmanweb.log file by > default if they log mail at all. (This is separate from the MTA logs > which should record any connections from localhost and mail submitted.) Is there any way I could get more logs, I had set Debug = True in settings.py a while back, but can't see anything more. > -- > GNU Mailman consultant (installation, migration, customization) > Sirius Open Source https://www.siriusopensource.com/ > Software systems consulting in Europe, North America, and Japan

7 months

[MM3-users] Re: A little stuck with installation of MM3 - ModuleNotFoundError: No module named 'flufl.lock'

by Odhiambo Washington

On Thu, 30 Jul 2020 at 00:13, Mark Sapiro <mark(a)msapiro.net> wrote: > On 7/29/20 12:15 AM, Odhiambo Washington wrote: > > > > Yes, the same problem. > > I created the file __init__.py in /opt/mailman/mm > > However, when I run using the wsgi.py I ended up (still do!) with the > error: > > > > [Wed Jul 29 10:08:51.869144 2020] [wsgi:info] [pid 79132] [remote > > 197.232.81.246:64709] mod_wsgi (pid=79132, process='mailman-web', > > application='mm3-lists.server.name|/mm3'): Loading Python script file > > '/opt/mailman/mm/wsgi.py'. > > What is the contend of the file /opt/mailman/mm/wsgi.py? > [wash@gw ~]$ cd /opt/mailman/mm/ [wash@gw /opt/mailman/mm]$ less wsgi.py """ WSGI config for HyperKitty project. It exposes the WSGI callable as a module-level variable named ``application``. For more information on this file, see https://docs.djangoproject.com/en/{{ docs_version }}/howto/deployment/wsgi/ """ import os # import sys # import site # For some unknown reason, sometimes mod_wsgi fails to set the python paths to # the virtualenv, with the 'python-path' option. You can do it here too. # # # Remember original sys.path. #prev_sys_path = list(sys.path) # # Add here, for the settings module #site.addsitedir(os.path.abspath(os.path.dirname(__file__))) # # Add the virtualenv #venv = os.path.join(os.path.abspath(os.path.dirname(__file__)), # '..', 'lib', 'python2.6', 'site-packages') # site.addsitedir(venv) # # Reorder sys.path so new directories at the front. # new_sys_path = [] # for item in list(sys.path): # if item not in prev_sys_path: # new_sys_path.append(item) # sys.path.remove(item) # sys.path[:0] = new_sys_path from django.core.wsgi import get_wsgi_application os.environ.setdefault("DJANGO_SETTINGS_MODULE", "settings") application = get_wsgi_application() > You previously posted the setting of WSGIDaemonProcess in your Apache > config as: > > > WSGIDaemonProcess mailman-web display-name=mailman-web > maximum-requests=1000 umask=0002 user=mailman3 \ > > group=mailman3 > python-path=/opt/mailman/mm/venv/lib/python3.7/site-packages:/opt/mailman/mm/venv/lib/python3.7 > \ > > python-home=/opt/mailman/mm/venv home=/opt/mailman/mm/var > > Is it still that? > This is from wsgi.conf in my Apache Includes/. It's a copy/paste of your version, with the only modification being the change pf python version to 3.7 -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", grep ^[^#] :-)

6 years, 1 month

[MM3-users] Re: integrating mm3 with postfix / lmtp

by Fabian A. Santiago

On October 25, 2017 9:13:20 PM EDT, Mark Sapiro <mark(a)msapiro.net> wrote: >On 10/25/2017 05:41 PM, Fabian A. Santiago wrote: >> >> No to the domains part and I think virtual alias maps is needed: >> >> mail postfix/trivial-rewrite[19445]: warning: do not list domain xxx >in BOTH virtual_mailbox_domains and relay_domains >> Oct 25 20:39:19 mail postfix/trivial-rewrite[19445]: warning: do not >list domain xxx in BOTH virtual_mailbox_domains and relay_domains >> Oct 25 20:39:19 mail postfix/submission/smtpd[19441]: NOQUEUE: >reject: RCPT from >pool-108-53-239-102.nwrknj.fios.verizon.net[108.53.239.102]: 550 5.1.1 ><test123@xxx>: Recipient address rejected: User unknown in virtual >mailbox table; from=<fsantiago@xxx> to=<test123@xxx> proto=ESMTP >helo=<[10.0.0.29]> > >(above slightly sanitized for return to the list) > >The issue here is your list domain cannot be a virtual_mailbox_domain >or >a virtual_alias_domain. > >I have the same issue on mail.python.org where we have both Mailman 2 >and Mailman 3 lists @python.org. and python.org is a >virtual_alias_domain. > >I have a group of MRs for a branch that implements "alias_domains" to >deal with this. > >Basically it works by creating another (virtual_alias_maps) >postfix_vmap >mapping to map list addresses @python.org to addresses @x.python.org. >Then the postfix_domains and postfix_lmtp maps have the x.python.org >domain and there is a patch to mailman/runners/lmtp.py to map the >x.python.org domain back to python.org. > >The various MRs are ><https://gitlab.com/mailman/mailman/merge_requests/202> for the core, ><https://gitlab.com/mailman/mailmanclient/merge_requests/18> for the >REST bindings used by Postorius and ><https://gitlab.com/mailman/postorius/merge_requests/186> to be able to >set an alias_domain via Postorius. > >That's not all implemented at mail.python.org. What's there is the >basic >Postfix config, a bash script the generate the new mappings from the >old >and a simple patch to mailman/runners/lmtp.py. > >So, the bottom line is it can be done and it's in process, but it won't >really be supported until Mailman 3.2. In the mean time, you just need >to have a separate domain for your lists that isn't a virtual_*_domain. Ok thanks. At least I have a clear answer now. Any ETA on 3.2 in mind yet? -- Thanks, Fabian S. OpenPGP: 3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC

8 years, 10 months

[MM3-users] Re: Sending a message to a subscription applicant when a subscription request is made

by Allan Hansen

Much appreciated, Mark. We'll go with (a.), as it's a one-liner as I expected, and it does not require me to change the policy. I'll just need to make some adjustments to the template contents. Yours, Allan On 3/28/23, 11:29, "Mark Sapiro" <mark(a)msapiro.net <mailto:mark@msapiro.net>> wrote: On 3/28/23 10:45, Allan Hansen wrote: > > a. That we change the lines in the Python program in our installation that send 'list:admin:action:subscribe' to the list admins to instead send the template to the applying subscriber. This patch will do that --- a/src/mailman/app/subscriptions.py +++ b/src/mailman/app/subscriptions.py @@ -338,7 +338,7 @@ class SubscriptionWorkflow(_SubscriptionWorkflowCommon): # This message should appear to come from the <list>-owner so as # to avoid any useless bounce processing. msg = UserNotification( - self.mlist.owner_address, self.mlist.owner_address, + self.address.email, self.mlist.owner_address, subject, text, self.mlist.preferred_language) msg.send(self.mlist) # The workflow must stop running here. Watch for wrapped lines. Note that this only works if Admin immed notify is Yes. > b. That we change the lines in the Python program in our installation that send 'list:user:action:subscribe' to the subscriber with an unverified address to always do this, even when the incoming address has already been verified. I think this patch will do it, but needs testing --- a/src/mailman/app/subscriptions.py +++ b/src/mailman/app/subscriptions.py @@ -285,7 +285,7 @@ class SubscriptionWorkflow(_SubscriptionWorkflowCommon): # If we do not need the user's confirmation, then skip to the # moderation checks. if self.mlist.subscription_policy is SubscriptionPolicy.moderate: - self.push('moderation_checks') + self.push('send_confirmation') return # If the subscription has been pre-confirmed, then we can skip the # confirmation check can be skipped. If moderator approval is Again watch for wrapped lines. -- Mark Sapiro <mark(a)msapiro.net <mailto:mark@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 <mailto:mailman-users@mailman3.org> To unsubscribe send an email to mailman-users-leave(a)mailman3.org <mailto:mailman-users-leave@mailman3.org> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/> Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org <mailto:mailman-users@mailman3.org>/message/NNMWW4PW55H4OLA3NTAKZLRNIEV2HHUA/ This message sent to hansen(a)rc.org <mailto:hansen@rc.org>

3 years, 5 months

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

by Abhilash Raj

This is kind of a top-post, because I am not sure which message should my reply quote. Please excuse that part. My thinking on this topic resonates with what Steve said, I don't think we should be forcing the Mailman Administrators to handle username passwords. Dare I say that most social auth providers have more incentive and money to keep their database secure than Mailman Administrators. Having said that, it doesn't have to be either or between "social logins enabled by default" and "I don't want to see a Facebook button". I have actually thought about this before, but never have been able to get to it. I opened an issue too but can't find it right now. Anyway, so the idea is that most social providers need some soft of configuration from the Admin. Today, we enable them by default, but they don't work by default. I think we could make both sides happy if we were to just not show the social providers that aren't configured. What do others think? Only two providers that I know of in Mailman's default list, which don't need any configuration, are Fedora and OpenID. I am happy to remove OpenID from default since I have never been able to actually get that to work. I am okay with removing Fedora too, which is a special case in Mailman 3 because of fedoralists.org being the first customer for Mailman 3 and Hyperkitty. I don't have cycles to do that myself right now, so I would encourage people to step up to tackle this. I would obviously help them out with any Python, Mailman or Django related questions they might have. Now, about the ease of being able to disable social logins, I think it should be possible to disable social logins with just a boolean flag in settings. Why haven't we done it yet? We didn't need to. What we provided was a **sample configuration**, with a huge emphasis on sample. We weren't maintaining it as an official set of configurations, but just something that one could use as a starting point. But that obviously didn't happen since people just downloaded and used it, some of which is ofc my own fault since the official docs doesn't say that what precisely you should be worried about changing from the sample. The beauty (and ugliness) of Django's settings.py is that it is Python. We can disable social login if your CPU heats up[1], or if the stock price of the company goes below (or above? :P) a threshold, or heck, if the network firewall detects a packet heading out to their servers. How Django's configuration works has been left kind-of open by the Django devs themselves, making every downstream project handle their own use case separately. We chose to just go with what was provided out of box, but that doesn't mean we can't do any better. We can do ini-style configs, it gets a tad bit complicated when there are unknown Python data structures that can't easily be represented in ini-style. We could do YAML, which supports more complicated data structures (nested maps and lists). OR, we could do JSON, but I find that less human readable. Next topic, people worrying about customizing settings in settings_local.py and worrying about not getting newer updates. Isn't this how rest of the packaging and configuration world works? If you customize the `/etc/postfix/main.cf` you don't get the updates to default config (apt asks you, but you will choose not to update with your custom settings, right?) when you upgrade your postfix package from Debian and you need to pull in any new settings that package supports manually. I have been (silently) working[2] on making the `mailman_suite` project a Python package (mailman3-web), like the Debian Maintainers did. That would be the right place to put whatever configuration logic we want to expose to our users. We can move to a model where you'd import all the settings from `mailman3_web.settings.base` and then customize all the fields that you do care about. But there will be downsides to it, like us updating a setting that changes the behavior of an already working site, and we can sure document those changes in release notes in big bold letters, but I still worry there will be people running `pip install -U` without thinking what does that even mean. I don't know what should we do? What do other people managing configurations do? Maybe Debian Maintainers can chime in here? [1]: https://xkcd.com/1172/ [2]: https://gitlab.com/maxking/mailman-suite/commits/master On Fri, Feb 15, 2019, at 8:43 AM, Mark Sapiro wrote: > 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 issue is that unlike mm_cfg.py and > Defaults.py in Mailman 2.1, the recommended way to set up Django in > Mailman 3 is to point Django at settings.py for the default config, and > the last thing in settings.py is > > try: > from settings_local import * > except ImportError: > pass > > Thus,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. > > 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. > > 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. > > -- > 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/ > -- thanks, Abhilash Raj (maxking)

7 years, 6 months

[MM3-users] Re: Permission denied for fulltext_index

by Jan Eden

On 2022-11-30 10:22, Mark Sapiro wrote: > On 11/30/22 08:41, Jan Eden via Mailman-users wrote: > > > > Changing the PATH value to a full path (/opt/mailman/fulltext_index) > > and restarting mailman-web generates a different error: > > > Yes, it should be a full path. I encountered yet another problem with emails not getting archived anymore: > ERROR 2022-12-01 09:18:00,111 1337915 hyperkitty.views.mailman Access to the archiving API endpoint was forbidden from IP XXX.XXX.XXX.XXX, your MAILMAN_ARCHIVER_FROM setting may be misconfigured where XXX.XXX.XXX.XXX is my server's public IP. This was probably caused by the switch to uwsgi_pass/a file socket, and could be fixed by adding MAILMAN_ARCHIVER_FROM = ('XXX.XXX.XXX.XXX', '::1') to /etc/mailman3/settings.py. > > > ERROR 2022-11-30 16:38:37,953 1028315 django.request Internal Server Error: /archives/list/testing@lists.eden.one/thread/T6MCILAVQYV5QIOGHJB3JNJ26Z7E2Z35/reattach-suggest > > > Traceback (most recent call last): > > > File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/handlers/exception.py", line 55, in inner > > > response = get_response(request) > > > File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/handlers/base.py", line 197, in _get_response > > > response = wrapped_callback(request, *callback_args, **callback_kwargs) > > > File "/opt/mailman/venv/lib/python3.10/site-packages/hyperkitty/lib/view_helpers.py", line 137, in inner > > > return func(request, *args, **kwargs) > > > File "/opt/mailman/venv/lib/python3.10/site-packages/hyperkitty/views/thread.py", line 454, in reattach_suggest > > > sugg_thread = msg.object.thread > > > AttributeError: 'NoneType' object has no attribute 'thread' > > > This says that searching the archive for this list for messages matching the > current message subject returns None. It is probably a bug that we don't > test for this, but what exactly are you doing? > See the post at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > for the only way I've been able to create an error like this. There are currently 5 (test) threads in the archive. After changing the PATH in the HAYSTACK_CONNECTIONS dict to /opt/mailman/fulltext_index, and fixing the issue with MAILMAN_ARCHIVER_FROM above, /opt/mailman/web/logs/mailmanweb.log does not display new error messages, but I do not get any suggestions for reattaching threads, and a search for a specific thread subject ("Third test") does not return any results. So reattachment works in principle, but the suggest/search function does not. - Jan

3 years, 9 months

[MM3-users] Re: Errors while importing mm2 list archives - SOLVED

by Odhiambo Washington

On Tue, Dec 20, 2022 at 8:32 PM Mark Sapiro <mark(a)msapiro.net> wrote: > On 12/20/22 06:48, Odhiambo Washington wrote: > > > > There is a WARNING on > > > https://docs.list.org/en/latest/install/virtualenv.html#virtualenv-install > > which says one must create the config file as /etc/mailman3/mailman.cfg > > How to force mailman to read that file is something I haven't understood, > > but turns out to be what has taken me days trying to get things right. > > > If you run the `mailman` command without any -C option, it will look for > a config in /etc/mailman3/mailman.cfg > In my case, running `mailman` without any arguments just makes it grok :) (venv) [mailman@gw ~/mm]$ mailman info GNU Mailman 3.3.7 (Tom Sawyer) Python 3.9.15 (main, Dec 6 2022, 09:25:59) [Clang 13.0.0 (git@github.com:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a *config file: /opt/mailman/mm/mailman.cfg* db url: mysql+pymysql://mailman_user:XXXXXXXX@localhost /mailman3db?charset=utf8mb4&use_unicode=1 devmode: DISABLED REST root url: https://localhost:8001/3.1/ REST credentials: restadmin:restpass (venv) [mailman@gw ~/mm]$ mailman Usage: mailman [OPTIONS] COMMAND [ARGS]... The GNU Mailman mailing list management system Copyright 1998-2018 by the Free Software Foundation, Inc. http://www.list.org Options: --version Show the version and exit. --run-as-root Running mailman commands as root is not recommended and mailman will refuse to run as root unless this option is specified. -C, --config FILE Configuration file to use. If not given, the environment variable MAILMAN_CONFIG_FILE is consulted and used if set. If neither are given, a default configuration file is loaded. -h, --help Show this message and exit. .... > Ultimately, when I did the import, there was only one email from the > > archives that failed to be imported - which I honestly don't mind, but > > maybe there is a solution for this > > "'utf-8' codec can't encode character '\udcae' in position 331: > surrogates > > not allowed" ?? > > > If you provide a copy of that message from the mbox, either on the list > or to me directly, I'll investigate. > A mbox file containing that email and the associated thread can be downloaded from here: https://webmail.kictanet.or.ke/~wash/chunk_7.txt.gz -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)

3 years, 8 months

Search results for query "sapiro"