(It’s possible that the wiki won’t remember your frontend preference for very long, if it suffers from the same problem that makes sessions so short-lived. Haven’t tested it very much yet.)

Sure ^^ do you need any special configuration?

@Bstorm Alright, that sounds fine to me.

In T285944#7233967, @bd808 wrote:

(It is technically possible to use jsub from a process running on the grid, but that is honestly so gross that I try and block it out from my mind.)

Field report from trying to use toolforge-jobs for the wd-shex-infer tool:

These tests date back to mid-2013; they start with a comment that’s kinda funny:

Looks good on Not Wikilambda now :)

Same goes for the wikilambdaload_zids parameter of the wikilambdaload_zobjects query+list module.

Did I actually need to request a new consumer? It’s now been pointed out to me that there is a checkbox to “Reset the secret key to a new value” in the page to update the consumer – would that have been enough?

Works now, thanks a lot!

Ohhhh. That’s true, I completely forgot about the logs.

Most of the volume mounts are already read-only:

But as an approximation, I’ve pushed a pygments-server change to override the Python open() function before calling Pygments. It may break if Pygments changes how it reads files, but for now it works as another defense layer (I’ve tested it locally).

The whole point of my pygments-server, as opposed to the other one, is that it doesn’t parse the command line, because that limits the ways in which it can be used. I don’t control Extension:SyntaxHighlight, I don’t know which parts of pygments’ CLI it’ll start to use tomorrow.

Isn’t it redundant with $wgServer or one of the related variables?

Alright, I added this to the LocalSettings.php:

I think this is fixed; no secrets were revealed in this task, so I think it can be made public too.

Alright, after a false start where I accidentally took down the wiki by blocking ingress to all pods, including the webservice, I think it’s working now.

Mentioned in SAL (#wikimedia-cloud) [2021-07-15T18:49:00Z] <wm-bot> <lucaswerkmeister> block external traffic to internal pods (T286724)

I thought a generally accessible pygments-server might be useful, but now I don’t feel confident enough anymore that k8s isn’t mounting random stuff elsewhere in the container. Let’s see if I can figure out network policies.

Mentioned in SAL (#wikimedia-cloud) [2021-07-15T18:24:00Z] <wm-bot> <lucaswerkmeister> don’t mount service tokens into pods (T286724)

Ugh, you’re right.

Mentioned in SAL (#wikimedia-cloud) [2021-07-15T17:53:00Z] <wm-bot> <lucaswerkmeister> only mount ~/www/python into pygments-server pod (T286724)

The fix here is to use Kubernetes network policies to limit incoming traffic to the pygments server service.

Also, note how the edit links in the sitelink groups (first screenshot) still say edit, rather than “golygu” as in ?uselang=cy.

Possible blocker: T286679: Some interface messages are in Welsh when British English is selected as the interface language isn’t a very serious issue, but may annoy a number of English Wikipedia users if it reaches group2. (It’s not yet clear how many messages would be affected, and I also don’t know how many people actually have their user interface set to en-gb.)

At least the footer seems to affect Wikipedias as well – https://ca.wikipedia.org/wiki/Portada?uselang=en-gb has the following footer on my end:

https://www.wikidata.org/wiki/MediaWiki:Wikibase-sitelinks-wikiquote/en-gb shows the Welsh message text for some reason (which is at least consistent with it being shown on item pages).

On the other hand, the sidebar, for instance, is unaffected (in ?uselang=cy it’s different):

In T286107#7204963, @aborrero wrote:

For the record, I identified the problem early in the development of the framework. It was a conscious decision to leave it out in the first iteration because I wanted to collect clear use cases and expectations.
I was hoping that the wrapper approach that is suggested in wikitech was enough to cover basically all cases.

In the slightly longer term, the ISA developers should probably request and configure a new OAuth consumer, and the old one should be disabled, since any Toolforge user could have stolen its secret in the past two years or so.

Alright, the old OAuth consumers are gone. I think we can close this. Thanks @bd808!

Alright, @bd808 approved the new consumer and I restarted the tool – seems to work as far as I can tell. (Task remains open since the old consumers are still enabled.)

New OAuth consumer has been requested and configured; I’ll restart the tool (to pick up the new configuration file) once it’s been approved.

Tentatively classifying as Vuln-Infoleak, though I’m not certain about that.

Worked around this in AC/DC by loading the other ResourceLoader module as well (commit, on-wiki diff).

You can get some attribution information from the query+imageinfo+extmetadata API, if you want to (example code), but it’s probably easier to just make the image a link to Commons.

I think just splitting on spaces would do more harm than good. A shell would probably be a viable option.

In T285944#7194862, @Majavah wrote:

In T285944#7194769, @LucasWerkmeister wrote:

• It looks like it’s not possible to pass arguments to the command being executed; I assume we’re expected to put any nontrivial commands into a shell script and use the shell script as the command?

You can add it in quotes, like --command "./my-command.py foo bar".

Thanks for the fingerprint.

I think the How It Ever Worked is that /etc/bash_completion.d/ isn’t loaded on-demand (which I guess is why it’s the legacy location and deprecated, because immediately loading all the completions takes a while)?

After typing misctools and then pressing Tab, become autocompletes correctly. If I understand correctly, completions in /usr/share/bash-completion/ are only loaded on-demand, so combining multiple completions into a single misctools files is not correct – they should be in files called become and sql, respectively, so that they’ll be autoloaded when trying to run autocompletion for those commands.

On the regular bastion, that completion comes from /etc/bash_completion.d/misctools, from the misctools package:

Looks like it’s not installed:

I’d love to use the new jobs framework for Wikidata Shape Expressions Inference, which currently runs as a Grid webservice so that it can schedule Grid jobs.

Hm, I didn’t consider new page creations, that’s a good point. I’ll check if there are any other reasons why Wikibase still has a separate API module.

In T284170#7129989, @LucasWerkmeister wrote:

You can still get the error by adding &notwikilambda-clear-preauth=false to the login URL (example).

Confirmed, looks like this. (“Add a statement” finds no results because it’s searching for properties for other statements, not items as the “depicts” value, but I also fell for this before realizing that there must be an input field missing.)

I guess I’ll close this task now, the “cyclic” brokenness seems to be resolved.

Okay, Z5 is now fixed as well (I added a line zobject.Z2K1 = 'Z5'; before saving the edit). I guess that ID was just a mistake in the initial data (which was then fixed in Iee44178630).

Alright, fixing Z5 doesn’t work, because apparently the content of that page specifies the ID (Z2K1) as Z4 rather than Z5, which wikilamdba_edit then (rightfully, I suppose) complains about when trying to save the fixed revision.

I threw together some JavaScript to fix the monolingual texts:

Big caveat: only counts namespace 0. Ideally it should probably respect $wgNamespacesToBeSearchedDefault.