The work happening in T429930: Convert dynamicproxy from nginx to haproxy accidentally caused the X-Forwarded-Proto header to be http (instead of https). This has now been fixed.

Regression from https://gitlab.wikimedia.org/repos/releng/release/-/merge_requests/259 / T434567: expanddblist without arguments doesn't fail cleanly it seems. $$argv[1] should probably be just $argv[1]. cc @Reedy @dancy

Please contact a maintainer of this project.

What Bryan suggests is what I would do as well. Alternatively I'd recommend updating the jobs to automatically use rsync (or some other file transfer tool) after the files have been generated to copy them to the web server instance to avoid the horrors that our NFS setup includes.

Documented that this volume will not be added to any new projects.

get tagged with project: tools (where?)

It seems like, from above, that there is no actual issue with the repository permissions. Closing.

Does not seem like an infrastructure issue to me, thus untagging.

An image is not inherently tried to a tool, as it is possible to build an image with one tool and deploy it to an another. https://wikitech.wikimedia.org/wiki/Tool:Containers is a good example of that sort of a pattern, and the dev tool of openstack-browser currently an another.

Our friend tool home directory archival strikes again:

taavi@tools-nfs-3:~$ sudo journalctl -u disable-tool.service --grep graphbot-frontend --lines 5
Aug 06 21:12:01 tools-nfs-3 disable_tool.py[3190531]: INFO __main__: Nothing to archive in /srv/tools/project/graphbot-frontend
Aug 06 21:12:01 tools-nfs-3 disable_tool.py[3190531]: INFO __main__: No database config (/srv/tools/project/graphbot-frontend/replica.my.cnf) for graphbot-frontend so nothing databases to delete
Aug 06 21:12:01 tools-nfs-3 disable_tool.py[3190531]: INFO __main__: Archiving databases for graphbot-frontend
Aug 06 21:12:01 tools-nfs-3 disable_tool.py[3190531]: INFO __main__: Tool graphbot-frontend is expired; archiving
Aug 06 21:10:01 tools-nfs-3 disable_tool.py[3190429]: INFO __main__: Nothing to archive in /srv/tools/project/graphbot-frontend
taavi@tools-nfs-3:~$ ls -lah /srv/tools/archivedtools/graphbot-frontend.tgz 
-rw-r--r-- 1 root root 6.1K May 20 14:08 /srv/tools/archivedtools/graphbot-frontend.tgz

+1

In T403912#12190377, @ekrem wrote:

a question born from ignorance & curiosity: given that codex received several minor updates after 2.3.1, should this task still stay open?

The toolinfo field has a field for an URL to documentation. I think it would be pretty simple to create a button in Striker that creates a Wikitech Tool: page on some template and adds it to the toolinfo record, similar to the recently added prompts to automatically add new GitLab repos and Phabricator projects to the toolinfo record.

I realized that the instance should use Bookworm instead of Trixie

Updated list:

taavi@cloudcontrol2010-dev ~ $ os server list --all-projects | grep bullseye
| 85884d07-0fa0-4abb-bac9-dd446d8e556c | tf-bastion                                   | ACTIVE  | VLAN/legacy=172.16.128.239                                              | debian-11.0-bullseye (deprecated 2023-06-30)          | g4.cores1.ram2.disk20 | testlabs                         |
| 3cc0dbe3-627d-42a7-98fb-4f141d2a32af | enc-1                                        | SHUTOFF | VLAN/legacy=172.16.128.97                                               | debian-11.0-bullseye (deprecated 2022-06-02)          | g4.cores1.ram2.disk20 | cloudinfra-codfw1dev             |

So this is essentially done except tf-bastion which is not Puppetized :(

The VMs are still there, just in a shutoff status

Thanks! That worked well, just needed one more explicit crypto key length setting in the patch above that had been missed previously. idp.wmcloud.org is now served by a host running Trixie+CAS 7 and works fine as far as I can tell. I'll leave this task open until the new CAS .deb has made it to apt.wm.o.

Thanks. If the build is available for me somewhere I can also test it now on the new Trixie WMCS host.

In T401804#12175529, @Cyberpower678 wrote:

All Cyberbot VMs are now upgraded to Trixie

This task is vague enough that I can't tell whether this is a request for help (which we usually prefer on the mailing list or on IRC) and if so, with what exactly, or if it is an internal tracking task for the migration.

Good question. Looking at the Netbox changelog that change was first made in 290184 and then reverted as 290185. What's interesting is that the change and the revert happened on the same second and with the same request ID?

The switch port was missing the required tagged VLANs (cloud-instances and cloud-private), I fixed that with https://netbox.wikimedia.org/extras/changelog/290186/ and ran Homer which applied the following diff:

[edit interfaces xe-0/0/26]
+   native-vlan-id 1128;
[edit interfaces xe-0/0/26 unit 0 family ethernet-switching]
-      interface-mode access;
+      interface-mode trunk;
[edit interfaces xe-0/0/26 unit 0 family ethernet-switching vlan]
-       members cloud-hosts1-c8-eqiad;
+       members [ cloud-hosts1-c8-eqiad cloud-instances2-b-eqiad cloud-private-c8-eqiad ];

After that I can successfully ping cloud-private targets:

taavi@cloudvirt1048 ~ $ ping -c2 -6 rabbitmq01.eqiad1.wikimediacloud.org
PING rabbitmq01.eqiad1.wikimediacloud.org (2a02:ec80:a000:201::17) 56 data bytes
64 bytes from cloudrabbit1001.private.eqiad.wikimedia.cloud (2a02:ec80:a000:201::17): icmp_seq=1 ttl=64 time=0.147 ms
64 bytes from cloudrabbit1001.private.eqiad.wikimedia.cloud (2a02:ec80:a000:201::17): icmp_seq=2 ttl=64 time=0.143 ms

Dupe of T311917: [webservice,toolforge-cli] Make `webservice shell` a standalone tool?

In the end it'll need to be a HAProxy map file on the proxy hosts, with an entry per domain name that's opted in to this. So I think we'll need something that can cheaply produce a full list of all tools (/host names) opted-in that can be called regularly on a timer to update the map file.

This is due to those instances not running Puppet successfully (or, more likely, their Puppet servers not syncing successfully due to local conflicts) and so not getting firewall updates to allow new metricsinfra instances to scrape them.

In T432617#12150495, @bd808 wrote:

I was a bit confused when @CCiufo-WMF, Levi, and Alexandros started talking about cloud dev environments as a feature that we should explore during the WE5 + WE6 offsite in Lisbon last fall. I think you may have been in the room for some of that, but maybe it was more of a side conversation at that point than product planning.

As I understand it, Patch Demo is a tool for testing and demoing existing patches that have been developed within a developer's existing local development environment. This seems to be wanting to move it towards a "development environment in the cloud" model for which we've had a long-standing policy against, so I have a bunch of questions relating to how you are planning to mitigate the concerns behind that policy.

Removing subtasks not related to the coordination of the deprecation. Individual project upgrades are tracked in Cloud-VPS (Debian Bullseye Deprecation).

This should be all done from our end.