Mise à niveau de mon serveur vers Ubuntu 14.04. [Retour sur Upgrade]

Rédigé par monptitnuage - - 1 commentaire

Ce week end j'ai enfin eu le temps de faire la mise à niveau de mon serveur pour passer de Ubuntu 12.04 vers la version 14.04.
Avant toutes choses je m'étais renseigné sur le déroulement de l'opération car étant donné que mon serveur est dépourvu d'interface graphique je n'avais que pour seule option ma connexion SSH. Étant donné que j'utilise un serveur OVH j'ai donc utilisé la commande conseillée qui est un "do-release-upgrade" cependant lorsque j'ai fait le test, OVH conseil de ne pas effectuer l'upgrade avec une connexion SSH car s'il y a des erreurs pendant l'opération cela peut être beaucoup plus compliqué à rattraper.

J'ai donc continué les recherches puis c'est en suivant le conseil de Quentin demouliere et en me basant sur son article Mise à jour de debian Wheezy vers debian Jessie que j'ai découvert dans le fichier "sources.list" un lien concernant la procédure d'upgrade fourni par OVH.

En me rendant sur le lien on tombe sur le même type de commande conseillé par OVH "do-release-upgrade" ainsi que des infos sur les paquets mis à jour et les nouveautés. La curiosité l'ayant emporté sur les conseils, j'ai quand même voulu tester la commande "do-release-upgrade" sur une machine de test et finalement tous s'étant bien passé je me suis lancé.
Au final la commande "do-release-upgrade" à très bien fonctionné, au cours de l'opération j'ai eu trois informations concernant un changement de version pour rkhunter ainsi que pour libc6 et le GRUB. Pour chaque mise à jour des paquets vous avez plusieurs choix dont un qui est plutôt pas mal, c'est la possibilité d'afficher côte à côte les différences entre les versions.
Voilà pour ce qui est de la partie upgrade

Maintenant j'écris cet article surtout pour vous parler d'une grosse surprise que j'ai eu lorsque je voulais remettre mon site en prod. En effet, une fois mon serveur redémarré avec la nouvelle version d'Ubuntu je suis retourné sur le site pour vérifier que tous était ok mais là que ne fut pas ma surprise, je tombe sur une belle erreur 403 pour toutes mes url.
Je suis donc allé voir dans les fichiers de conf d'Apache et pourtant tous était ok, rien n'avait bougé par rapport à avant alors pourquoi cette erreur subite ?

Et bien le problème venait tous simplement du fait que Apache à changer de version et je suis donc passé sur la 2.4.7 qui utilise une nouvelle syntaxe. Si j'avais pris le temps de bien lire la documentation fournie par OVH j'aurais pu voir qu'effectivement Apache faisait partie des paquets mis à jour et qu'une documentation concernant la nouvelle syntaxe a été mise à disposition. Bref, d'où l'importance de lire les docs jusqu'au bout.

Je vous met ci-dessous les syntaxes qui changent :
Order deny,allow
Deny from all
devient
Require all denied

Order allow,deny
Allow from all
devient
Require all granted

Allow from 127.0.0.1 # Local
devient
Require ip 127.0.0.1 (surtout retirer le # Local car apparemment il ne l'accepte plus)

Allow from exemple.org # test
devient
Require host exemple.org (même chose, il faut retirer le # test)


Une fois tous ça mis à jour mon site devient de nouveau accessible mais ça ne s'arrête pas là car en effet lorsque je suis passé à la vérification de mes services comme le firewall, fail2ban, rkhunter, ... j'ai découvert que mon fail2ban ne fonctionnait plus.
Bon cette fois fail2ban n'apparaissait pas dans la doc de OVH, néanmoins les messages d'erreur lors du restart de fail2ban étaient explicites :

Première chose, on peut voir que fail2ban ne trouve pas le fichier de configuration "daemon.log". En effet, le fichier n'existe plus si l'on se rend à l'endroit indiqué par défaut dans fail2ban. De même, lorsque j'ai fais un locate daemon.log, il ne m'a rien trouvé. Comme cela engendre une erreur lors du redémarrage du service pour la surveillance de "xinetd-fail", j'ai donc créé moi même le fichier "daemon.log" dans /var/log. Je redémarre de nouveau fail2ban et cette fois il ne me reste plus qu'une erreur :

Maintenant le problème concerne le paramètre "ignoreregex" qui n'est pas définie dans le fichier /etc/fail2ban/filter.d/apache-auth.conf mais je n'y ai jamais touché étant donné que le paramètre "ignoreregex = " permet juste de définir des lignes de logs à ignorer et je n'en ai pas utilité.
J'ai donc laissé comme ça car je ne pense pas qu'il y aura un impact sur le fonctionnement de fail2ban.

Et pour finir, mon Logwatch avait également pris congé car n'étant plus actif je me suis donc rendu dans les dossier et fichiers de config qui, à mon grand étonnement ^^ étaient tous VIDE !
J'ai donc désinstallé et réinstallé Logwatch puis j'ai reconfiguré tous ça. Surtout n'oubliez pas de recréer le dossier "logwatch" dans "/var/cache" car pour moi étant donné que j'ai fais un aptitute purge logwatch, le dossier n'est pas créé automatiquement.

Voilà c'est tout ce que j'ai eu comme surprise cependant concernant la nouvelle syntaxe de Apache 2.4.7, je suis coupable, si j'avais lu la doc jusqu'au bout je n'aurais pas été étonné.

N'hésitez pas à lâcher un com si vous avez d'autres infos à passer ;)

Webmasteur et rédacteur du blog monptitnuage
Vous pouvez me suivre sur Twitter : @monptitnuage

1 commentaire

#1  - Marcus Binomi a dit :

Je vous applaudie par rapport à votre immense travail.

Répondre

Fil RSS des commentaires de cet article

Écrire un commentaire

Quelle est la quatrième lettre du mot ilnwo ?