Search results for "Postorius" - Mailman-users

Re: Emergency Moderation

by Allan Hansen

> On May 24, 2020, at 11:34 , Mark Sapiro <mark(a)msapiro.net> wrote: > > On 5/24/20 10:59 AM, Allan Hansen wrote: >> In the MM3 settings there is an option to ‘Hold for moderation’ when members or non-members post to the list. >> I use that for the same cases where in MM2 I switched a list to ‘Emergency Moderation.’ > > > If you imported your MM 2.1 lists with `mailman import21`, `emergency` > was set appropriately for the imported list and should be working to > hold posts regardless of other settings. Not sure what is the difference between ‘emergency moderation’ and ‘Hold for moderation.’ It appears redundant. > > >> My own current top-of-the-list issues: >> >> A bug: Moderators can’t see/edit the list of members even when allowed to by list setting. > > The visibility issue is <https://gitlab.com/mailman/postorius/-/issues/369>. > > Editing membership beyond what could be done via the admindb interface > (i.e. clearing a moderated poster's mod flag) was never allowed for a > moderator in MM 2.1. > > In MM 3, a moderator can set a member's moderation when handling a held > post. Do you think a non-owner moderator should be able to make other > changes to a member? I can only speak for my own application of MM3: Desiring consistency between the lists, I don’t want to turn all the moderators into owners who can change list settings. Many of my moderators keep asking me to see the list of members and to subscribe and remove members. I end up servicing those requests. So... a. Moderators should be able to unsubscribe and subscribe members. b. Moderators should be able to set the member’s moderation status. c. Moderators should not be able to see/modify any other member settings. > > >> A feature request: Member changing email address on all lists he/she belongs to, without involving moderators. > > > This is <https://gitlab.com/mailman/postorius/-/issues/399> and we're > working on it. Awesome!!!! Thank you, Allan > > -- > 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/

4 years, 6 months

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

4 years, 5 months

UnicodeEncodeError: 'ascii' codec can't encode character

by Marvin Gülker

Hi, I've accidentally sent from an unregisted address to one of my lists. Mailman correctly held the message back for moderation, but when I go to the page for held messages in postorios, I receive a 500 error. I've included an except from the log below. To me, it looks as if it errors on processing my last name (which has a non-ascii character in it). This is Postorius 1.1.2 on Ubuntu 18.04 LTS from the repos. I've searched on the tracker for the problem and found one ticket[1], but it has something with logging so I suppose this is a different problem. Ideas? And how do I discard the message without access to the held messages page? Python version is 3.6.8. Log excerpt: Dec 09 13:21:04 2019 (3090) REST request handler error: Traceback (most recent call last): File "/usr/lib/python3.6/wsgiref/handlers.py", line 137, in run self.result = application(self.environ, self.start_response) File "/usr/lib/python3/dist-packages/mailman/database/transaction.py", line 50, in wrapper rtn = function(*args, **kws) File "/usr/lib/python3/dist-packages/mailman/rest/wsgiapp.py", line 214, in __call__ return super().__call__(environ, start_response) File "falcon/api.py", line 215, in falcon.api.API.__call__ (falcon/api.c:2872) File "falcon/api.py", line 189, in falcon.api.API.__call__ (falcon/api.c:2419) File "/usr/lib/python3/dist-packages/mailman/rest/post_moderation.py", line 167, in on_get resource = self._make_collection(request) File "/usr/lib/python3/dist-packages/mailman/rest/helpers.py", line 159, in _make_collection for resource in collection] File "/usr/lib/python3/dist-packages/mailman/rest/helpers.py", line 159, in <listcomp> for resource in collection] File "/usr/lib/python3/dist-packages/mailman/rest/post_moderation.py", line 157, in _resource_as_dict resource = self._make_resource(request.id) File "/usr/lib/python3/dist-packages/mailman/rest/post_moderation.py", line 78, in _make_resource resource['msg'] = msg.as_string() File "/usr/lib/python3.6/email/message.py", line 158, in as_string g.flatten(self, unixfrom=unixfrom) File "/usr/lib/python3.6/email/generator.py", line 116, in flatten self._write(msg) File "/usr/lib/python3.6/email/generator.py", line 181, in _write self._dispatch(msg) File "/usr/lib/python3.6/email/generator.py", line 214, in _dispatch meth(msg) File "/usr/lib/python3.6/email/generator.py", line 243, in _handle_text msg.set_payload(payload, charset) File "/usr/lib/python3.6/email/message.py", line 315, in set_payload payload = payload.encode(charset.output_charset) UnicodeEncodeError: 'ascii' codec can't encode character '\ufffd' in position 269: ordinal not in range(128) Dec 09 13:21:04 2019 (3090) 127.0.0.1 - - "GET /3.0/lists/tsc-devel(a)lists.secretchronicles.org/held?count=10&page=1 HTTP/1.1" 500 59 -- Blog: https://mg.guelker.eu

4 years, 11 months

Run 'manage.py makemigrations' to make new migrations

by christopher.claus＠tgcamberg1848.de

Hello together, at startup of my docker-container with mailman 0.4.3 i got some warnings to apply some data-model-migrations. I´m very unfamilar with python and django and be not sure how to handle it. Are these warnings from mailman and should i migrate the data-model (and how)? Or should i ignore these message for keeping mailman in a safe state? Best regards, chrclaus System check identified some issues: WARNINGS: django_mailman3.MailDomain: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the DjangoMailman3Config.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. django_mailman3.Profile: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the DjangoMailman3Config.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.Attachment: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.Email: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.Favorite: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.LastView: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.MailingList: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.Profile: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.Tag: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.Tagging: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.Thread: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.ThreadCategory: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. hyperkitty.Vote: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. postorius.EmailTemplate: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the PostoriusConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. Operations to perform: Apply all migrations: account, admin, auth, contenttypes, django_mailman3, django_q, hyperkitty, postorius, sessions, sites, socialaccount Running migrations: No migrations to apply. Your models in app(s): 'postorius' have changes that are not yet reflected in a migration, and so won't be applied. Run 'manage.py makemigrations' to make new migrations, and then re-run 'manage.py migrate' to apply them.

2 years, 4 months

Re: Turn off social logins?

by Stephen J. Turnbull

Note: I've changed the order of sentences from Torge's post to fit my responses. Torge Riedel writes: > I do agree, same here on my side. Lot's of my users are very > "sensitive" to social media and don't want see them here. This is the first I've heard of this. Obviously it's fairly widespread; *please* speak up if anyone have similar issues that we haven't addressed. AFAIK all of the currently active Mailman developers believe that social auth is a GoodThang[tm], so we're unlikely to DTRT as you see it without your help. > I need to migrate from mailman2 to mailman3 and was wondering why > social accounts are enabled by default By default Mailman 3 is social media: you have a profile, you can be searched in the indicies of the archives, and so on. The large auth providers provide more secure authentication, and a lot of convenience for users who have such accounts already. They also take some administrative burden off the list and site managers when people lose their passwords and forget what their subscription address is, and similar scenarios. Clearly, these are not universally-valued features, but I think that they justify the current defaults. > and are difficult to disable. They're easy enough to disable (easy to recognize and just add a hash character in front), since you have to edit settings_local.py to install anyway. If you're using a packaged version and the package configuration utility doesn't handle it, there's nothing we can do about it. The distro will have to deal with that. It should be better documented, I imagine (haven't checked yet). > I propose something like an additional setting listing the enabled > social accounts. Do you mean in the Postorius administration interface? If so, do you want it by-site, by-domain, or by-list? ("You" is everybody who wants to disable social auth, not just Torge!) If you mean in settings_local.py, I suggested something similar earlier. It's not obvious it would be easy to do (sometimes these things are order-dependent, though that's bad practice). > And if the admin is setting this to an empty value in the > settings_local.py everything is disabled Because the settings are a Python module, this is the way settings_local.py works anyway. That's why Mark suggested editing INSTALLED_APPS.

5 years, 9 months

Re: moving lists to another server

by Odhiambo Washington

On Mon, Nov 20, 2023 at 8:53 PM Mark Sapiro <mark(a)msapiro.net> wrote: > On 11/20/23 00:58, Odhiambo Washington wrote: > > > > 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'. > > Normally you do this on the old server via the HyperKitty web UI which > has download buttons which do things like > > > https://example.com/archives/list/list@example.com/export/list@example.com.… > > or for a partial archive > > > https://example.com/archives/list/list@example.com/export/list@example.com-… > > However, in your case I don't think you have the old installation working > any more so the above won't help. > I had a dump of the old installation actually - both databases. The above has actually helped and I obtained the archive. > > BTW, how will ' mailman addmembers' treat a file containing: > > ``` > > Firstname Lastname <email@address> > > Onlyname <email2@address> > > ``` > > Correctly. It will import email@address with display name = 'Firstname > Lastname' and email2@address with display name = 'Onlyname'. > Super! > > 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. > > Perhaps you can export the mbox via the web UI on the old server or > maybe temporarily create a second mailman-web on your server with the > old mailman-web database and use that web UI. That's exactly how I did it and got the archives. > Otherwise, if you have a working mailman-web that can access this > database, you could try > something like > ``` > $ mailman-web shell > > >>> from hyperkitty.lib.compat import get_list_by_name > >>> mlist = get_list_by_name('list_name_only', 'list_domain') > >>> with open('output.mbox', 'wb') as fp: > ... for email in mlist.emails.order_by("archived_date").all(): > ... fp.write(email.as_bytes() + b'\n') > ... > >>> > ``` > I tested the above out of curiosity. It failed. There are 9 lists in the setup, but I am only interested in 1. ``` (venv) mailman@debian12:~$ mailman-web shell Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] Type 'copyright', 'credits' or 'license' for more information IPython 8.17.2 -- An enhanced Interactive Python. Type '?' for help. In [1]: from hyperkitty.lib.compat import get_list_by_name In [2]: mlist = get_list_by_name('list_name_only', 'list_domain') --------------------------------------------------------------------------- Http404 Traceback (most recent call last) Cell In[2], line 1 ----> 1 mlist = get_list_by_name('list_name_only', 'list_domain') File ~/venv/lib/python3.11/site-packages/hyperkitty/lib/compat.py:37, in get_list_by_name(list_name, domain) 35 matching = list(MailingList.objects.filter(name__startswith=list_name+"@")) 36 if len(matching) == 0: # no candidate found ---> 37 raise Http404("No archived mailinglist by that name") 38 if len(matching) == 1: # only one candidate 39 return matching[0] Http404: No archived mailinglist by that name ``` Was I supposed to substitute something for the real listname of the list I wanted? Another thing - totally unrelated - that surprised me: While using the commented-out block below, I could not click and get anything beyond http://http://list.name/mailman3 as anything to do with /postorius/xxxxx gave "Page not found" error. However, with the second config block that uses the UNIX socket, I am able to access everything ``` #<IfModule mod_proxy.c> # ProxyPreserveHost On # ProxyPass "/mailman3" "http://127.0.0.1:8010/mailman3" # ProxyPass "/archives" "http://127.0.0.1:8010/archives" # ProxyPass "/accounts" "http://127.0.0.1:8010/accounts" # ProxyPass "/admin" "http://127.0.0.1:8010/admin" # ProxyPass "/user-profile" "http://127.0.0.1:8010/user-profile" # </IfModule> ProxyPassMatch ^/static/ ! ProxyPassMatch ^/favicon.ico ! ProxyPass / unix:/opt/mailman/mm/var/uwsgi.sock|uwsgi://localhost/ ProxyPassReverse / unix:/opt/mailman/mm/var/uwsgi.sock|uwsgi://localhost/ ``` Why is it that the UNIX socket option worked flawlessly while the other option failed??? -- 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]

1 year

Re: Cross-List and Domain based sender whitelisting ( accept_these_nonmembers )

by Abhilash Raj

On 9/8/21 3:39 PM, Patrick Brückner wrote: > Hi everyone, > > one of our servers that was running a mailman2 instance just crashed this afternoon, so we decided to take the leap and migrate to 3, and I have to say it worked pretty well, the lists seem to be back. > > What I can't seem to find is the option to whitelist senders based on a domain AND on membership on a different list. > > The lists are operated for a smallish university and all the professors need to be allowed to send to the students list, without being member of that list. That was possible with mailman2 by just whitelisting the university domain. > > Also, in the past we allowed all members of the all-students list to post to any of the dorm-lists (this is mainly used for party announcements so it is not a must have), but I wanted to ask anyways, if there was a chance to allow this feature again. > > According to the docs, the accept_these_nonmembers option exists (https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/…), but none of my lists have that set after the migration - the field is not even there when accessing the REST API. > > Do I need to enable something? Has that feature been added just recently, and we are missing out (since we are using the apt packages from ubuntu)? You are probably on an old version of Mailman which didn't expose the values in API and also Postorius didn't expose it in UI. You can install a new version manually by downloading new debs from Debian unstable repos (I don't know if Ubuntu just copies the ones from Debian or has their own packaging, I think it is former) that have newer built debs. On your version, you probably would be able to set the accept_these_nonmembers using the command line using ``` mailman withlist -l test(a)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 test(a)example.com mailing list >>> m.accept_these_nonmembers ['*.example.com'] >>> m.accept_these_nonmembers = [r'*.example.com'] >>> commit() >>> quit() ``` -- thanks, Abhilash Raj (maxking)

3 years, 2 months

Re: How To Install Mailman 3 on Debian 10 (Complete Guide)

by Abhilash Raj

On Thu, Feb 25, 2021, at 3:55 PM, Brian Carpenter wrote: > https://wiki.list.org/DOC/Howto_Install_Mailman3_On_Debian10 Thanks Brian, this looks quite comprehensive in the details. The only thing I am a bit concerned about is granting sudo privileges to the Mailman user. It really shouldn't have sudo given that Mailman and Django are supposed to run as mailman user. Any compromise of the Django application will provide the attacker root on the machine. On Thu, Feb 25, 2021, at 3:55 PM, Brian Carpenter wrote: > I have finished my how-to install Mailman 3 on Debian 10 completed to > the point where you can use it to get a fully functional Mailman 3 > environment up and running. This is a comprehensive guide that walks you > through installing EVERYTHING (currently!) that Mailman 3 needs to run. > It also makes updating Mailman 3/Postorius/Hyperkitty very easy. I have > not added the update directions yet but will very soon. I also plan on > adding a section on setting up DKIM and Xapian with Mailman 3. > > I hope this helps those who wish to get a Mailman 3 server up and > running quickly and brings a sense of sanity to the confusion regarding > the various documentation out there concerning the installation of > Mailman 3/Postorius/Hyperkitty. I intend to add a How-to for Ubuntu 20 > at some point. This really does remind me of https://xkcd.com/927/. Is there a specific reason that you chose to go with an entirely new doc rather than helping to improve the existing one? Several parts of it (at least the ones that official guide covers) seems similar to me and is duplicate information that at least two people are going to spend time writing and maintaining in future. Is it something about the contribution process to the official documentation that makes it hard for people to contribute? Most of the pages at docs.mailman3.org or come from this[1] repo and use Sphinx to build and REsT formatting (.rst). [1]: https://gitlab.com/mailman/mailman-suite-doc I am just trying to understand how can we lower the barrier for community members to help contribute to existing docs instead of them having to create new ones. Specifically around installation, since that tends to get stale often when depedent packages change or a new dependency is added that breaks the installation. -- thanks, Abhilash Raj (maxking)

3 years, 9 months

Request for help debugging a hyperkitty connection issue

by Stephen Daniel

Mailman folk -- I've recently completed a complete install of the mailman3 suite on a Debian VM in Google Cloud (GCP). I used the excellent directions given here: https://wiki.list.org/DOC/Howto_Install_Mailman3_On_Debian10 Most things appear to work. Postorius is working, and I can create accounts, email lists, etc. I have two problems. One is with getting list mail out of GCP. I am working on that. The issue I don't know how to address is a problem with hyperkitty. Nothing is being archived. When I send an email through my test list, this message shows up in the mailman log: Jan 04 11:57:26 2022 (806) Exception in "hyperkitty" archiver Traceback (most recent call last): File "/opt/mailman/mm/venv/lib/python3.7/site-packages/urllib3/connection.py", line 175, in _new_conn (self._dns_host, self.port), self.timeout, **extra_kw File "/opt/mailman/mm/venv/lib/python3.7/site-packages/urllib3/util/connection.py", line 73, in create_connection for res in socket.getaddrinfo(host, port, family, socket.SOCK_STREAM): File "/usr/lib/python3.7/socket.py", line 748, in getaddrinfo for res in _socket.getaddrinfo(host, port, family, type, proto, flags): socket.gaierror: [Errno -2] Name or service not known This triggers a bunch more tracebacks. Then I get this: Jan 04 11:57:27 2022 (797) Connection to HyperKitty failed: HTTPSConnectionPool(host='www.XXXXX.dev <http://www.xxxxx.dev/>', port=443): Max retries exceeded with url: /archives/api/mailman/archive (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f2114e14e10>: Failed to establish a new connection: [Errno -2] Name or service not known')) Jan 04 11:57:27 2022 (797) Exception in the HyperKitty archiver: HTTPSConnectionPool(host='www.XXXXX.dev <http://www.xxxxx.dev/>', port=443): Max retries exceeded with url: /archives/api/mailman/archive (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f2114e14e10>: Failed to establish a new connection: [Errno -2] Name or service not known')) Jan 04 11:57:27 2022 (797) Traceback (most recent call last): File "/opt/mailman/mm/venv/lib/python3.7/site-packages/urllib3/connection.py", line 175, in _new_conn (self._dns_host, self.port), self.timeout, **extra_kw File "/opt/mailman/mm/venv/lib/python3.7/site-packages/urllib3/util/connection.py", line 73, in create_connection for res in socket.getaddrinfo(host, port, family, socket.SOCK_STREAM): File "/usr/lib/python3.7/socket.py", line 748, in getaddrinfo for res in _socket.getaddrinfo(host, port, family, type, proto, flags): socket.gaierror: [Errno -2] Name or service not known I think this second error is just mailman3 reporting that it had trouble with hyperkitty because of the first error. How can I get more information about what connection is being attempted when this failure occurs? Thanks! -- Stephen Daniel

2 years, 10 months

Re: Archive search failing on one list

by Stephen J. Turnbull

Mark writes: > as I kept getting an error when starting:� > > #django-admin shell > >>> from hyperkitty.models.mailinglist import MailingList > ... > django.core.exceptions.ImproperlyConfigured ... This suggests to me that you have multiple versions of Python and/or Django installed. This is an advantage of using a venv -- once activated, you are much more likely to get a well-defined, consistent set of utilities and libraries. By the way, does that # prompt mean you are logged in as root while you're working with Mailman? That is inadvisable, as if you change anything there is a chance that root will be the owner of the file, and the list user will not be able to work with it. Also, if you have mailman-web installed, I recommend using that rather than django-admin or python3 manage.py. Each Django application may have its own copy of django-admin (not usually, but I've seen it happen) and definitely will have its own copy of manage.py. mailman-web knows how to work with both HyperKitty and Postorius without getting confused about that. > Does this (missing list_id) give any clue as to why the > archive-search isn't working, or is just that starting with "# > python3 manage.py shell" is the wrong thing to do? If all you're doing is querying the database, it doesn't really matter how you do this. If you get the right copies of python3, django-admin, and manage-py it's all just going to work. It doesn't matter which utility you start with, it all ends up going through the same Django modules in the end. The process of search index construction is both CPU and wall-clock time intensive. For this reason, the cron jobs that do regular index updating (I think once an hour?) are separate from the utility that constructs the index in the first place when you have existing archives (either migrated from another MLM such as Mailman 2, or if you're upgrading to better archive software). Is it possible that you have most of a bunch of migrated archives indexed because the migration process did it, but that the periodic update process (like cron jobs, but actually run by the Django queue task manager IIRC) is not running, so no new posts are being archived? That fits the symptoms you described so far (that I recall). Steve

1 year, 1 month

Mailman-users search results for query "Postorius"