User Details
- User Since
- Oct 17 2014, 11:24 AM (510 w, 1 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- Krd [ Global Accounts ]
Fri, Jul 12
The problem occurs just now, created one account, cannot create another one.
Fri, Jul 5
The list of all used e-mail addresses is defined in VRTS and mirrored to: https://vrt-wiki.wikimedia.org/wiki/List_of_email_addresses
Thu, Jun 27
With the curl command you are not logged in, are you?
With the curl command you are not logged in, are you?
Jun 20 2024
Resolved by latest update.
Resolved by latest update.
Jun 19 2024
May 13 2024
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.
May 11 2024
Why is MW1.41.0 removed here when the issue started in MW1.41.0?
Apr 9 2024
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.
Mar 28 2024
I can confirm that in a 64bit environment the problem does not occur.
Mar 25 2024
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.
Mar 22 2024
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
Mar 16 2024
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.
Mar 15 2024
Sent by e-mail.
Mar 12 2024
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.
Mar 1 2024
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
Feb 21 2024
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.
Feb 6 2024
Asked and answered in May 2023: If the gridengine instance can no longer run, please feel free remove it.
Feb 5 2024
Feel free to look into my code, but I don't like to publish that.
Jan 15 2024
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.
Jan 13 2024
Last occurence: Sat Jan 13 07:00:02 2024 (UTC)
Jan 5 2024
Jan 4 2024
Dec 31 2023
Dec 11 2023
@grin I think this is out of scope of this task. We can discuss it at VRT wiki.
Dec 9 2023
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.
Jul 1 2023
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
May 16 2023
The shell now works, but I don't get all required the perl modules installed via CPAN for different reasons.
May 15 2023
Sorry that I may sound stupid, but I have no experience how this all works.
May 11 2023
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.
Mar 28 2023
Mar 26 2023
Mar 6 2023
Feb 15 2023
Error deleting file: An unknown error occurred in storage backend "local-multiwrite".
Oct 7 2022
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".
Sep 11 2022
Aug 2 2022
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?
Jul 31 2022
I should be possible for the user to unsubscribe from the list directly out of the received list e-mail.
Apr 18 2022
Another example: [[ticket:2022041010003876]]
Dec 19 2021
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?
Please advise if the data is needed in any other format.
Oct 11 2021
Aug 17 2021
Assigning to Ladsgroup as we already talked about this.
Aug 6 2021
Jul 4 2021
Much appreciated. Thank you!
Jul 3 2021
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?
Jun 16 2021
After a hint from Keegan and Quiddity I was able to delete the causing tickets. Issue resolved.
Jun 15 2021
Thx.
Jun 8 2021
Issue still present, see:
https://lists.wikimedia.org/postorius/lists/otrs-permissions-l.lists.wikimedia.org/
Correct.
Jun 6 2021
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.
Jun 3 2021
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.
May 26 2021
May 25 2021
Makes sense, communicated to the user this way, thank you!
May 24 2021
May 14 2021
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?
May 12 2021
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.
Apr 9 2021
I would like to withdrawn the request. Can be done later.
Apr 3 2021
Jan 22 2021
Database s51441_krdbot can be immediately deleted.
Jan 8 2021
Oct 6 2020
Disclosure: I did not participate in the vote, but it is know that I'm supportive of the idea for years.
Sep 24 2020
Sep 18 2020
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.
Sep 17 2020
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.
Aug 2 2020
Jun 24 2020
Looks good to me. Please also include checkuser.wikimedia.org and steward.wikimedia.org.