Hier soir a été un de ces moments où les doigts fonctionnent plus vite que le cerveau pour moi. J’ai mis à genoux le serveur qui héberge feub.net, bon nombre d’autres domaines et un serveur de messagerie pour ne citer que les services les plus importants, juste parce que je n’ai pas réfléchi avant d’agir et il m’a fallu trois bonnes heures pour corriger mes dégats.
N’ayant jamais eu à gérer un nombre dingue de domaines et d’hébergements, je fais tout à la main (DNS, httpd/vhost, etc), mais j’ai voulu essayer un panneau de gestion d’hébergements open source, en l’occurence ZPanel et ça a été le début de la fin.
Je précise que je m’attribue la faute et non à cet outil que je vais ré-installer à la main pour finalement l’essayer, car tout vient de là, j’ai vu un installeur pour CentOS disant « Install a clean CentOS server with ZPanelX », je n’ai pas cherché plus loin, après une longue journée, plutôt flémard, je n’ai pas lu la doc, je me suis dit CentOS <--> Fedora (15 en plus) c’est kiffe-kiffe, go…
Le script se lance et commence par un yum remove bind-chroot, mes yeux enflent, le script se poursuit, modifie la configuration d’Apache, il y a bon nombre d’erreurs, mais cela va trop vite pour voir exactement lesquelles. Le script se termine par un…. reboot. J’avais un uptime de plus d’un an, tout tournait bien.
Le reboot ne donne rien, le ping répond, mais pas d’accès SSH. Je fais un hard reboot pendant que je reçois pas mal d’alertes d’OVH comme quoi ma machine ne répond plus, SSH down, DNS down.. Le hard reboot met un temps fou avant d’avoir enfin la main.
Je me connecte enfin, difficilement. Je commence par un yum install bind-chroot, mais que dalle, je n’ai pas d’accès à l’extérieur, pas de yum, pas de wget, NetworkManager a pris la main sur le service network, le resolv.conf est vide. Je corrige ça. Après des tentatives diverses infructueuses, j’opte pour le téléchargement du RPM bind-chroot sur la machine sur laquelle je travaille, j’uploade en SFTP et j’installe avec un yum localinstall. Named est reparti c’est déjà ça.
La suite du problème a été avec Apache, le script d’installation de ZPanel ayant fait diverses modifications, mais ne sachant pas exactement lesquelles, j’ai préféré repartir sur la sauvegarde de la veille (merci à mon plan de sauvegarde qui semble bien tourner).
Tous les fichiers sous /etc/httpd remis en place, les répertoires zpanel sous /etc et /usr/quelquechose détruits, je lance un systemctl start httpd.service, mais le job échoue.. Après un peu d’investigation des fichiers de logs, le problème était simplement qu’étant reparti de fichiers de configuration de sauvegarde, certains liens symboliques étaient vus comme de simples fichiers, j’avais ça :
$ ls -l /etc/httpd/ total 8 drwxrwxr-x 2 root root 4096 Mar 24 21:34 conf drwxrwxr-x 2 root root 4096 Mar 24 20:19 conf.d -rwxrwxrwx 1 root root 19 Mar 24 21:30 logs -rwxrwxrwx 1 root root 29 Mar 24 21:31 modules -rwxrwxrwx 1 root root 20 Mar 24 21:31 run
A la place de ça :
$ ls -l /etc/httpd/ total 8 drwxrwxr-x 2 root root 4096 Mar 24 21:34 conf drwxrwxr-x 2 root root 4096 Mar 24 20:19 conf.d lrwxrwxrwx 1 root root 19 Mar 24 21:30 logs -> ../../var/log/httpd lrwxrwxrwx 1 root root 29 Mar 24 21:31 modules -> ../../usr/lib64/httpd/modules lrwxrwxrwx 1 root root 20 Mar 24 21:31 run -> ../../var/run/httpd/
Après avoir recréé ces liens, httpd a bien démarré. J’ai eu d’autres petits soucis du même ordre avec Postfix et Dovecot.
Tout semble être reparti comme en 40 ^.^ A voir. En tout cas, les leçons à retenir, toujours les mêmes :
- l’importance des sauvegardes
- penser avant d’agir bon dieu!
Crédit photo : Jean Spector