Please read the error. ES6 support is only for core+extensions not on-wiki JS.

So server roles:

• we will have a MW server that has the mediawiki::is_canary value set to true in puppet which will have the ssh keys installed /srv/mediawiki-staging/keys and armed using ssh-agent. This will be the main deploy server. This should also have is_staging set to true.
• we will have a test server with is_staging set to true but not is_canary
• all other MediaWiki servers will have use_remote_deploy set to true. This will add the ssh keys to the www-data account allowing remote access from the is_canary server.
• On most MediaWiki servers for config, simply pushing to puppet will trigger the change to be pulled onto the canary server and then trigger sync checks to run on all servers.
• On MediaWiki servers for l10n, there will be a shorthand that can be run to rebuild the cache when syncing a file or folder.
• For mediawiki, a new sync command will be introduced that will allow you to build them. We could make test3 auto sync on a change. MediaWiki servers can simply require 1 command to be ran or we will automate this.

We can't enable Widgets as we have security concerns. Please see https://dev.miraheze.org/wiki/Replacements_for_the_Widgets_extension for alternatives or ask on https://meta.miraheze.org/wiki/Community_noticeboard

Test3 is now running as 'staging':

It would also be good if we could allow for the extension to receive other updates and still have the patch remain applied, which may require some research/testing.

If we copy enough logic, it should be fine. In the worst case, you just run git apply after updating but before syncing.

This also saves on running commands many many times and cloning git. We could probably eventually automate it in puppet if mediawiki or config changes

Deployed!

Ok, we can try that

CSP Desicions can take a while

I strongly doubt that anyone has a >128 charecter password.

In T7713#155094, @Void wrote:

I'm not certain I would reduce the maximum (currently 4096). In theory, the only problem with having a password longer than 128 characters is potential server load.

I'll create announcements before doing this

Your DNS is pointing at a Softlayer Technologies IP

Test worked in seconds so resolving

We can't reveal user information publicly. I'll note the global account wasn't created properly but the user can email us if they need help.

Yes I intended anyway to speak to Reception first

I'll post formally on CN in the morning and make public but no embargo on discussing it if anyone wants to know

Email recieved

Pending analysis but ^

Disclosure

On 27th July, We logged all users out following a report by a trusted volunteer that an OAUTH2 Rest Endpoint was incorrectly caching some responses resulting in the accidental leakage of some user tokens.

We don't disable for no reason.

We've banned api & rest.php from cache. All users are currently being logged out in case of token leak.

I banned oauth2 from varnish.

I'm not convinced by changing stuff in the Database Collation so probably not tbh.

Such a collation would have to be part of the ICU Version in Debian Stable

https://phabricator.wikimedia.org/T287347

Has this been reported upstream?

not

We can bulk delete once T7693: php-fpm workers keep running out is over

Seems resolved

We know, i'm applying bandages.

Done

rhinos@jobrunner4:~$ mwscript importImages.php smutstonewiki '/home/rhinos/smutfiles --comment-ext=desc --summary="Attribution: https://v2smutstone.fandom.com"'
Will execute:
sudo -u www-data php /srv/mediawiki/w/maintenance/importImages.php --wiki=smutstonewiki /home/rhinos/smutfiles --comment-ext=desc --summary="Attribution: https://v2smutstone.fandom.com"
Type 'Y' to confirm: Y

Dump restarted

I'm not sure if this is magic or Upstream but Partial Blocks has no active code owner, neither massively does the irc feed and we don't do event streams.

In T7573#154040, @RhinosF1 wrote:

In T7573#153879, @R4356th wrote:

FYI, I have been receiving emails from Meta normally on my Outlook email address.

Good to hear. SRE should see subtask for a possible issue.

In T7671#154606, @RhinosF1 wrote:

Findings:

• No conclusive evidence of wrongdoing by SRE
• Current SRE have minimal knowledge of some deployed services
• SRE should ensure that all access members have is documented and handed over or explicitly documented as not to be when someone leaves. Access should be logged and audited regularly rather than on leave.
• SRE should make an effort to review sensitive configuration on a regular basis to see if it's still needed and appropiate.

In T7681#154576, @RhinosF1 wrote:

I can try running the images again and make it use the desc files later

I haven't restarted the import yet

I can try running the images again and make it use the desc files later

Please note that https://smutstone.miraheze.org/wiki/Special:Statistics will be nonsense. I'll refresh stuff later.

21:38 MirahezeLSBot: [rhinos@jobrunner4] sudo -u www-data php /srv/mediawiki/w/maintenance/importImages.php --wiki=smutstonewiki /home/rhinos/smutfiles --comment=Attribution: https://v2smutstone.fandom.com (END - exit=0)

Images done

You don't have to type Y. I was copying my terminal ouput. Both XML + Image output are running. You'll see https://meta.miraheze.org/wiki/Tech:Server_admin_log populated with the log entries and exit=0 when they're done

Not sure why the reply didn't notify me.

We can provide a CSR, please note that you will be responsible for renewing your certificate and while we will make our best effort to notify you before, if it does expire then we have to remove it.

No it's our responsibility to check what we input.

Thanks for the great bug report. It was an easy thing to look at as you'd done most of the hard work for us.

Please can you go into more detail than a bug?

Thanks for the very detailed task.

It recovered 15:41 UK time so was down ~70 minutes

@Amical: As far as I could tell, your wiki wasn't resolving at all. I was getting not resolved when browsing it too.

@Amical:

14:33:14 <icinga-miraheze> PROBLEM - wiki.wikimedia.cat - reverse DNS on sslhost is CRITICAL: rDNS CRITICAL - wiki.wikimedia.cat All nameservers failed to answer the query.

What fandom wiki is the dump from?

Would need to be done in Varnish or NGINX

16:05:53 <MirahezeLSBot> !log [rhinos@jobrunner4] sudo -u www-data php /srv/mediawiki/w/maintenance/importDump.php --wiki=helioswiki heliosrisingheroes_pages_full.xml --username-prefix wikia:heliosrisingheroes (END - exit=0)