FOSS developer and Miraheze Sysadmin.
User Details
- User Since
- May 24 2019, 17:22 (92 w, 6 d)
- Availability
- Available
- IRC Nickname
- RhinosF1
- GitHub User
- RhinosF1
- Miraheze User
- RhinosF1 [ Global Accounts ]
Wed, Mar 3
Someone needs to run sql/patch-approval_date.sql
Looking
Tue, Mar 2
I'm still seeing lag. Just had a 6 hour delay.
Mon, Mar 1
The broken update was rolled back.
Cargo was updated with https://github.com/wikimedia/mediawiki-extensions-Cargo/compare/8fc32040cdef3012f6c0666a85d45af4b6afe2ad...34bc7aed58def2a481918a8a6ea60497926070fe included on Monday.
Go away Herald
Tagging Site Reliability Engineering because CSP needed
Sun, Feb 28
Thanks for letting me know @Dmehus
Not sure why Parsoid is failing and haven't checked that but I don't see it actually being set in ManageWiki
Please clear your cookies. Session tokens don't persist very well over a wiki rename.
We'll run that for you soon then.
If by indexed, you mean by search engines, that is updated often but they're not always the quickest at picking it up.
You can either purge the page or we can run a script
Fri, Feb 26
By best to suggestion is to change the account email to sre@ and then we can reset the password and switch to our details.
Was these the ones that were free? What provider was it?
Thu, Feb 25
Will do by end of week
Please try resetting your cookies but what wiki?
Wed, Feb 24
Thanks!
Tue, Feb 23
You should be able to hide it from the sidebar but you can't block access to them completely.
Do you mean all Special pages or specific ones?
Mon, Feb 22
Already available from Special:ManageWiki/settings
Sun, Feb 21
I had a quick look and unless I'm blind it's not quite as simple as I thought but I'm looking into it.
I can look into filing a change of url notification to google but if I recall correctly I might have to ask @Southparkfan for help with that.
Sat, Feb 20
Fri, Feb 19
Thu, Feb 18
Thanks!
Will make public once WMF confirm they have no objections too as they've been involved in a lot.
And updated with Grafana v7.4.2 (29e75ad97b)
WMF have still kept the stop gap and it's an extra layer so worth keeping as well still.
Proper fix is available with https://github.com/grafana/grafana/pull/31263
Wed, Feb 17
There's also the kafka JobQueue task on another get rid of redis mission
Only IR left
Sysadmins: Use https://graylog.miraheze.org/search?q=NOT+mediawiki_exception_file%3A%5C%2Fsrv%5C%2Fmediawiki%5C%2Fw%5C%2Fextensions%5C%2FCargo%5C%2F%2A+AND+mediawiki_exception_class%3AJobQueueError&rangetype=relative&streams=5f8c6fd446640840f104b0ba&relative=7200 and https://graylog.miraheze.org/search?q=mediawiki_host%3Ajobrunner%2A&rangetype=relative&streams=5f8c6fd446640840f104b0ba&relative=7200 to see errors.
Much lower rate but still some. We'll continue working on it. CC @Paladox to see if they know how to get redis working again.
Looks to be out of disk space
jbr3&4:
ERR Error running script (call to f_3b56824083b7c4c3509163c7e76e00904014d92e): @user_script:4: @user_script: 4: -MISCONF Redis is configured to save RDB snapshots, but it is currently not able to persist on disk. Commands that may modify the data set are disabled, because this instance is configured to report errors during writes if RDB snapshotting fails (stop-writes-on-bgsave-error option). Please check the Redis logs for details about the RDB error.
There's a huge rise in redis errors starting 07:12
I'll look now
Tue, Feb 16
Mon, Feb 15
Per our discussion, Zppix's access will remain revoked and in this case any new access request needs approval anyway of Miraheze SRE.
Thanks. Tagging @MacFan4000 and @Voidwaker to respond to me on IRC so we can discuss long term action as soon as possible.
The situation and Zppix's future
The relay is restored. Further discussions will occur today
I have revoked Zppix's access per https://phab.MirahezeBots.org/T193 and will restore the relay
Sun, Feb 14
For some reason the config flag was never set. I've added it.
Sent email back to researcher on SPF's request
Sat, Feb 13
It should be fairly easy to make configurable.
It's CentralNotice but I'd assume no because that would break translations.
Thu, Feb 11
Looks like that to me now.
There's a bunch of puppet failures you might wanna check
That should be Unbreak then
I think you just copy the pages it mentions to your wiki
I'm not sure this is actually an extension
I see https://github.com/miraheze/mw-config/pull/3512/files and https://phabricator.miraheze.org/T6528 but imagine this is DPL v DPL3?
@Universal_Omega: Is this safe? I think you've raised performance concerns before with it.
See above links, they all shows as warning or critical for me.
No longer pointing
https://icinga.miraheze.org/monitoring/service/show?host=sslhost&service=pol.wiki%20-%20LetsEncrypt
Times out
Times out
Broken DNS config
No longer pointing
No longer pointing
No longer pointing
Proxying us through CloudFlare
Proxying us through CloudFlare
Registration Lapsed or held
Not resolving
Which wiki, there's 8. An rDNS alert doesn't mean wiki down as well, it can mean anything from bad config to they're proxying our traffic through something first.
I believe this is deliberate and set somewhere in our config, although if I recall correct that might have been just meta, but yes I agree it needs phasing out and replacing with a proper description for everyone.
Wed, Feb 10
Looking at your records, you seem to have your nameserver as mw-lb.miraheze.org and 2 others.
Tue, Feb 9
Site is pointing at cp6 which has been decommissioned. Please use a CNAME to mw-lb.miraheze.org or convert to our DNS.
Mon, Feb 8
Sorry didn't even see the policy
Sun, Feb 7
Still can reproduce from https://nonciclopedia.org/wiki/Speciale:TutteLePagine, multiple untranslated namespaces.