Pour simplifier la centralisation des fichiers graphiques pour la pycon, j'aurais besoin d'avoir accès à la machine :)
Co-authored-by: Florian Guillet <florian@eno.do>
Reviewed-on: #7
Co-authored-by: Florian Guillet <merwyn@noreply.localhost>
Co-committed-by: Florian Guillet <merwyn@noreply.localhost>
So there's 3 place to configure max upload body size:
- Discourse settings (Via admin web interface)
- Host nginx (via Ansible)
- Guest nginx (Via app.yml)
Like:
E: The value 'bookworm-backports' is invalid for APT::Default-Release as such a release is not available in the sources
E: The value 'bookworm-security' is invalid for APT::Default-Release as such a release is not available in the sources
E: The value 'bookworm-updates' is invalid for APT::Default-Release as
such a release is not available in the sources
But anyway « The plugin does not support this anymore. » : bc6450d8eb
The disk starts to approch 90% on deb2.
Also Discourse is huge, I do no longer feel like sharing the same
machine that so many other things (it was OK when our Discourse was
just a small test).
SpamHaus expect the IPv6 /64 to be owned by the same entity.
This is not the case for Gandi VPS that are provided with a single
IPv6.
Gandi is working on it, they want to provide /64 to organisations, but
it's not ready yet.
In the meantime we're blocked by spamhaus since a few days on both the
/64 used by git.afpy.org and the /64 used by discuss.afpy.org.
So as a trash fix I propose sending emails using IPv4.
While proofreading the config, and checking if it was up to date
according to:
- Mozilla recommandations
- SSLtest
- testssl.sh
I spotted an issue in the HSTS header:
$ curl -I https://afpy.org
[...]
Strict-Transport-Security: max-age=63072000; always
the `always` part is an nginx config token, not a cookie value.
So I simplified the conf so we can more easily copy/paste from Mozilla
generator, which obviously removed the bug.