Resolved by latest update.

Resolved by latest update.

In T314247#9905328, @Dzahn wrote:

Mailman migrated to a new server and a new version just now. Did this get faster?

Sadly I'm not competent enough, I don't even have a clue where to look. I'm of course happy to assist and to test.

Why is MW1.41.0 removed here when the issue started in MW1.41.0?

The list in Manual:32-bit consists of four entries, three of which are relevant for very large sites only, i.e. not relevant for nearly all sites, and one issue similar to this one.

I can confirm that in a 64bit environment the problem does not occur.

The problems happens even with a fresh default 1.41.0 installation on an empty database, so the German language isn't the factor because default is en-gb, and the same for short URLs.

What perhaps should be said: My story runs on a 32 bit Linux, and the MW installer says php uses 32 bit integers, which is not recommended. Any comment on that before a restart the whole testing on a 64 bit system?

Step by step:

• download MediaWiki 1.41.0 and unpack it in the Documentroot of an empty webserver
• setup empty MariaDB
• run the Mediawiki installation, leaving as much as possible on default, except: Wiki name, database password, user name, user passwort, enable Linter, enable Visual Editor, enable DiscussionTools
• notice that it complains that no default skin is selected, so choose Vector
• install the LocalSettings.php
• notice that DiscussionTools is not enabled in the generated LocalSettings.php, so enable it
• run update.php or not
• verify described behaviour

It may happen that more than 6 accounts per 24 hours have to be created,. Does the limit also apply to sysops?
Anyway, at the given day only two accounts were created, and the second creation showed the mentioned problem.

Sent by e-mail.

As I have created the ticket, it appeared to work. Anyway it should be checked, as this happened around a dozen times before and it's not acceptable to retry for hours to create an account.

Fri Mar 1 11:00:15 2024: error: OTRS-CGI-10: Can't write '/opt/otrs/var/tmp/CacheFileStorable/User/5/2/52f851d8292246f80d324eacb84f5bc5': No such file or directory

Just as an opinion, as soon as the plan is going to become complete, I may worth involving the VRT community for feedback before the actual changes are made. At best via VRT wiki as maybe not everybody is able to follow here.

Asked and answered in May 2023: If the gridengine instance can no longer run, please feel free remove it.

Feel free to look into my code, but I don't like to publish that.

Good idea, I didn't even consider that this may be triggered by myself. It appears to be always a few seconds after full and half hours, so it's unlikely one of my scripts, but perhaps one of the GenericAgent tasks.

Last occurence: Sat Jan 13 07:00:02 2024 (UTC)

@grin I think this is out of scope of this task. We can discuss it at VRT wiki.

spam-by-queue cannot happen. Not that nobody is able to handle that, nobody will handle it. And it's not the solution to the described problem, but at most only a weak cure for the symptoms.

https://commons.wikimedia.org/wiki/File:..Arunachal_Pradesh_Flag(INDIA).png
https://commons.wikimedia.org/wiki/File:Derzhprom.JPG
https://commons.wikimedia.org/wiki/File:%D0%93%D0%BE%D1%81%D0%BF%D1%80%D0%BE%D0%BC,_%D0%B2%D0%B8%D0%B4_%D1%81%D0%BE_%D1%81%D1%82%D0%BE%D1%80%D0%BE%D0%BD%D1%8B_%D0%BF%D0%BB.%D0%A1%D0%B2%D0%BE%D0%B1%D0%BE%D0%B4%D1%8B.JPG

The shell now works, but I don't get all required the perl modules installed via CPAN for different reasons.

Sorry that I may sound stupid, but I have no experience how this all works.

When I do this I get version mismatches because the container runs with perl5.32 but the login host where I installed some additional perl modules has 5.28.

https://commons.wikimedia.org/wiki/File:%D0%93%D0%BE%D1%81%D0%BF%D1%80%D0%BE%D0%BC,_%D0%B2%D0%B8%D0%B4_%D1%81%D0%BE_%D1%81%D1%82%D0%BE%D1%80%D0%BE%D0%BD%D1%8B_%D0%BF%D0%BB.%D0%A1%D0%B2%D0%BE%D0%B1%D0%BE%D0%B4%D1%8B.JPG

https://commons.wikimedia.org/wiki/File:Derzhprom.JPG

https://commons.wikimedia.org/w/index.php?title=File:Derzhprom.JPG&action=delete

https://commons.wikimedia.org/wiki/File:%D0%93%D0%BE%D1%81%D0%BF%D1%80%D0%BE%D0%BC,_%D0%B2%D0%B8%D0%B4_%D1%81%D0%BE_%D1%81%D1%82%D0%BE%D1%80%D0%BE%D0%BD%D1%8B_%D0%BF%D0%BB.%D0%A1%D0%B2%D0%BE%D0%B1%D0%BE%D0%B4%D1%8B.JPG

https://commons.wikimedia.org/wiki/File:Human_Flaccid_Penis.jpg

Error deleting file: An unknown error occurred in storage backend "local-multiwrite".

When I run via "webservice --backend=gridengine start" is works.
When I stop it and use ""webservice start" it breaks with "Can't locate CGI.pm".

I have changed the footers accordingly, and I think there is a good cance that this could solve a relevant part of the problem. Thank you!

I don't want to have the list content e-mail reroutet, but the list admin notifications. Is this also possible?

I should be possible for the user to unsubscribe from the list directly out of the received list e-mail.

Another example: [[ticket:2022041010003876]]

Please see http://gulu.net/T297783_v1.tar.bz2 with the included A.sh for the download. Does that make sense?

Please give me a day or two to prepare this accordingly.

There files have different names at the source site than they should have at commons. They may also be in different path at the source site, or even at different sites. What is the procedure to get them to the mediawiki maintenance servers and apply the file name mapping?

In T297783#7579492, @Reedy wrote:

The descriptions need to be in individual files that match the filenames to be uploaded; not in multiple large files that contain many descriptiions each... Otherwise the uploader has to split them.

Please advise if the data is needed in any other format.

Assigning to Ladsgroup as we already talked about this.

Example: https://commons.wikimedia.org/wiki/File:Karlheinz_Krauth_ed02.jpg

Much appreciated. Thank you!

Well, yes, but it doesn't increase my confidence in this new mailman setup, to be honest. There are a few other issues, all small enough not to report them, but summarized the whole thing isn't really convincing. (Sorry, please don't shoot the messenger.)

Interestingly the 6 pending requests are visible under https://lists.wikimedia.org/postorius/lists/otrs-permissions-l.lists.wikimedia.org/unsubscription_requests but the badge icon at https://lists.wikimedia.org/postorius/lists/otrs-permissions-l.lists.wikimedia.org/ shows "0" now. Is this a new bug introduced with the recent change?

After a hint from Keegan and Quiddity I was able to delete the causing tickets. Issue resolved.

Thx.

Issue still present, see:
https://lists.wikimedia.org/postorius/lists/otrs-permissions-l.lists.wikimedia.org/

Correct.

Another example: I run a deletion request archiver bot on Commons which once in a while gets limited by the spam filter. When working behind this manually, I'm unable to perform these edits even as a sysop, so I spend hours to find the relevant matches and "nowiki" them in pages of dozens of KB size. The cost of such manual work is hardly in good relation to the benefit.

The migration team concluded that "VRT permissions agents" should be the name of the global group, and if possible both the visible (translatewiki) text and also the technical wiki group name should be renamed.

Please delay this task to tomorrow, after today's project team meeting.

Makes sense, communicated to the user this way, thank you!

Does only the technical implementation (rights assignment) move to the stewards, or also the decision the rights are to be assigned?
Do local policies remain in place, or are they overridden by a new global policy?

The current requirement is that one has to have 2fa enabled at the time when IA rights are applied, but there is neither a policy (is it?) nor a technical reason not to disable 2fa at any time later. Will stewards review or monitor this in any way?
A more simple approach from the bureaucratic point of view would be to technically check the 2fa status by the software at the time the group rights are to be used, so that IA (or say CU) features can only be used when 2fa is enabled at that time. This of course would require a software change, but it appears to be a much more reasonable and flexible way to me.

I would like to withdrawn the request. Can be done later.

Database s51441_krdbot can be immediately deleted.

Disclosure: I did not participate in the vote, but it is know that I'm supportive of the idea for years.

Can you please put or link this somewhere on OTRS wiki? I think there are some more Greasemonkey scripts, at lease I have one that is a bit useful.

I appreciate that we have that feature now and do test it, but I second akosiaris' statement above that we don't have any process yet to recover an account. I guess if anybody locks out themselves at the moment we could be unable to recover the account. Please consider that OTRS admins may not have enough resources for assistance at the moment.
If 2fa forces us to rely on anything not verifyable during account recovery, it perhaps doesn't add much additional security.

In T246449#5957171, @chasemp wrote:

@Krd if you would like to be included here please add MFA to your phab account. Thanks.

Looks good to me. Please also include checkuser.wikimedia.org and steward.wikimedia.org.

As said, I can do that, but I don't think too much detail is required anyway.
We can use bots currently on private wikis with username and good passwords. If we had bot passwords, we could enable 2fa on the bot account and limit the bot password to the fixed IP of the private server the bot runs at. This will in any case highly improve security, with likely not any loss.
If you ask me, this is a nobrainer.

Please feel free to do so.

Please advise what is needed to push this forward.

Perhaps I could, but definitely not in a public ticket.