Bonjour,

Je rencontre, depuis la sortie de la v4, quelques soucis pour l'envoi d'e-mails. Il semble, après discussion avec le support (et après avoir suggéré l'idée, vu qu'ils pataugeaient) que le quota "x mails/heure/ip" soit d'application depuis leur hébergement mutualisé, ce qui fait que les autres clients hébergés à coté du Lexpage bloquent régulièrement le quota du Lexpage, et m'empêche donc d'expédier correctement les emails d'inscriptions et les logs d'erreurs que je suis supposé recevoir par e-mail. La résolution de ce problème était un pré-requis pour envoyer les notifications du site par e-mail...

Ce problème, ajouté aux limitations techniques sur l'usage de Python et l'incompétence du support technique d'OVH en ce qui concerne les hébergements mutualisés me pousse à choisir une autre solution. Tchou a proposé, sur le minichat, de s'orienter vers un VPS. A priori, je ne souhaite pas gérer les e-mails moi-même et je conserverai ce service chez OVH. Je n'ai pas encore confirmation que le souci d'e-mail sera réglé depuis le VPS, mais à priori, ça devrait être le cas puisque la machine possède sa propre IP...

Donc, je voudrai savoir si certains parmi vous avez une expérience avec les VPS d'OVH, en particulier le cru 2014 qui semble avoir corrigé certains problèmes du passé (notamment au niveau des performances). L'hébergement actuel arrive à expiration en octobre ou novembre, j'ai donc du temps pour prendre un VPS en parallèle, tester 2-3 choses et faire la migration si cela se passe bien. Je pense, dans un premier temps, m'orienter vers une Debian 7. Vu les ressources limitées (1go de RAM), je pense m'orienter vers Nginx en frontal, avec Gunicorn comme proxy pour servir les applications Python (et donc le Django qui gère le Lexpage). Niveau DB, je resterai (malheureusement) sur du MySQL. Probablement que j'en profiterai pour passer à Myisam plutôt qu'InnoDB, n'ayant pas besoin (je dois encore vérifier) des possibilités de ce dernier.

Pour la partie PHP (indispensable notamment pour faire tourner Piwik, et éventuellement conserver encore un peu le site Lexteam en ligne, le temps de migrer les photos vers une autre plate-forme), je n'ai pas spécialement d'idée... Il semble que PHP-FPM soit une bonne approche, mais j'ai peur de consacrer trop de ressources sur la plateforme "juste pour de l'analytique" (à peu de choses près). Je n'ai, de plus, aucune idée de la charge que représente Piwik (j'imagine que ça doit être globalement léger, tout de même !).

En plus de la question sur le VPS, j'ai quelques questions concernant l'administration du système :
- Quelqu'un a-t-il déjà utilisé Supervisor ou une alternative ? Un retour sur la fiabilité de cet outil ?
- Je suis allergique à iptables (essentiellement parce que je n'ai pas l'expérience avec cet outil). Je sais que c'est pratiquement indispensable pour un serveur d'avoir un bon firewall, mais je n'ai aucune idée du type de configuration à utiliser. A priori, j'imagine qu'il vaut mieux partir sur une approche basique consistant à filter tout, sauf les ports utilisés (ssh, ftp, http).
- OVH ne propose pas, forcément, de backups comme c'est le cas avec les mutualisés (pour la petite histoire, la seule fois où j'en ai eu réellement besoin, OVH avait flingué tous les backups !). Je partirai à priori sur un petit script maison pour sauver les sources/config/db et faire la copie "manuellement" sur une autre machine (chez moi, quoi peut-être que mon rasp pourrait s'en charger, d'ailleurs...). Vous avez des alternatives ?
- Enfin, quelles sont les possibilités de "monitoring" relativement légères ? Par exemple, en cas de surcharge du serveur pendant quelques secondes/minutes, ou de service qui crash lamentablement, etc. j'aimerai pouvoir recevoir une notification (ou en tout cas, pouvoir déclencher un trigger au niveau du serveur, soit pour me l'afficher sur Lexpage, soit pour me l'envoyer par e-mail, etc.). Y a quelque chose de "centralisé" qui existe ? (jusqu'à présent, sur les serveurs que j'ai monté à l'unif, j'avais un script qui scannait les logs et extrayait les éventuelles erreurs, avant de me les envoyer par e-mail ^^).

Pourquoi "malheureusement sur du mysql" ? C'est ton serveur, tu fais ce que tu veux ! :)

Je pense que postgres est plus gourmand que mysql, donc effectivement ça le ferai pas sur une petite machine (à vérifier, c'est de l'estimation au doigt mouillé !), mais y'a mariadb qui est sensé remplacer à l'identique mysql.

La charge de piwik : bah ça va dépendre du nombre de visiteurs et de la puissance réelle de cette machine monocœur 1Go. Là, difficile à dire. La surcharge aura lieu lors du travail de génération des pages, que tu peux scripter via cron.

: REUUUUUUH ! Le ftp, ça n'existe plus. Ça n'a jamais existé, du reste ! :D ... sftp : tout se gère via le ssh ! Voire scp ou rsync et là ça reste sur le port ssh. Globalement, si tu utilise ssh, première chose à faire c'est virer le login root (par ssh, hein, pas le root de la machine accessible une fois loggué avec ton nom de user dont les script-kiddies ne sont pas sûrs de l'existence ! ;) ), la seconde c'est un apt-get install fail2ban .

Les backups : rsync ou scp (rsync (via ssh) est mieux car il préserve les permissions et sauve les liens symboliques en liens symboliques) je dis pas du tout ça car y'a un mois un scp m'a fait une boucle folle à cause d'un ln d'un répertoire sur son répertoire parent ! :) géré via cron, sur une machine distante.

Monitoring : c'est mon point faible. Je préfère pas répondre (et lire les réponses avec attention).

Le php avec php-fpm : suffit juste de l'installer, ça va pas plus loin. Je dis ça mais je n'ai pas encore installé professionnellement de nginx (j'ai juste fait des essais ou des projets persos), mais c'est pas plus compliqué qu'installer un couple apache + mod_php.

Tes DNS sont gérées où ? Rien ne t'empêche si tu as les 2 hébergements de concert de tester les 2 de concert avec lexpage.net sur une IP et www.lexpage.net (ou niou.lexpage.net, whatever) sur l'autre. Tu sais quel est le NDD le plus utilisé actuellement (perso j'utilise le domaine sans www) ?

Une VPS, c'est une IP à toi ? Ou y'a du NAT derrière ? Je demande car on est sensé ne plus en avoir beaucoup en Europe (quand y'en a plus du tout en Asie depuis une paire d'années). À quand l'IPV6, ce loup de mer ?

TchouPourquoi "malheureusement sur du mysql" ? C'est ton serveur, tu fais ce que tu veux ! :)

Oui, je suis plutôt partisan de Postgres mais effectivement, comme tu le dis, c'est un peu plus lourd
Je ne connais pas Mariadb, je vais me renseigner...

Tchou : REUUUUUUH ! Le ftp, ça n'existe plus. Ça n'a jamais existé, du reste ! :D ... sftp : tout se gère via le ssh ! Voire scp ou rsync et là ça reste sur le port ssh. Globalement, si tu utilise ssh, première chose à faire c'est virer le login root (par ssh, hein, pas le root de la machine accessible une fois loggué avec ton nom de user dont les script-kiddies ne sont pas sûrs de l'existence ! ;) ), la seconde c'est un apt-get install fail2ban .

Fail2ban fait partie de la liste de ce que je dois installer. C'est effectivement un incontournable
Pour le FTP, je passe actuellement une fois sur 2 via SSH, mais c'est un poil plus lent. Dans certains cas, ça vaut la peine d'avoir du FTP classique tout de même (j'ai noté vsftpd pour l'instant).

Pour le login root, j'ai vraiment l'habitude de sudo, donc le compte sera probablement désactivé au login, que ça soit en ssh ou en local. Si j'ai besoin d'une console root, y a toujours sudo -s..

TchouLes backups : rsync ou scp (rsync (via ssh) est mieux car il préserve les permissions et sauve les liens symboliques en liens symboliques) géré via cron, sur une machine distante.

J'ai peur que rsync soit un poil gourmand pour faire de l'incrémental, que ça soit sur mon rasp, ou sur le serveur. A priori, j'ai toujours un backup des fichiers en local, c'est plutôt pour la db que j'aimerai avoir un backup. Pour l'instant, j'ai en tête d'utiliser ma Dropbox comme target du backup. Ca tourne en ligne de commande, et il me suffit d'activer/désactiver le service quelques minutes avant et après le backup.

TchouTes DNS sont gérées où ? Rien ne t'empêche si tu as les 2 hébergements de concert de tester les 2 de concert avec lexpage.net sur une IP et www.lexpage.net (ou niou.lexpage.net, whatever) sur l'autre. Tu sais quel est le NDD le plus utilisé actuellement (perso j'utilise le domaine sans www) ?

Les DNS sont gérées par OVH, je peux donc sans problème ajouter un champ A sur un sous-domaine pour tester le vps tranquillement en faisant pointer le sous-domaine sur son IP. Le seul "souci", c'est que le serveur SQL d'OVH n'est pas accessible en dehors d'un mutualisé, je vais donc dans un premier temps faire quelques tests, puis migrer la db sur le VPS, et faire pointer le mutu dessus. Si ça passe sans souci, je ferai le changement des dns pour le www vers le VPS. Les autres sous-domaines seront migrés petit à petit et resteront sur le mutu le temps que tout soit bien vérifié.

Pour le NDD, c'est le www qui est le plus utilisé. Je pense profiter du changement pour forcer l'usage du www (via un redirect simple).

TchouUne VPS, c'est une IP à toi ? Ou y'a du NAT derrière ? Je demande car on est sensé ne plus en avoir beaucoup en Europe (quand y'en a plus du tout en Asie depuis une paire d'années). À quand l'IPV6, ce loup de mer ?

Y a une ipv4 et une ipv6. Selon la doc OVH, "Chaque VPS dispose d’une Adresse IP publique dédiée en V4 et une en V6. ".

A priori, MariaDB est full compatible avec MySQL pour ce que je dois en faire, et le backend de Django pour MySQL ne devrait pas poser de souci. Vu les quelques benchmarks, je ne perds rien à tester MariaDB plutôt que MySQL, au contraire...

Juste dommage que ça soit pas dans les dépots de Wheezy... (Je pense me diriger vers Debian 7, ne connaissait pas vraiment CentOS et ayant une certaine expertise sous Debian ^^).

Il me _semble_ avoir lu que debian allait remplacer mysql par mariadb, de manière transparente. Il me semble. Rien qu'à l'écrire ça me semble bizarre.

Ce qui a causé mariaDB, c'est encore et toujours le propriétaire de mysql, Oracle, qui ayant acquis les logiciels open-source de Sun, tend à les délaisser voire à les remettre en proprio pour certaines parties. Cf Open-office/LibreOffice, c'est la même chose.

Pour le : on s'en fout de la vitesse, la sécurité c'est mieux ! Le balance tes identifiants en clair, suffit d'un sniffeur sur le trajet entre toi et ton VPS et tu seras bien content d'avoir économisé quelques secondes sur un transfert une fois par mois !

Backuper des bases, c'est facile. Et dans le pire des cas, même sans faire proprement un mysqldump, copier les fichiers (dans /var/lib/mysql de mémoire) et les remonter ailleurs marche, me dit un collègue (perso, je préfère quand même faire dans le "propre" d'un dump).
En sachant (mais ça ne va pas te concerner) que tu peux aussi avoir un serveur de réplication sous mysql, avec un serveur maitre et un esclave. Si l'un tombe, tu redirige vers le second avec des données quasi(?)-identiques.

TchouIl me _semble_ avoir lu que debian allait remplacer mysql par mariadb, de manière transparente. Il me semble. Rien qu'à l'écrire ça me semble bizarre.

Je confirme ton info, c'est ce qu'on retrouve un peu partout.

TchouPour le : on s'en fout de la vitesse, la sécurité c'est mieux ! Le balance tes identifiants en clair, suffit d'un sniffeur sur le trajet entre toi et ton VPS et tu seras bien content d'avoir économisé quelques secondes sur un transfert une fois par mois !

Je n'utilise pratiquement jamais les mêmes identifiants/passwords pour FTP et le reste
Cela dit, le jour où j'ai besoin du FTP, je l'active, et je le désactive juste après

TchouBackuper des bases, c'est facile. Et dans le pire des cas, même sans faire proprement un mysqldump, copier les fichiers (dans /var/lib/mysql de mémoire) et les remonter ailleurs marche, me dit un collègue (perso, je préfère quand même faire dans le "propre" d'un dump).

J'ai une nette préférence pour le dump aussi, qui rend possible la migration.

TchouEn sachant (mais ça ne va pas te concerner) que tu peux aussi avoir un serveur de réplication sous mysql, avec un serveur maitre et un esclave. Si l'un tombe, tu redirige vers le second avec des données quasi(?)-identiques.

Difficilement envisageable sur un serveur "unique". Cela dit, OVH propose de base du raid 10, donc je suis "à l'abri" pour les pannes matérielles éventuelles, et leur backup/semaine est accessible en cas d'incident technique. C'est surtout vis à vis des "pannes logicielles" que j'envisage le backup (un système de fichiers en rade, une suppression malencontreuse des données, une attaque qui passerait, un fichier corrompu, ...). Dans ce cas-là, rien de tel qu'un petit dump pour remettre en route le bouzin

Guybrush Probablement que j'en profiterai pour passer à Myisam plutôt qu'InnoDB

NON !
Aucune bonne raison de faire ça, jamais

Bah si : Django n'a pas l'usage de ce qu'InnoDB propose

Vu l'ORM, c'est principalement du PK-lookup qui est fait (d'ailleurs, je viens de voir que Django par défaut utilisait MyIsam actuellement ) donc en terme de perfs, un gain moyen pas négligeable... Le jour où j'ai besoin du transactionnel ou des FK, c'est sûr que je forcerai innoDB (actuellement, je tourne en auto_commit, chaque insertion est faite via l'ORM, donc les routines internes à Django suffisent pour défaire ce qui est fait en cas de souci).

En plus de se torcher avec l'ACIDité, Myisam c'est aussi des full-table lock à chaque update de row et pleins d'autres petites joyeusetés de ce genre (pas de buffer d'écritures, etc, etc...).
Ce moteur est voué à mourir depuis trop longtemps, il faut arrêter de l'utiliser :)

Le verrou global à la table est un peu ch.. en effet, mais dans le cas d'un site comme Lexpage, avec peu d'update (et surtout peu de concurrence), ce n'est pas gênant. Pour les transactions et la récupération, ce n'est plus un souci dans Aria (le fork de MyISAM pour MariaDB) si j'ai bien lu. Je vais essayer de trouver quelques benchmarks pour voir l'overhead de base d'InnoDB (enfin, son équivalent pour MariaDB). Si c'est léger, autant adopter cet engine dès maintenant...