Another issue caused by deployers merging without reviewing the changes being deployed. I've ask @Paladox to run the SQL.

Not an issue

mail and postfixUser are two distinct things

Paladox has blocked the IP which is causing most of the traffic

Update on the logging I asked you to look into a few days ago?

Quite a few actions are blocked on you.

Redis is no longer being used for caching

Non-reliable numbers here from small scaling testing but:

Discussion happened and support was given, outcome?

https://github.com/miraheze/CreateWiki/commit/c9dd807fffa119e47558ce820ec2ef876a9a26f2 And deployment will be whenever someone chooses to deploy it onto production

Technically the location of the file means little and moving it to be in MirahezeMagic would seem out of scope - as it's a root-level file. Keeping it within puppet seems easiest as theres no gain from moving it to mw-config.

Same password as bots-noreply

which means persistency and tls will be supported.

In T6852#135120, @Reception123 wrote:

In T6852#135095, @RhinosF1 wrote:

Per our discussion, Zppix's access will remain revoked and in this case any new access request needs approval anyway of Miraheze SRE.

The bots team are granting automatic approval to all current members as of this comment in the Miraheze Infra team to full root access to our cluster.

Per policy, any member of Infra can approve access for the rest.

I hope this reassured you. The relay token got deleted by @Zppix but I've made a new one and myself @Void will deploy that later so full access will be restored by end of day.

I think this is a sensible proposal and prevents unnecessary spending by Miraheze Limited for another server.

In T6852#135081, @RhinosF1 wrote:

The relay is restored. Further discussions will occur today

In T6850#135030, @Dmehus wrote:

I guess Special;Interwiki it needs to be available to non-registered users so search engines can crawl it

My understanding is the reason this was added was to allow Interwiki Administrators to handle IW on private wikis.

This isn't a bug - it's expected behaviour by https://github.com/miraheze/MirahezeMagic/blob/master/includes/MirahezeMagicHooks.php#L211

We can install Redis v6, however to use TLS, we need PHP-Redis v5 >, which is not available in Buster, only in Bullseye (11). MediaWiki also does not have support for this, but it's a small modification to a regex in RedisConnectionPool which we can commit locally.

Is a major software upgrade of critical services really ‘short term’?

This is possible natively with Redis 6

mon1 marked as done, Icinga logs need to be local for IRC bots however I set up icinga logs to go to graylog separately under T6798

@Paladox are you able to give a look over the ones that SPF has marked for you to review please?

If restarting the service is required to pick up changes, databases.json and *wiki.json can't be cached

Can you do the incident report as the primary responder?

Icinga monitoring alerts/events are now logged in Graylog

Approved

Midnight UTC for us, for other users of the extension, it would be whatever they configure it to be.

Endorsement by the DSRE is enough for me.

Done, though in future please make these requests at the Stewards' Noticeboard