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

[MM3-users] Re: [Django] ERROR (EXTERNAL IP): Internal Server Error: /accounts/login/

by Mark Sapiro

On 5/18/21 4:06 PM, Mark Dadgar wrote: > I have a user attempting to access the list archives and he’s generating this login error. I have verified that he does have a django account. I’ve never seen this one before and I didn’t find anything relevant in the lit archives. > > Any ideas what’s going on here? ... > File "/opt/mailman/mm/venv/lib/python3.8/site-packages/allauth/account/utils.py", line 134, in _has_verified_for_login > emailaddress = EmailAddress.objects.get_for_user(user, email) > File "/opt/mailman/mm/venv/lib/python3.8/site-packages/allauth/account/managers.py", line 54, in get_for_user > ret = self.get(user=user, email__iexact=email) > File "/opt/mailman/mm/venv/lib/python3.8/site-packages/django/db/models/manager.py", line 82, in manager_method > return getattr(self.get_queryset(), name)(*args, **kwargs) > File "/opt/mailman/mm/venv/lib/python3.8/site-packages/django/db/models/query.py", line 419, in get > raise self.model.MultipleObjectsReturned( > > Exception Type: MultipleObjectsReturned at /accounts/login/ > Exception Value: get() returned more than one EmailAddress -- it returned 2! > Request information: > USER: AnonymousUser Go to the Django admin users page - something like http(s)://example.com/admin/auth/user/ - and search for the email address. This search is case-insensitive and I'm guessing it will find two users differing in case. In any event, django allauth is trying to find this user and is finding multiple EmailAddress.objects for this address or username. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 6 months

[MM3-users] Re: Hyperkitty

by Mark Sapiro

On 1/30/23 13:17, Onyeibo wrote: > > The mails don't have that header. I suspect I may have to investigate > SELinux. I think it's unlikely a SELinux issue unless you mean it's an issue writing the log, but if there are any entries at all in mailman.log, that should be OK. what does `mailman conf -s archiver.hyperkitty -k configuration` show? The default is `/etc/mailman3/mailman-hyperkitty.cfg`. Whatever it is, what's in that file. It should be something like ``` [general] base_url: http://127.0.0.1:8000/archives/ api_key: some_key ``` some_key needs to match ``` MAILMAN_ARCHIVER_KEY = 'some_key' ``` in /etc/mailman3/settings.py and the base_url setting needs to access hyperkitty. It could be as above or it could be the URL that accesses HyperKitty externally as in ``` base_url: http:://example.com/archives/ ``` Is all of that correct? To verify base_url, you can do ``` curl http://127.0.0.1:8000/archives/api/ ``` where the initial part of that is the base_url setting. That should return the html for a page of documentation. Look at https://gitlab.com/mailman/mailman-hyperkitty/-/blob/master/mailman_hyperki…. This is Mailman Core's interface to the archiver. If any of the methods there fail to connect to HyperKitty or get an appropriate response, they all log errors. In particular, the archive_message() method at line 171 is saving the message in the spool queue. Immediately before that at lines 164 and 167 it is writing log messages. You should be seeing them. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 10 months

[MM3-users] Re: troubleshooting hyperkitty

by Mark Sapiro

On 12/9/20 5:01 PM, Morris Jones wrote: > > did that as well ... > > base_url: https://mailman.whiteoaks.com/hyperkitty/ > > (Though the configuration comment on this suggests it should not be > publicly accessible, I don't see any alternative endpoint that's private.) The comments in mailman-hyperkitty/mailman-hyperkitty.cfg say in part # ... It does not need to be publicly available, in fact it's # better if it is not. but they add # However, if your Mailman installation is accessed via HTTPS, the URL needs # to match your SSL certificate (e.g. https://lists.example.com/hyperkitty) > I added both my public IP address and my domain name to > MAILMAN_ARCHIVER_FROM. > > So this part is all set, it would seem ... > > [archive.hyperkitty] > class: mailman_hyperkitty.Archiver > enable: yes > configuration: /opt/mailman/var/etc/mailman-hyperkitty.cfg > > [logging.archiver] > path: /opt/mailman/var/logs/archiver.log api_key What is api_key? Is your setting for api_key somehow garbled. Note it needs to be set in the general section of mailman-hyperkitty.cfg and not in mailman.cfg > My archiver log continues empty > > The API keys match in settings_local.py MAILMAN_ARCHIVER_FROM and > mailman-hyperkitty.cfg The key in settings_local.py is MAILMAN_ARCHIVER_KEY, not MAILMAN_ARCHIVER_FROM, a typo in your mail or ?? Anyway, in settings_local.py the key is a python string and must be quoted, but the api_key setting in mailman-hyperkitty.cfg is not quoted. -- 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: Wrong info in moderation mail when held due to match of a header rule

by Mark Sapiro

On 10/17/20 10:39 AM, Torge Riedel wrote: > > The message is being held because: > > Header "Yes" matched a header rule > > At your convenience, visit your dashboard to approve or deny the > request. > > I think this is wrong, it should read 'Header "x-spam" matched a header > rule'. Cause the header rule is configured for header "x-spam" and > pattern "Yes". The message is defined as 'Header "{}" matched a header rule' where {} is replaced with the value of the matching header. I agree it would be better if it were something like 'Header value "{}" matched a header rule for {}:' with {}s replaced with the header value and name. That would make it in your case 'Header value "Yes" matched a header rule for x-spam:' > I haven't found a bug report for this yet on gitlab. If someone of the > developers confirm this is wrong, I will file a bug on gitlab for it. Please do file a bug. It won't be fixed until after the upcoming 3.3.2 final release because we not making i18n changes between the candidate and final releases. Also, if you don't like my suggestion, feel free to suggest something else. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 1 month

[MM3-users] Re: Upgrade to 3.3.2 fails

by Mark Sapiro

On 12/26/20 11:28 AM, Joel Lord wrote: > innodb_page_size of 16384 is the default, so that is what I'm working > with as well. The row size limit is half the page size minus some > overhead, so it comes out to 8126 and I bet that is yours as well. > > Yes, I am utf8mb4 at the database and table levels, and I bet you are > right. Just to confirm, between 3.2.1 and 3.2.2 the column archive_rendering_mode was added to the mailinglist table. This column is type - integer (4 bytes), but could be enough to push the row over the limit. As far as utf8mb4 vs. utf8 is concerned. There will be issues with the hyperkitty_email table subject and content columns in particular and maybe others if email messages contain 4-byte utf-8 unicodes. However, as I read the MySQL docs, for columns like VARCHAR(255) and VARCHAR(510), the difference affects only the number of characters that can be stored in the column and not the actual column width. I.e., a VARCHAR(255) column is actually up to 256 bytes wide (1 byte for length and up to 255 butes of data) and can thus hold up to 85 3-byte utf-8 encodings or up to 63 4-byte utf-8 encodings, but since any string normally contains only a few if any (probably none in the case of the mailinglist table) the actual limit is much closer to 85. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 11 months

[MM3-users] Re: Archive search failing on one list

by Mark Sapiro

On 10/9/23 22:50, Mark wrote: > > I'm still on this problem of one list's archive-search not returning > any results. I created a new list today and it also has the same > problem. > > In short, the older lists all seem fine -- their search results are up- > to-date so that tells me the cron is okay. It's just these 2 newer > lists that have the problem. > > It's taken me while to get my head around the Django admin command you > have suggested, as I kept getting an error when starting: Steve has addressed your issues with multiple Django admin commands, some of which apparently don't reference the correct settings. > The format of my final line is different to yours ... > > Mine: <MailingList: <MailingList thepost(a)example.com>> > > Yours: <MailingList listname(a)domain.com (listname.domain.com)> > > 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? It is not a clue as to the problem. The format of that `representation` changed in HyperKitty 1.3.5. What is your version? What happens if you do, with the appropriate Django admin and list name, ``` python3 manage.py update_index_one_list thepost(a)example.com ``` -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 2 months

[MM3-users] Re: Pre-approved howto

by Mark Sapiro

On 7/5/18 6:14 AM, thor.rustad(a)gmail.com wrote: > I have tried to understand the concept of pre-approved messages, but I'm spending way too much trying to figure it out. Help! There is a list attribute, moderator_password, which is not currently exposed in Postorius and therefore must be set via 'mailman shell'. Here's a sample session. > $ mailman shell -l junk(a)msapiro.net > Welcome to the GNU Mailman shell > The variable 'm' is the junk(a)msapiro.net mailing list >>>> m.moderator_password >>>> from mailman.config import config >>>> m.moderator_password = config.password_context.encrypt('xxx123').encode('us-ascii') >>>> m.moderator_password > b'$6$rounds=656000$SKMqTlPybIZSBjYB$wCga5qALCv8oobp4cDql2iKEg8T6qIgk8XEKYbkk9QXENeFQDHZ1M4AtmqfureYQDB5g.Az.nZPrWAr9N9g1N0' >>>> commit() That will set the list's moderator_password to the encrypted value of 'xxx123'. Then, if a post to the list contains Approved: xxx123 either as a header in the message (recommended if possible) or as the first non-blank line in the first text/plain part of the message, the post will be 'pre-approved'. The header can actually be any of Approve:, Approved:, X-Approve: or X-Approved: and if it is not a header, but is found in the first text/plain part of the message, it will be removed from that part and a best effort will be made to remove it from other text/* body parts in case it is also in an alternative part. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years, 5 months

[MM3-users] Re: Removing the footer from mails

by Mark Sapiro

On 10/21/2017 01:46 PM, Peter Mueller wrote: > Hi, > > mailman2 had the configuration variable "msg_footer" to edit/remove the > footer. How can I get rid of the footer in mailman3? The doc is at <http://mailman.readthedocs.io/en/latest/src/mailman/handlers/docs/decorate.…>, but it's a bit complex. First, the message footer template name is 'list:member:regular:footer' and the digest footer template name is 'list:member:digest:footer' and if you want the same template for both, the name 'list:member:generic:footer' will do. The easiest way to set these is to create a template for the desired language (probably 'en') or an empty file if you want no footer. Then, there is a 'var' directory in the Mailman installation which contains sub directories named 'archives', 'cache' 'data', 'etc', 'ext', 'lists', 'locks', 'logs', 'messages', 'queue' and 'templates'. You can put list specific templates in var/templates/lists/LIST.ID/en/, domain specific templates in var/templates/domains/DOMAIN/en/ and sitewide templates in var/templates/site/en/. For example if you put an empty file at var/templates/site/en/list:member:generic:footer and a non-empty file at var/templates/lists/list.example.com/en/list:member:regular:footer, all messages and digests will have no footer except for regular deliveries from the list.example.com list which will use it's template. list overrides domain overrides site overrides default. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

8 years, 1 month

[MM3-users] Re: Mailman3 on Debian 10

by Mark Sapiro

On 1/30/20 9:22 AM, Bala Mutyam wrote: > Sorry one more issue, > > Mailman settings page giving me below error. > > Server error > An error occurred while processing your request. > > Error logs: > > ERROR 2020-01-30 17:20:11,331 16285 django.request Internal Server Error: /postorius/accounts/subscriptions/ > Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py", line 41, in inner > response = get_response(request) > File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 187, in _get_response > response = self.process_exception_by_middleware(e, request) > File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 185, in _get_response > response = wrapped_callback(request, *callback_args, **callback_kwargs) > File "/usr/lib/python3/dist-packages/django/contrib/auth/decorators.py", line 23, in _wrapped_view > return view_func(request, *args, **kwargs) > File "/usr/lib/python3/dist-packages/postorius/views/user.py", line 306, in user_subscriptions > mm_user = MailmanUser.objects.get_or_create_from_django(request.user) > File "/usr/lib/python3/dist-packages/postorius/models.py", line 164, in get_or_create_from_django > return self.get(address=user.email) > File "/usr/lib/python3/dist-packages/postorius/models.py", line 86, in get > return method(*args, **kwargs) > File "/usr/lib/python3/dist-packages/mailmanclient/client.py", line 322, in get_user > return User(self._connection, content['self_link'], content) > KeyError: 'self_link' Just prior to this is a call to the REST API to GET /users/user(a)example.com (or whatever the user's address is). It appears that that user doesn't exist in core. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 10 months

[MM3-users] Re: # comment allowed in a template file?

by Mark Sapiro

On 7/27/20 5:15 AM, skenny(a)scss.tcd.ie wrote: > > The effect of the template files not being readable by user "mailman" was interesting. Hundreds of lines like the following got written to mailman-core's var/log/smtp.log file at the rate of 4 per second: > > Jul 23 17:09:54 2020 (25) Using agent: <mailman.mta.bulk.BulkDelivery object at 0x7fdf9e7b5f28> > > (the hex number was different each time). That's a `debug` level log message written for every delivery. It has nothing to do with the unreadable templates except that the unreadable template causes looping in an attempt to send the message. Did you perhaps set [logging.smtp] level: debug in an effort to diagnose the template issue? > Having excessively restrictive permissions on the template files is a silly - but easy enough - mistake to make. If it were possible to add it to Mailman 3, a more descriptive logging message could point others who make it in the right direction, perhaps. I spent a long time trying to figure out why messages weren't getting sent out from Mailman core, and in the end it was luck in form of a colleague's suggestion about file permissions that got me out of the rut. There is clearly a bug in that an unreadable template should just be skipped and the fact logged. I have reported <https://gitlab.com/mailman/mailman/-/issues/745>. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 4 months

Search results for query "sapiro"