Retour : Page Principale > sommaire aide > sommaire aide-mémos

---

À faire sur Osyris le nouveau "Sequoia" (2015-12-17)

Des idées en vrac de trucs à faire lors de l'installation du nouveau serveur "Sequoia"



NOTE : DÉPLACÉ EN GRANDE PARTIE SUR TAÏGA

• Installer un certificat SSL plus solide, et passer tout le site en HTTPS  fait ✓ 
  • envisager de passer de Gandi à  LetsEncrypt
• Installer un système de virtualisation genre LXC / Openvz / Proxmox (veille à faire) et plusieurs machines virtuelles pour les différents services (emails, Web...)  fait ✓ 
  • évaluer  ProxMox 4 et s'il n'y a pas de contre-indications et si personne ne propose mieux, go !  fait ✓ 
  • proposition de machines virtuelles :
    • une pour les emails et listes + webservices attachés, webmail etc. (Debian 8 sauf si pb de libs trop récentes)
    • placer les emails sur Grosdur (plus de place, plus sécuritaire) => https://en.wikipedia.org/wiki/Qmail (chercher "NFS")
    • une pour le test et la prod (Debian 8)  fait ✓ 
    • une pour tester les upgrades (permet de tester la mise à jour de la distrib / des paquets sensibles avant d'appliquer à la prod)  fait ✓ 
• Installer un Webmail glamour compatible mobiles : Roundcube, Rainloop ou autre
  • transformer les listes de remarques en comptes IMAP ?
  • repasser les nouveaux employés en IMAP interne plutôt que Gmail ?
    • Attention, on va recevoir 3000x plus de SPAM ! (Gmail est tout de même bon contre le spam...)
• Activer le Wake-on-LAN pour redémarrer un serveur depuis un autre à distance en cas de PB
  • pas la peine, grâce au super iDRAC de Dell  fait ✓ 
• Ne pas mettre le même mot de passe que Sequoia et Agathis (trop vieux, trop connu)
• Sécuriser à donf l'accès web à iDRAC et à la GUI de Proxmox
  • les mettre en DMZ, et que seules les VMs aient des IP routables => accéder à la DMZ en VPN
• définir une stratégie d'adressage pour l'hôte et les conteneurs / VMs  fait ✓ 
  • proposition : seul l'hôte a une IP routable, les conteneurs / VMs sont en NAT => voir ci-dessus
• réviser la stratégie de connexion à distance  fait ✓ 
  • permettre de faire du SSH avec d'autres comptes que root ?  fait ✓ 
  • pour faire du SSH sur les conteneurs / VMs : utiliser des ports différents afin d'éviter de devoir rebondir sur l'hôte
  • abandonner le FTP et tout faire en SFTP  fait ✓ 
• pondre une stratégie de routage Web
  • comment atteindre les VMs qui n'ont pas d'IP routables ?
    • proposition: mettre un serveur Web léger sur l'hôte genre Apache ou nginx (plus rapide mais pas de .htaccess, moins pratique à tuner en live) qu redirige le trafic sur les VMs
• réviser la stratégie de sauvegarde
  • faire un snapshot complet des VMs genre une fois par mois (voire à la main avant chaque grosse opération), pour faciliter la migration mais pas pour sauver les données  fait ✓ 
  • dans chaque VM, pousser les données vers Adansonia avec rsync comme actuellement  fait ✓ 
    • envoyer moins de données toutes les nuits (dumps de bases de données : deux ou trois seulement, et laisser Adansonia gérer l'historique)
    • vérifier les dates et heures de sauvegarde pour éviter d'avoir un jour de décalage sur les BDD etc.
    • compresser les dumps de base de données avec bzip2
    • compresser les dumps de base de données utilisateur par utilisateur et pas tous ensemble
    • essayer de compresser le flux (rsync avec gzip ?)
• Installer une sonde PHP pour Munin  fait ✓ 
• Installer Nagios, ou plutôt Shinken ( http://shinken.readthedocs.io/en/2.2/01_about/whatsnew.html )
• Installer  PostgreSQL pour tester les performances p/r  MySQL
• Installer une truite en plastique qui danse en fonction de la charge
• réorganiser cette liste

• Configurer les onduleurs pour qu'ils nous préviennent en cas de coupure !
  • si hébergement externe, obsolète (le courant sera ondulé et garanti sans coupure)  fait ✓ 

• L'appeler "Sequoia" et renommer l'ancien, ou le contraire ? Dans tous les cas faudra trouver un nouveau nom.
  • L'hôte s'appelle Osyris !  fait ✓ 

---