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

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

by Danil Smirnov

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… 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/ >

7 years, 5 months

[MM3-users] Re: Cannot Run Web Frontend

by Mark Sapiro

On 12/26/25 08:02, dap1--- via Mailman-users wrote: > SELECT name FROM hyperkitty_mailinglist; > +--------------------------+ > | name | > +--------------------------+ > | lllllllll(a)ddddddddd.net | > | lllllllll(a)gmail.com | > +--------------------------+ > 2 rows in set (0.00 sec) > > It seems just deleting lllllllll(a)ddddddddd.net is non-trivial. > Cannot delete or update a parent row: a foreign key constraint fails (`mailmanweb`.`hyperkitty_email > `, CONSTRAINT `hyperkitty_email_mailinglist_id_2c2b6f03_fk_hyperkitt` FOREIGN KEY (`mailinglist_id`) REFERENCES `hyperki > tty_mailinglist` (`id`)) This is not a critical issue so you can just ignore it until you get the web UI working at which time a Django superuser or the list owner can delete the list in HyperKitty's web UI. If you want to do it in the database, I think you can first do DELETE FROM hyperkitty_attachment WHERE hyperkitty_attachment.email_id IN (SELECT id FROM hyperkitty_email WHERE hyperkitty_email.mailinglist_id IN (SELECT id FROM hyperkitty_mailinglist WHERE hyperkitty_mailinglist.name = 'lllllllll(a)ddddddddd.net')); to delete attachments and then do DELETE FROM hyperkitty_email WHERE hyperkitty_email.mailinglist_id IN (SELECT id FROM hyperkitty_mailinglist WHERE hyperkitty_mailinglist.name = 'lllllllll(a)ddddddddd.net'); to delete the emails and finally DELETE FROM hyperkitty_mailinglist WHERE hyperkitty_mailinglist.name = 'lllllllll(a)ddddddddd.net'; But this may possibly run into other foreign key constraint issues. It's probably easier to get the web UI up and do it there. > netstat -lntp > Active Internet connections (only servers) > Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name > tcp 0 0 127.0.0.54:53 0.0.0.0:* LISTEN 1103/systemd-resolv > tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 1407/mysqld > tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 1644/smbd > tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 1644/smbd > tcp 0 0 127.0.0.1:8001 0.0.0.0:* LISTEN 74794/python3 > tcp 0 0 127.0.0.1:8024 0.0.0.0:* LISTEN 74791/python3 > tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 1103/systemd-resolv > tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 74696/master > tcp 0 0 0.0.0.0:26 0.0.0.0:* LISTEN 1/init > tcp 0 0 127.0.0.1:33060 0.0.0.0:* LISTEN 1407/mysqld > tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 160003/cupsd > tcp6 0 0 :::443 :::* LISTEN 132763/apache2 > tcp6 0 0 :::445 :::* LISTEN 1644/smbd > tcp6 0 0 :::139 :::* LISTEN 1644/smbd > tcp6 0 0 :::80 :::* LISTEN 132763/apache2 > tcp6 0 0 :::25 :::* LISTEN 74696/master > tcp6 0 0 :::26 :::* LISTEN 1/init > tcp6 0 0 ::1:631 :::* LISTEN 160003/cupsd > > I'm not using IPV6. Nothing is listening on 8000, just 8001 and 8024. > > It appears that guicorn is not running if there is supposed to be a process by that name. There is also no such service. See https://docs.mailman3.org/en/latest/install/virtualenv.html#automatically-s… Particularly the part that says: If using Gunicorn, the ExecStart line above becomes: ExecStart=/opt/mailman/venv/bin/gunicorn -c /etc/mailman3/gunicorn.conf mailman_web.wsgi:application Do you have that and is the mailmanweb service running? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 months, 3 weeks

[MM3-users] Re: config incoming email in my domain cpanel

by Rafael Mora

El jue., 3 ago. 2017 a las 14:48, Mark Sapiro (<mark(a)msapiro.net>) escribió: > On 08/03/2017 12:15 PM, Rafael Mora wrote: > > > > Should I configure my private Centos7 server with subdomain > > lists.labbrands.com? > > Doing so how do I redirect the email to the private Centos where postfix > > and MM3 are installed? > > > Create a DNS A record for lists.labbrands.com with the IP of the Mailman > server. You will also want a rDNS PTR record pointing from the IP to > lists.labbrands.com. > Does the rDNS PTR record should be placed in my Centos7 server? I've created the DNS A record for lists.labbrands.com with the IP but I don't know the port that it uses so I can make a port redirect to my local ip address wich is 192.168.1.42, do you know the port????? > > -- > 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 > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > -- Atentamente / Best Regards Ing. Rafael Mora

9 years

[MM3-users] Re: Mailman will not restart

by Christian

Yes, thank you Mark & Peter. I did that and also eliminated locks that were appearing and it is now working. -----Original Message----- From: Mark Sapiro <mark(a)msapiro.net> Sent: Wednesday, March 8, 2023 3:10 PM To: mailman-users(a)mailman3.org Subject: [MM3-users] Re: Mailman will not restart On 3/8/23 12:34, peter(a)chubb.wattle.id.au wrote: >>>>>> "Christian" == Christian via Mailman-users <mailman-users(a)mailman3.org> writes: > > Christian> , line 36, in <module> Mar 08 20:17:45 > Christian> zarathustra.ccalternatives.org mailman[31893]: from > Christian> typing_extensions import Concatenate as Concatenate # 3.10 > > You probably need to update the typing_extensions package. inside your > venv. Yes, but why? Something upgraded sqlalchemy > 2.0 but didn't install all its dependencies. The latest versions of sqlalchemy require typing-extensions but sqlalchemy<2.0 didn't require that. So in the venv, `pip install typing-extensions` will probably solve this. -- 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/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/ 2SXACQYNAHYSUYY4G33PQQDJKKAIBZZM/ This message sent to csa(a)web-analysts.net

3 years, 5 months

[MM3-users] Re: Mail control not given from Mailman 3 to postfix

by Mark Sapiro

To follow up, I received the traceback and the dump of the shunted message off-list. The traceback is ``` Jul 07 21:36:47 2020 (26815) Uncaught runner exception: sequence item 0: expected str instance, Header found Jul 07 21:36:47 2020 (26815) Traceback (most recent call last): File "/var/lib/mailman/mailman/src/mailman/core/runner.py", line 173, in _one_iteration self._process_one_file(msg, msgdata) File "/var/lib/mailman/mailman/src/mailman/core/runner.py", line 266, in _process_one_file keepqueued = self._dispose(mlist, msg, msgdata) File "/var/lib/mailman/mailman/src/mailman/runners/pipeline.py", line 37, in _dispose process(mlist, msg, msgdata, pipeline) File "/var/lib/mailman/mailman/src/mailman/core/pipelines.py", line 50, in process handler.process(mlist, msg, msgdata) File "/var/lib/mailman/mailman/src/mailman/handlers/avoid_duplicates.py", line 59, in process addrs = getaddresses(msg.get_all(header, [])) File "/usr/lib64/python3.6/email/utils.py", line 112, in getaddresses all = COMMASPACE.join(fieldvalues) TypeError: sequence item 0: expected str instance, Header found Jul 07 21:36:47 2020 (26815) SHUNTING: 1594138007.5613732+1a5932f41fb4cfcd18c9b0b0ac6f999c84408577 ``` This was apparently caused by an invalid RFC 2047 encoded To: header which encoded the entire header including the address as one base64, unknown-8bit character set encoded word. However, despite trying with several different Python versions, I was unable to recreate the TypeError, so the reason for this exception remains unknown.

6 years, 1 month

[MM3-users] Re: UnpicklingError on mailman lists command

by Mark Sapiro

On 8/3/21 7:35 AM, Bryan Loniewski wrote: > Okay, that helped identify possible culprits. Three of our lists are hitting/over the max BLOB length (65,535 bytes) for accept_these_nonmembers. I executed this SQL command for each of the BLOB cols you referenced and only accept_these_nonmembers is borked: > > MySQL [mailman]> SELECT list_name, OCTET_LENGTH(accept_these_nonmembers) as howManyBytes from mailinglist where OCTET_LENGTH(accept_these_nonmembers) > 64000; > +---------------+--------------+ > | list_name | howManyBytes | > +---------------+--------------+ > | <snip> | 65535 | > | <snip> | 65535 | > | <snip> | 65535 | > +---------------+--------------+ > 3 rows in set (0.01 sec) > > So, putting aside *why* these lists are so large wrt that column, can or should I alter the col type(s) to MEDIUMBLOB? If yes, would that remain on suite upgrades? If no, is there a better alternative? Or some recommendation in between? Modifying the column type at this point will not help because the data has already been truncated and the missing piece is gone. It may help avoid future issues, but I suspect it's not necessary. It would probably 'stick' on an upgrade as long as there were no new migration affecting those columns, but if there were such a migration, it could fail due to the existing type not being as expected. I suspect these lists were imported from Mailman 2.1 with the `mailman import21` command. The goal of that is to import the addresses as non-members with the appropriate action and put only the regexps in the MM 3 *_these_nonmembers. Prior to Mailman 3.3.2, import21 would add the entire 2.1 *_these_nonmembers and then delete the non-regexps. Possibly something went wrong in that process because of the truncation and left the new *_these_nonmembers in a broken state. Or possibly you just have a huge number of regexps in these list's accept_these_nonmembers. I suggest you use mysql to update this column's data for these three lists. to a value which unpickles as an empty list. This value is the python bytes b'\x80\x04\x5d\x94\x2e' (i.e. 5 bytes with hex values 80, 04, 5d, 94 and 2e). I'm not sure how that is stored in a MySQL BLOB, but I'm sure you can determine that. This will allow you to actually access those lists in Mailman. Also note that beginning with Postorius 1.3.3, the *_these_nonmembers settings are exposed on the List Settings -> Message Acceptance form. If you still have the original MM 2.1 config.pck files, you can examine them with Mailman 2.1's bin/dumpdb command to see what was in accept_these_nonmembers, and then see if the appropriate MM 3 nonmembers were created and if the remaining regexps are not too long, add them. If you need help with this, I will help. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years

[MM3-users] Re: Splitting hosts: mta&core vs postorius

by Mark Sapiro

On 6/20/20 1:37 PM, Ruth Ivimey-Cook wrote: > Thanks Mark, Ignore bracketed numbers below ([1], [2], etc.) They come from conversion of the HTML only post to plain text. > On 20/06/2020 03:53, Mark Sapiro wrote: > > What are your Django settings for MAILMAN_REST_API_URL, > MAILMAN_REST_API_USER and MAILMAN_REST_API_PASS and do these agree with > the [webservice] settings for hostname, port, use_https, admin_user and > admin_pass in mailman.cfg in core and is the port open to the outside on > the core machine? > > greyarea-post is the mailman-core and exim server. > > greyarea-web1 is the postorius and hyperkitty server. > > On greyarea-web1, in django-settings.py, > > MAILMAN_REST_API_URL = '[1]http://greyarea-post:8870' > MAILMAN_REST_API_USER = 'restadmin' > MAILMAN_REST_API_PASS = XXXX > > and both the above-named hosts are also included in ALLOWED_HOSTS along > with localhost. > > On greyarea-post, in mailman.cfg: > > [webservice] > admin_pass: XXXXX > admin_user: restadmin > api_version: 3.1 > hostname: 0.0.0.0 > port: 8870 > use_https: no > > The password and username are as on web1. That all looks good. > Do you see REST requests from the Postorius machine in core's > mailman.log and access.log? > > Yes, there are lots of requests of the form: > > [07/Jun/2020:15:00:01 +0000] "GET /3.1/lists?count=10&page=1 > HTTP/1.1" 200 470 "-" "GNU Mailman REST client v3.3.1" > > I made a new list using the core CLI, and as a result of navigating > directly to the list archive page I get to see: > > [06/Jun/2020:23:00:02 +0000] "GET /3.1/lists/chbcdaily(a)ch-bc.org.uk > HTTP/1.1" 200 365 "-" "GNU Mailman REST client v3.3.1" > > ... but in neither case do I get a complete screen on the browser or > 'follow-up' requests. > > I don't have a file access.log on the greyarea-post. Yes, that's actually a gunicorn log so would only be on greyarea-web1, but the mailman.log tells us the requests are getting to the core REST API, so we don't need that info. > On the greyarea-web1 I have mailmansuite.log with the last few lines: > > File > "/opt/mailman3/lib/python3.6/site-packages/mailmanclient/restbase/ba > se.py", line 74, in rest_data > response, content = self._connection.call(self._url) > File > "/opt/mailman3/lib/python3.6/site-packages/mailmanclient/restbase/co > nnection.py", line 124, in call > 'Could not connect to Mailman API: ', repr(e)) > mailmanclient.restbase.connection.MailmanConnectionError: ('Could > not connect to Mailman API: ', > 'ConnectionError(MaxRetryError("HTTPConnectionPool(host=\'0.0.0.0\', > port=8870): Max retries exceeded with url: /3.1/domains/ch-bc.org.uk > (Caused by NewConnectionError(\'<urllib3.connection.HTTPConnection > object at 0x7f5416db8518>: Failed to establish a new connection: > [Errno 111] Connection refused\',))",),)') > ERROR 2020-06-03 01:02:06,115 29002 django.request Service > Unavailable: /postorius/lists/ OK. This is telling us that mailmanclient (the REST API Python bindings that Postorius uses to access core) is having trouble establishing a connestion to the core REST server, but it clearly gets there some of the time based on the mailman.log entries. > the uwsgi-error_*.log contains many lines of the form: > > api: url is > [2]http://greyarea-post.cam.ivimey.org:8870/3.1/lists?count=10&page= > 1 > api: url is > [3]http://greyarea-post.cam.ivimey.org:8870/3.1/lists?count=10&page= > 1 > > My reason for thinking, in my original post, that the wrong host > address is being used is that the ConnectionError above contains > 0.0.0.0 in its url for /3.1/domains/... but 0.0.0.0 is only present as > the listen address on the core web service and does not appear in the > config for postorius. The ConnectionError above comes from requests.request (docs at <https://requests.readthedocs.io/en/master/>). Client only provides a URL in the call to request and the URL is the baseurl + the path and the baseurl is MAILMAN_REST_API_URL which you have as http://greyarea-post:8870. Entries above have http://greyarea-post.cam.ivimey.org:8870/. Is that the correct FQDN? I suspect a DNS lookup issue. How does greyarea-web1 resolve greyarea-post? You could try a FQDN that greyarea-web1 can lookup in DNS rather than relying on /etc/resolv.conf and/or /etc/hosts. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 2 months

[MM3-users] Re: moving list from mm3 -> mm3

by Mark Sapiro

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

2 years, 8 months

[MM3-users] Re: Enable delivery

by Mark Sapiro

On 12/9/24 17:35, Hirayama, Pat wrote: > Greetings, > > I'm finding something a bit odd with our listserv. Please see https://wiki.list.org/DOC/Mailman%20is%20not%20Listserv > Some of the members of some of the lists are reporting that they aren't receiving messages sent to the list. When I review the member options for the person in question, I see that Delivery Status shows nothing selected (i.e. neither radio button is selected for Enabled or Disabled). If you look in the MTA logs is mail being sent to them. As far as the Delivery Status showing nothing, that means the member's delivery_status is None. The ultimate delivery status is determined by checking first the member's delivery_status, then the address's delivery_status, then the user's delivery_status and finally Mailman's global preferences. The first non-None value is what's used. See https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/model/member.p… Also see the various tabs at https://www.example.com/mailman3/accounts/subscriptions/ > If I select Enabled and Save, then delivery starts working for that user. This should only happen if the users address or user based preference or the global preference is Disabled. > There are other members of the list that have neither Enabled or Disabled selected, but they are working. Which also seems to mean that when I run: > > mailman members --nomail any listname@listserv > > Nothing is returned. Because all members ultimately have delivery enabled. > If anyone has any ideas about why this might be the case, or how I might proactively identify other members who aren't receiving mail, that would be appreciated. Alternately, any thoughts on how I might force all members to Delivery Status Enabled, that would also be great. It shouldn't be necessary to do that. For one of these members, e.g. user(a)example.com, that isn't getting mail, do this in mailman shell ``` mailman shell -l list(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 list(a)example.com mailing list >>> from mailman.core.constants import system_preferences >>> mbr = m.members.get_member('user(a)example.com') >>> print(mbr.delivery_status) (this will print the ultimate delivery_status, for the components do) >>> print(mbr.preferences.delivery_status) (output) >>> print(mbr.address.preferences.delivery_status) (output) >>> print(mbr.address.user.preferences.delivery_status) (output) >>> print(system_preferences.delivery_status) (output) >>> ``` The first of the (output) lines which is not None should be the same as the output from print(mbr.delivery_status). -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 8 months

[MM3-users] Re: Installing mailman 3

by Rafael Mora

ok, thanks Mark, I'm getting an error doing: (env) [mailman@localhost mailman-suite_project]$ python2 manage.py migrate Traceback (most recent call last): File "manage.py", line 8, in <module> from django.core.management import execute_from_command_line ImportError: No module named django.core.management What do you suggest?? El vie., 21 jul. 2017 a las 14:31, Mark Sapiro (<mark(a)msapiro.net>) escribió: > On 07/21/2017 12:07 PM, Rafael Mora wrote: > > Installing mailman-suite for web ui. I did this: > > > > (env) [mailman@localhost ~]$ git clone > > https://gitlab.com/mailman/mailman-suite/ > > Cloning into 'mailman-suite'... > > error: RPC failed; result=22, HTTP code = 404 > > fatal: The remote end hung up unexpectedly > > > > > > but it returned an error, what should I do?? > > > It's another case of incorrect docs. It should be > > git clone https://gitlab.com/mailman/mailman-suite.git > > See <https://gitlab.com/mailman/mailman-suite-doc/issues/15>. > > -- > 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 > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > -- Atentamente / Best Regards Ing. Rafael Mora

9 years

Search results for query "sapiro"