Hello everyone,
We recently installed a tutorial for the Wikidata Query Service
<https://wdqs-tutorial.toolforge.org/> (WDQS) on Toolforge.
This is the first time Wikimedia Israel developed an instructional tool in
English for the use of the whole Wikmedia community and beyond - as opposed
to our other tools that were aimed for the Hebrew or Arabic speaking
communities. As such, it is also the first time we are hosting a tool on
Toolforge.
All our other tools (mostly Wordpress sites, like the one on Toolforge) are
hosted in Israel at a commercial hosting service, and maintenance (Wordpress
update and security) is done by a commercial company. However, I am not
sure this company would provide maintenance for the WDQS tutorial given
that access to Toolforge requires a Wikimedia developer account, a Wikitech
account, SSH access - not the kind of things commercial services are keen
to get into...
I was wondering if any of you have some on what we could do to ensure the
WDQS tutorial is kept up-to-date and secure.
I believe maintenance would take up to 2-3 hours per month - this is not a
huge undertaking, but at our organization we do not have anyone in-house
who is savvy enough to do it.
Do you know or can suggest someone who knows how to maintain a Wordpress
site AND is familiar with the Toolforge? Are you this someone?!? Or maybe
you know someone that might know someone?
Any input regarding this issue would be much appreciated.
Cheers and stay safe,
Dr. Keren Shatzman
Academic & Projects Coordinator
WMCS has redesigned the PAWS cluster and built a new one in parallel. We
would like people to try things out and makes sure it's ready to go. If
you are a PAWS user and have some things you might like to try out, you
can visit https://hub.paws.wmcloud.org and give it a shot. Please create
a Phabricator task with the project tag #paws if you find any bugs or
things that don't work as well as in the old cluster. We will leave both
clusters live until August 7th (2020-08-07), when we will change
paws.wmflabs.org to a redirect to the new domain.
Please be aware that it is running on the local sqlite database for now,
and that may reduce the performance for things like launching notebooks
under load. It will be using Toolsdb like the existing PAWS cluster
after the final cut over.
For further details, please see:
https://wikitech.wikimedia.org/wiki/News/2020_PAWS_migration
--
Brooke Storm
SRE
Wikimedia Cloud Services
bstorm(a)wikimedia.org
IRC: bstorm_
_______________________________________________
Wikimedia Cloud Services announce mailing list
Cloud-announce(a)lists.wikimedia.org (formerly labs-announce(a)lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/cloud-announce
Is there any specific guidance for what's appropriate or not appropriate for my tool to be logging?
I'm using OAUTH, so my tool knows the identity of the user. I assume I don't want to be logging that. Or, is it OK, as long as the logs stay within toolforge?
For debugging purposes, I'd like to log some kind of unique session and/or request id, which I'd expose to the user via the tool's U/I and ask that they report those as part of any bug reports. Are there any issues with that?
Hello everyone,
As part of the Small wiki toolkits
<https://meta.wikimedia.org/wiki/Small_wiki_toolkits> initiative, a Starter
kit <https://meta.wikimedia.org/wiki/Small_wiki_toolkits/Starter_kit> has
been developed for smaller language Wikimedia wikis! This Starter kit lists
resources, tools, and recommendations in technical areas (e.g., templates,
bots, gadgets, etc.) relevant to smaller wikis that are just getting
started. Small wiki contributors can use it to make their community's
workflow easier. You can now use and promote the Starter kit in your wiki
community, and start translating the landing page and its subpages in a
language you want.
If you have any questions, ideas for venues where it should be shared or
wiki pages where it should be linked, or any other suggestions for
improving it further, please share on this talk page
<https://meta.wikimedia.org/wiki/Talk:Small_wiki_toolkits/Starter_kit>.
If you are interested in helping with the Small Wiki Toolkits initiative
and can offer help with running workshops, developing toolkits, or
exchanging problems and challenges in smaller wiki communities, add
yourself as a member here:
https://meta.wikimedia.org/wiki/Small_wiki_toolkits#Members.
Cheers,
Srishti
*Srishti Sethi*
Developer Advocate
Wikimedia Foundation <https://wikimediafoundation.org/>
I've created a handful of keys, experimenting the various configs. Now that I've figured out what I need, I have a bunch of old consumers that I don't need any more. Is there anything I should do to revoke them?
Today we merged two small changes [0][1] to the front proxy for
*.toolforge.org. These changes allowed us to close a 5 year old
feature request [2] asking for Toolforge to always use TLS (HTTPS) and
to also set a strict-transport-security header (HSTS) to tell web
browser that they should *always* use TLS when talking to a Toolforge
webservice.
Most of this has been happening for some time, but the final changes
were to increase the HSTS duration to one year (technically we
advertise 31,622,400 seconds which is 366 days) and to close the "POST
loophole". The "POST loophole" was created when TLS was first enforced
on Toolforge back in January 2019 [3]. It allowed HTTP requests with
the POST verb to continue without TLS encryption. This was done
because of unspecified behavior of clients (web browsers) when
receiving an HTTP "301 Permanent Redirect" response to a POST action.
A similar exception was originally made when the Wikimedia project
wikis were switched to always require TLS encryption.
We do not expect new issues with the use of Toolforge webservices as a
result of this change, but if you find something behaving badly as a
result please report it in Phabricator using the #Toolforge project
tag or join us in the #wikimedia-cloud Freenode IRC channel to ask for
help.
[0]: https://gerrit.wikimedia.org/r/612947
[1]: https://gerrit.wikimedia.org/r/612948
[2]: https://phabricator.wikimedia.org/T102367
[3]: https://phabricator.wikimedia.org/phame/post/view/132/migrating_tools.wmfla…
Bryan
--
Bryan Davis Technical Engagement Wikimedia Foundation
Principal Software Engineer Boise, ID USA
[[m:User:BDavis_(WMF)]] irc: bd808
_______________________________________________
Wikimedia Cloud Services announce mailing list
Cloud-announce(a)lists.wikimedia.org (formerly labs-announce(a)lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/cloud-announce
This is a heads-up that we are planning to replace the host keys
for the Gerrit SSH server at gerrit.wikimedia.org:29418.
The change is planned for Tuesday, July 14th in the PDT
morning right after the MediaWiki train, that's around 11:00 UTC.
(https://wikitech.wikimedia.org/wiki/Deployments#Tuesday,_July_14)
The RSA key will be replaced with a longer version and additionally we
will start to offer ecdsa_256, ecdsa_384, ecdsa_521 and ed25519.
The service will not be RSA-only anymore which some users had already
reported as an issue.
After the change on Gerrit, your git / git-review / direct ssh
commands are expected to fail with errors about mismatched or changed
host keys or host identification.
This is expected.
You will need to remove the old, no longer used host key, and verify
the new one.
To remove the old host key, follow the instructions on screen or
consult the manual of your SSH software. Once that is done, retry the
command, and you'll be prompted to verify the new host key.
You can find the new keys for verification in this email below and on
https://wikitech.wikimedia.org/wiki/Help:SSH_Fingerprints/gerrit.wikimedia.…
If they match, confirm, and your command should continue. Once you
have successfully updated the host key you should no longer see any
errors.
If you are running any bots talking to gerrit-ssh please also update
their configuration accordingly and restart where needed.
https://wikitech.wikimedia.org/wiki/Help:SSH_Fingerprints/gerrit.wikimedia.…
ssh_host_rsa_key
2048 SHA256:j9/pXXc9WzjQwYP0t7nlzqH9EBOTw6q7DgcfnamJtsY
gerrit-code-review(a)gerrit1001.wikimedia.org (RSA)
ssh_host_ecdsa_256_key
256 SHA256:58swSiByT+4LVqs30/FqJpEPj+Mwjtn3WJY5hitlEgM
gerrit-code-review(a)gerrit1001.wikimedia.org (ECDSA)
ssh_host_ecdsa_384_key
384 SHA256:vFEVzNGuagPmYiw9EIwBStzd0X+gtprZzOi8vbLxAfc
gerrit-code-review(a)gerrit1001.wikimedia.org (ECDSA)
ssh_host_ecdsa_521_key
521 SHA256:OWb1uenhapK7AFPfEB+NRxgfxhktZ1Q6C5eCy+VbgsY
gerrit-code-review(a)gerrit1001.wikimedia.org (ECDSA)
ssh_host_ed25519_key
256 SHA256:njCmWMsshq3MqQxyIFO36UNwCwzTamXERqylF1XJhd8
gerrit-code-review(a)gerrit1001.wikimedia.org (ED25519)
--
Daniel Zahn <dzahn(a)wikimedia.org>
Operations Engineer
I've got several oauth tokens that I registered for a while ago. I have the actual tokens, but where I can I look up the details like whether I registered them as owner-only, etc?
Hi Everyone,
We’re happy to announce the July 2020 edition of the Technical Community
Newsletter
<https://www.mediawiki.org/wiki/Technical_Community_Newsletter/2020/July>
is now available. The newsletter is compiled by the Wikimedia Developer
Advocacy Team. It aims to share highlights, news, and information of
interest from and about the Wikimedia technical community.
Check it out, and learn about what technical contributors have been up to
this past quarter, upcoming conferences & calls for papers, and how to get
involved.
The Wikimedia Technical Community is large and diverse, and we know we
can't capture everything perfectly. We welcome your ideas for future
newsletters. Let us know what you would like to see or highlights you would
like us to include.
Subscribe to the Technical Community Newsletter
<https://www.mediawiki.org/wiki/Newsletter:Technical_Community_Newsletter>,
if you'd like to keep up with essential updates and information.
Kindly,
Sarah R. Rodlund
Technical Writer, Developer Advocacy
<https://meta.wikimedia.org/wiki/Developer_Advocacy>
srodlund(a)wikimedia.org
Hi!
We are happy to announce the new domain 'toolforge.org' is now ready to be
adopted by our Toolforge community.
There is a lot of information related to this change in a wikitech page we have
for this:
https://wikitech.wikimedia.org/wiki/News/Toolforge.org
The most important change you will see happening is a new domain/scheme for
Toolforge-hosted webservices:
* from https://tools.wmflabs.org/<toolname>/
* to https://<toolname>.toolforge.org/
A live example of this change can be found in our internal openstack-browser
webservice tool:
* legacy URL: https://tools.wmflabs.org/openstack-browser/
* new URL: https://openstack-browser.toolforge.org
This domain change is something we have been working on for months previous to
this announcement. Part of our work has been to ensure we have a smooth
transition from the old domain (and URL scheme) to the new canonical one.
However, we acknowledge the ride might be bumpy for some folks, due to technical
challenges or cases we didn't consider when planning this migration. Please
reach out intermediately if you find any limitation or failure anywhere related
to this change. The wikitech page also contains a section with information for
common problems.
You can check now if your webservice needs any specific change by creating a
temporal redirection to the new canonical URL:
$ webservice --canonical --backend=kubernetes start [..]
$ webservice --canonical --backend=gridengine start [..]
The --canonical switch will create a temporal redirect that you can turn on/off.
Please use this to check how your webservice behaves with the new domain/URL
scheme. If you start the webservice without --canonical, the temporal redirect
will be removed.
We aim to introduce permanent redirects for the legacy URLs on 2020-06-15. We
expect to keep serving legacy URLs forever, by means of redirections to the new
URLs. More information on the redirections can also be found in the wikitech page.
The toolforge.org domain is finally here! <3
--
Arturo Borrero Gonzalez
SRE / Wikimedia Cloud Services
Wikimedia Foundation