Done!

https://gitlab.wikimedia.org/toolforge-repos/db-names is a simple PHP tool using a buildpack.

Done. Please let me know if you have any issues.

• Archived GlobalRename
• Archived {H29}

This seems to work exactly as described on https://en.wikipedia.org/wiki/Help:Pipe_trick.

Please provide the full SMTP logs.

I wonder if this should be a Cloud-VPS (Project-requests) task since this would need a cloud vps project

Ok, the defaults are this:

JOB_DEFAULT_MEMORY = "512Mi"
JOB_DEFAULT_CPU = "500m"

So for 16 jobs I think you want 8Gi RAM and 8 CPUs, does that sound good?

Duplicate of T275555 T225190 T225191?

How many jobs do you want to run at the same time?

Proposal: Let's pick a reasonable default pod quota (current is 10, maybe that or 16?), and then update the default CPU and RAM quotas to match the pod quota multiplied by the jobs-api default settings for CPU and RAM.

This is a dupe of T334908: toolforge-jobs error message doesn't specify which job name is invalid which is pending a jobs-cli release.

analytics-privatedata-users is the wrong group and SRE-Access-Requests is the wrong workflow here. What you want for (especially client) log access is Logstash access which can be received via the nda LDAP group which is required via LDAP-Access-Requests.

This would be the nda LDAP group.

Done!

https://wikis.world/@taavi/110396472967512402

Please note that not all of our servers have -sk support yet, it's only on systems running Bullseye or newer.

I don't think it should link to the task creation form directly, since we want to encourage everyone to search for existing bugs before opening a new one.

Hello! Is there a specific reason to do this on a separate project from wikiapiary? If you need more quota for that one you can request it here.

Hm, that's not intentional! I've updated the repo description and set it as read-only. I don't seem to have permissions to update the Diffusion repo and I don't see a GitHub mirror.

This should probably be explicit about group membership imported from LDAP groups.

Yeah. Iirc for mediawiki/* the only Gerrit group sync is that wmf has equivalent rights to the mediawiki group. There's also a wmde-mediawiki Gerrit group with similar privs (but it's managed manually, not via LDAP), I think we want to preserve that as a separate list instead of merging it with everyone who's passed the MediaWiki-Gerrit-Group-Requests process.

Hi!

Is graphite/statsd on cloudmetrics still actively consumed/useful? (i.e. does anyone look at the metrics?)

Not really[1]. There are some grafana-cloud dashboards (and a majority of those are probably unused these days) using it but the equivalent metrics are present on the metricsinfra Prometheus instance.

Both are members of the deployment group (via platform-engineering membership), so I've added to the wmf-deployment Gerrit group.

The easiest way I can think of to block all of those actions would be to temporarily change the uid=novaadmin user's password. We don't have anything else that would be close to a unified off switch for all of these LDAP write workflows.

I believe at least for Keystone this would result the LDAP tree getting out of sync compared to its MariaDB database.

I can't reproduce with Firefox. All of the images load, although it does take a few seconds.

Making this one public sounds fine to me, but T336556 should stay private for now.

In T334940#8850559, @gamer191 wrote:

May I propose disabling editing graphs (to mitigate the potential risk of someone exploiting this vulnerability, now that it's been discovered), and then leaving it up to the user if they want to view a potentially unsafe graph from before this vulnerability (which tbh I know nothing about) was discovered?

Unable to reproduce with:

wfLoadSkin( 'Vector' );
wfLoadSkins( [ 'MonoBook' ] );

So this seems like an issue coming from an individual skins ValidSkinNames skin.json option and not a more general issue that affects all the skins. I suggest doing some sort of a binary search to find the skin that's causing the issues.

In T335865#8846384, @dcaro wrote:

This is a workaround (not very nice) on how to change the log path:

In general we expect to see existing contributions to the relevant projects before granting privileged access, which I'm not seeing here, nor any specific plans on what you're planning to work on. Declining.

Which specific MediaWiki software features would this allow testing that are not covered by existing beta cluster wikis?

I'm pretty sure I've user harbor with a tool with a - in it. So it's the double dash or punycode that's the real issue.

Tool names can't have underscores in them as they're restricted to DNS labels (for K8s compat reasons).