Project for issues which require a Site Reliability Engineer to do something or generalised work affecting servers, networking, new services or major puppet/DNS changes.
I cannot be sure but I have a feeling that the image was being loaded properly.
Most browsers had an update quite a long time ago which is causing this issue. An example wiki affected by this- Snap! Wiki.
I support this idea
Thu, Sep 24
Seems to be resolved now. If not feel free to reopen.
causing icinga to warn because nginx access logs were filled with 429s.
It was doing this with the old system anyway on occasion. I assume you mean more frequently. Are 429s something we can exclude from the check? Would that be better?
It seems this problem will prolong indefinitely or should we expect a solution soon?
@Paladox and @Southparkfan are working to deal with this. The rate limiter will probably exist for the foreseeable future unless we are happy are resources can cope with traffic that was causing issues (DDoS/SQLis) but we are working to improve the solution so it doesn't affect legitimate traffic.
It seems this problem will prolong indefinitely or should we expect a solution soon? Thank you (ps: some days ago I was able to load my page without problem but then when back to the same, was the rate limiter lifted at some point?)
Wed, Sep 23
Done should take effect in approx. 10 minutes
Why did you close it, it hasn't even been completed yet. I'm planning on reopening this failed/rejected task. And yes you can make the change now.
Tue, Sep 22
Sorry to interrupt, currently the following domains are whitelisted:
Mon, Sep 21
I've had to revert my change as it was causing icinga to warn because nginx access logs were filled with 429s. Though I did raise the limit to 50r/s still not enough.
Sun, Sep 20
Ah, so that might be the main issue here, the RAM usage? Perhaps a discussion with @Owen if we have room in the budget to increase the RAM allocated to one or more of our servers? If the budget is too tight, then I guess this is dependent on a rather significant donation from another benefactor?
This does seem to require a lot of RAM, so not sure we can do this at this stage.
This would be useful for certain bots as well. For example: SignBot requires this. (https://phab.bots.miraheze.wiki/T86)
Waiting for response from @Paladox regarding nginx changes.
Contacted Owen for a data processing agreement for the free infra offers.
Thu, Sep 17
Wed, Sep 16
Sun, Sep 13
Sorry, when I edited, it reopened it.
It happened to me too.
Wed, Sep 9
It's rebalancing so should hopefully reduce gluster1 disk usage (thus resolving that warning).
Tue, Sep 8
Fixed the phab issue with https://github.com/miraheze/puppet/commit/8ea25cf319be946116166fc2635e61e2e1b6fe64
Fixed with https://github.com/miraheze/puppet/pull/1491