I suppose the first step with this would be to get the wikitech configuration merged into operations/mediawiki-config.git. Settings for testwiki may be useful to look at to see what things we tweak when pinning a vhost to a particular machine.

I got poked today as a Scrum-of-Scrums pingback to see why this is still open and marked as blocked by Operations. Here's my $0.02:

Wikitech is using hetdeploy today as a result of work that @Andrew, @Reedy and I did in August/September. What it is not doing is "riding the train" to get weekly updates as a result of scap and sync-* commands executed by deployers on tin. @Andrew was concerned about letting the deployers group have ssh access to virt1000 (host that runs wikitech) which up until now has been an root-only host for ssh access.

Instead of getting changes pushed from tin, virt1000 is updated by a root running sync-common --verbose manually. The obvious problem with this is that it is an manual operation and thus subject to not being performed often enough to say get the latest security patches and bug fixes that have been pushed to the cluster.

The proper fix in my opinion would be to allow deployers access to virt1000 and get it properly on the train or we should disentangle it from hetdeploy again and go back to ops manually updating wikitech when they remember to do it.

We want it to be hosted on a separate host from the puppetmaster, we don't want it to be on the mediawiki cluster at all. Wikitech offers, if any, a completely different surface of attack than most of the (much more relevant) other sites, because of the different auth mechanism and of the use of OSM.

Let's move this forward again. Getting a server to host wikitech is easy. Actually hosting wikitech on a different server than virt1000... I have no idea if it's possible. @Andrew, since you are the one most familiar with wikitech from what I see (do correct me if I am wrong), mind taking a look and figure out what's needed for this to happen ?