I have switched the SSL bot to the WikiTideSSLBot account. Please let me know if there are any issues with certs now.

It would be great if this could be looked into as SSL requests are starting to pile up.

Using RDAP (preferably) or WHOIS is a better solution for these kinds of issues.

At this point I think our only option may be to switch to a new account if we can't retrieve access to MirahezeSSLBot. But we'll see if we can find a recovery code or something first. I believe that is still controlled by John and we should retrieve access somehow.

In T11275#235252, @OrangeStar wrote:

This has been open for a while, I thought someone was going to come up with some idea to do this automatically but I guess not.

Let's keep it simple then. I propose we just have an array of wikis with wikibase client, and wikis those wikis have to contact, and send the appropiate CORS headers. Those that want to do the same thing as @Redmin here will have to open a phab task here for their wikis to be added to this array. This would be done in https://github.com/miraheze/puppet/blob/master/modules/varnish/templates/default.vcl#L231. Sound good to the SRE team?

Will make the change now, though I think what is really needed is a wider reorganization of https://meta.miraheze.org/wiki/Request_features and the current forms we have on Phorge. Especially since eventually there will be very few tasks like imports (even images) that will still be done on Phorge. But it's probably worth waiting until more stuff is automated (at least images I'd say).

I will consider this request after talking to a few others in both SRE and T&S and to find out what the future of TSPortal is anyway. As a T&S member I think it helps for DPA primarily the other aspects of it are pretty buggy sometimes and may not be really worth maintaining if we choose not to utilize it and in that case this request may be unnecessary...

A user on Discord has reported it happening again, it's possible the issue wasn't fully resolved.

Sounds good

Hmm, that's weird but now I don't get Error 500 neither by importing pages on gameshows nor by editing with code editor on chernowiki. Looks like the problem is actually resolved.

Visual editor being broken is already tracked in T11903. As for the other issues, can you reproduce this on any wikis other than gameshowswiki?

Still got Error 500 when try to import pages on gameshows.miraheze.org. Small xml files are going well when large (like 750 kb) are failing.

Once again purged 13-16G of Varnish logs.

Several Discord users have reported this occurring recently and more frequently

Not a huge priority anymore

Oh, my bad. I assumed that this was done during the migration and this task just wasn't closed.

We should still rebalance the successors.

In T11744#235630, @Universal_Omega wrote:

I've been thinking... would this actually solve anything? The new global DB could still go down and take down the farm... however I do suppose it would be less likely...

What resources do you propose, CPU and RAM wise?

dbs has been migrated and the ones mentioned in this task no longer exist

Triaging as low as domains that are not pointed aren't usually even removed on sight

This is now done.

This is now done.

It would be easier because you wouldn't need a command anymore, it would be fully automatic, which is the point of T11710. When Caddy sees a new domain name for the first time, it queries a HTTP server, and if it gets a 200 OK as a response, it generates a certificate for that domain. This all happens in the timespan of the first TLS ClientHello for that domain.

I think I'm a bit confused with the terms here, since technically certificates are generated "automatically" (i.e. just with a command), so how would this make it easier for them to be generated based on a request sent by RequestSSL ?

https://github.com/caddyserver/nginx-adapter could make such a migration possible, but of course rewriting the config in JSON or Caddyfile would be best.

Adding the RequestSSL tag since, while this is Miraheze-specific, it is of interest to me as a developer. If this is done it will define how I approach the Miraheze-specific hook handlers related to RequestSSL.

Now deployed. If a wiki wishes to have it enabled, they can request it at Steward requests.

Just as a quick update even though this was already resolved, did https://github.com/miraheze/puppet/pull/3731 to fully puppetize this, including build, so it should be installed 100% automatically on any new servers now.

https://github.com/Universal-Omega/CVTBot/commit/a2b07eb14ef9ff34c4428b42d80c2b3a2c9db91e removed the mono dependency to make this work. Then https://github.com/miraheze/puppet/pull/3727 for making it work on Miraheze. That patch is currently running on mon181 which seems to work!

Fix for this would be having a separate exception handler for NXDOMAIN, instead of bundling it together with NoAnswer (https://github.com/miraheze/puppet/blob/fec5c1dfa8dd4592a727c41bc4e29155c229feca/modules/monitoring/files/check_reverse_dns.py#L125).

Per above. Please do reopen if you notice others missing though.

For now, I don't believe this is needed, but if it becomes apparent that is we can do so eventually.

In T11756#235854, @Universal_Omega wrote:

I did think of that, but I also agree that issue-tracker is a bit to long and making it simple is better. It's kinda difficult regardless of what is used, all have some negatives to it...

In T11756#235853, @Agent_Isai wrote:

Also, for Phabricator CDN, we should use wikitide.net as miraheze.wiki is being deprecated and might be dropped outright one day.

I did think of that, but I also agree that issue-tracker is a bit to long and making it simple is better. It's kinda difficult regardless of what is used, all have some negatives to it...

I did think about that but not everyone on Phabricator is an issue but I might be getting to much into the specifics and semantics.

After further consideration, I think maybe issues.* would be better for simplicities sake, as Labster recommended. But not 100% decided on which is the best yet.

issue-tracker sounds good to me.

With self hosted mail gone for good here, I'd say this has become a lot more viable.