Problème de bind9 réglé. Idem pour fail2ban qui bouffait beaucoup

Serveur MariaDB prêt et configuré (accessible par le réseau le temps de la migration, faut pas que j'oublie de limiter à localhost après).

Serveur Nginx installé et qui peut déjà servir du php (via php-fpm). Reste à installer Gunicorn et tester Python. Ce sera pour plus tard.

Ca avance bien

Plutôt, oui. J'ai un peu d'expérience avec la mise en place de serveurs pour les étudiants, à l'unif... mais j'essaye aussi de faire ça très proprement, et le plus simplement du monde (au cas où je dois recommencer suite à un crash système ).

Pour Gunicorn/Django/Lexpage, je vais prendre un peu de temps, car je vais essayer de placer tout ça correctement dans un environnement virtuel, histoire de ne pas être embêté par des mises à jour ultérieures et pouvoir gérer les versions comme je veux.

Nginx configuré pour dealer avec Gunicorn, lui-même configuré en virtualenv pour servir les joyeuses pages du Lexpage !
Il ne reste plus qu'à tester ça (et surtout les petits détails comme iptables, monit, backup, ... ) et voir comment optimiser le tout (mais pour l'instant, ça tourne bien, c'est plus rapide que le "Lexpage" actuel !).

Je continue à mettre en place. Lexpage tourne parfaitement ainsi que Piwik. Pour l'instant, le tout fonctionne sur un peu moins de 300mo de RAM, ce qui fait plaisir (mais y a aucune charge dessus). Les différentes librairies sont bien installées (dans un environnement virtuel) et en cas de souci, tout redémarre proprement comme il faut.

Je me tâte sur la configuration d'iptables, vu qu'il n'y a que les ports du serveur web qui sont ouverts (et le serveur MariaDB, mais dès que la migration est terminée, il n'écoutera qu'en local).

La configuration avance, petit à petit. J'ai finalement laissé tombé Exim pour la gestion des e-mails, vu que je souhaite juste pouvoir envoyer 2-3 mails depuis le serveur, typiquement sur ma propre adresse (pour les alertes, etc.). Les emails envoyés depuis le site le sont via une "vraie" connexion SMTP, je n'ai donc rien besoin de particulier sur le VPS. Et bien, assez curieusement, c'est plus compliqué de faire simple que de faire compliqué J'ai du remplacer Exim par sSMTP configuré pour le serveur d'OVH avec un compte utilisateur pour que ça fonctionne enfin. Tout ça parce qu'OVH refuse de servir de relais pour les e-mails (même avec authentification !).

A propos des backups, ils sont maintenant en place. Je ne backup que la base de données (j'ai une copie locale des fichiers, toujours à jour). Par facilité, et pour ne pas trop me prendre la tête, j'utilise logrotate (avec un script maison) pour gérer les dumps des différentes bases de données. Le dump est créé, compressé, lors du postrotate et est ensuite géré comme un "fichier de log" par logrotate. Le tout a lieu dans un répertoire que je synchronise via Dropbox sur un nouveau compte créé pour l'occasion. Ca devrait être suffisant.

[Edit : grrr... Le démon dropbox bouffe près de 70 mo ^^ Tant qu'à faire, autant ne pas l'activer en permanence. J'ai donc un cron qui m'active un script qui s'occupe de lancer Dropbox, lui laisse maximum 3 minutes pour se synchro, et le coupe. Ca devrait suffire]

Il me reste à regarder 2-3 petites choses au niveau monitoring/alerte et ensuite je pourrai débuter les tests de charge (notamment en migrant Piwik sur le vps, puis la database du Lexpage. Ensuite, on change les DNS et enjoy ^^).

J'avais jamais fait gaffe que fail2ban bouffait "beaucoup".

sSmtp, j'utilise aussi. Ultra simple d'utilisation quand tu as déjà un smtp ami dans le coin !

En effet, et surtout quand tu n'arrives pas à configurer correctement Exim pour faire ce job (Je sais pas pourquoi, mais Exim a toujours refusé de s'authentifier auprès d'OVH, et voulait l'utiliser en tant que relais !!). Pour fail2ban, je sais que l'objectif n'est pas le même que le firewall, mais je ne l'utilisais que pour SSH, alors j'ai juste mis une règle 5 connexions TCP/60 secondes sur SSH, et je m'en vais de ce pas configurer un délai de quelques secondes sur PAM pour l'authentification, ça devrait fortement limiter les tentatives par brute-force [edit : ok, y a déjà 3 secondes de délai...]

J'ai fait pas mal de chipotages sur le VPS aujourd'hui, et ça commence doucement à prendre forme. J'ai un peu galéré avec Nginx (notamment pour gérer du PHP dans un sous-répertoire (coté client) qui n'est pas dans un sous-répertoire (coté serveur)). Ca m'a permis de voir que, comme d'habitude, ce que je veux faire est facile, mais sujet à un bug (connu depuis près de 3 ans, toujours pas solutionné. Pour l'info, c'est le try_files $uri qui foire en cas d'usage d'alias au lieu de root).

Hier soir, j'ai galéré avec ufw pour configurer iptables. Une fois que tout était fini, et que j'ai voulu tester, ça a bien foiré. Pourquoi ? Parce que ufw n'apprécie pas d'être dans openvz sans certains modules... Moralité : je me suis tapé une grosse partie de la doc d'iptables pour faire la configuration "à la main". Cela dit, je suis plutôt content du résultat. Si y a un expert firewall dans le coin, j'aimerai montrer les règles histoire d'avoir un retour là-dessus, parce que je suis un peu noob dans ce domaine (et je suppose qu'il vaut mieux, pour une question de sécurité, ne pas publier ces règles ici, sauf si elles sont parfaites )

J'ai fini l'optimisation du serveur MariaDB. C'est un peu "too much" pour Lexpage, mais ce n'est pas grave. Coté Gunicorn/Nginx, je n'ai pas fait grand chose. La configuration d'Nginx est la version par défaut. Je bloque juste au niveau d'iptables à 20 connexions TCP par 10 ou 15 secondes (j'ai testé 20/20 mais c'est un peu extrême quand on est plusieurs derrière un NAT). Pour Gunicorn, j'ai mis 2 workers en sync pour l'instant, sans preload (comme ça je peux changer le code du site sans devoir relancer gunicorn). On verra si ça tient la route, mais je suppose que oui, vu le temps de réponse très très faible.

Visiblement, OVH met une limitation sur les connexions sortantes depuis son hébergement mutualisé, rendant impossible/inefficace l'utilisation d'une base de données distante. Je vais donc attendre quelques jours (le temps de vérifier la configuration du VPS) avant de faire le changement DNS, et de mettre un joli bandeau sur la "version actuelle" invitant à utiliser temporairement une autre adresse... (maximum 24 à 48h, cela dit).