Premier contact avec Debian 8 et systemd

Hello World !

Ah ça m’avait manqué un bon petit article technique ! J’ai réfléchi pour cet article si je le mettais ou pas dans server@home et finalement j’ai décidé que non. Il est davantage tourné vers le monde professionnel et ça me permettra de dégrossir le boulot pour un article propre et fini dans la série server@home.

D’un point de vue organisation je vous conseille le cheminement suivant (c’est celui que j’utilise actuellement) :
– Faites votre veille journalière avec les outils que vous avez choisi (en général lecteur de flux RSS, réseaux sociaux genre Twitter, livres ou magazines)
– Lisez les articles sur le futur projet/besoin que vous allez avoir à gérer et enregistrez-les sur votre Shaarli
– Le jour précédent ou le matin même où vous débutez votre projet, relisez les articles que vous avez accumulé dans votre Shaarli. Cela vous servira à vous rafraîchir la mémoire et ce sera une bonne base de documentation pour débuter
– Vérifier les sauvegardes du serveur sur lequel vous allez travailler et idéalement faites un test de restauration. Si votre serveur est une machine virtuelle, pensez à faire un snapshot
– Durant le projet prenez des notes sur les problèmes rencontrés et les solutions trouvées, cela vous servira toujours pour un autre serveur, un collègue ou pour rédiger de la documentation
– Tentez dans la mesure du possible (si vous avez le temps) de confirmer votre compréhension des problèmes et du projet ainsi que les solutions que vous avez trouvé en testant sur un autre serveur ou en revenant en arrière grâce au snapshot
– Laissez reposer deux semaines votre projet idéalement en checkant tous les jours car il est extrêmement rare que tout soit parfait dès le début : Sauvegarde, configuration du firewall, configuration du logiciel ou du serveur etc.
– Passez au serveur suivant ou au projet suivant

J’ai donc commencé par me rafraîchir la mémoire avec ces articles (exclusivement sur systemd car c’est le gros morceau du passage à Debian 8) ce que je vous invite à faire également :
http://linuxfr.org/news/systemd-l-init-martyrise-l-init-bafoue-mais-l-init-libere
http://linuxfr.org/news/systemd-pour-les-administrateurs-partie-1-et-2
http://linuxfr.org/news/systemd-pour-les-administrateurs-parties-3-4-et-5
http://linuxfr.org/news/systemd-version-216
http://geekeries.de-labrusse.fr/?p=2786 (en Français mais moins complet : http://carnetdevol.shost.ca/wordpress/aide-memoire-sur-les-commandes-associees-a-systemd/)


On débute toujours en mettant à jour tous les paquets de notre serveur.

Mes serveurs sont des machines virtuelles sur un ESXi (VMware) et Debian installe par défaut le paquet mpt-status car il considère que les disques en dessous sont en RAID (voir ce lien). Sur Debian 7 j’avais pris l’habitude de désactiver le service mais j’ai pu remarquer que la migration vers Debian 8 repassait le service en enabled. Par conséquent, je désinstalle purement et simplement.

Je passe en hold le paquet nagios-nrpe-server (je vous renvoie sur mon ancien article sur ce sujet).

On édite le fichier /etc/apt/sources.list et on passe le tout en Jessie.

On se lance en mettant à jour la liste des paquets disponibles depuis les dépôts Jessie puis en faisant l’upgrade vers Jessie.

Voici quelques remarques qui peuvent vous intéresser.

1) J’ai pour ma part eu l’erreur suivante : « /var/lib/dpkg/info/clamav-daemon.postinst: 626: /var/lib/dpkg/info/clamav-daemon.postinst: cannot create : Directory nonexistent dpkg: erreur de traitement du paquet clamav-daemon ».

On résout ce souci en modifiant $DEBCONFILE par $DEBCONFFILE en faisant une petite recherche sur $DEBCONFILE dans le fichier /var/lib/dpkg/info/clamav-daemon.postinst (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778507) puis on relance aptitude dist-upgrade.

2) Durant l’upgrade, on m’a invité à enlever lsof donc pour le remettre on lance aptitude install lsof.

3) J’ai les messages suivants dans les logs « rsyslogd-2007: action ‘action 4’ suspended, next retry is Mon Apr 20 11:50:21 2015 [try http://www.rsyslog.com/e/2007 ] », j’ai trouvé ce lien https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742113 mais je ne suis toujours pas arrivé à résoudre ce problème.

4) Je n’ai plus rien dans mes fichiers logs « classiques » (c’est-à-dire sans devoir passer par journalctl) et ça ne me plaît pas, on passe ForwardToSyslog=yes dans le fichier /etc/systemd/journald.conf puis on fait systemctl restart systemd-journald.

5) J’envoie les logs des différents serveurs à une machine qui centralise ces logs, rsyslog se charge de cela. Avec systemd la transmission du journal vers des machines distantes est facilitée grâce au nouvel outil systemd-journal-upload qui permet d’envoyer les données du journal à une machine distante exécutant systemd-journal-remote, je n’ai pas encore trouvé de tutos mais je me pencherai sur cette problématique.

6) Si vous éditez le fichier /etc/systemd/journald.conf, vous allez voir une option intéressante nommée Storage je vous invite à regarder la documentation à ce sujet. Je cite : « If « persistent », data will be stored preferably on disk, i.e. below the /var/log/journal hierarchy (which is created if needed), with a fallback to /run/log/journal (which is created if needed), during early boot and if the disk is not writable. « auto » is similar to « persistent » but the directory /var/log/journal is not created if needed, so that its existence controls where log data goes. » Vous devez avoir auto dans votre fichier, c’est l’option par défaut. Je trouve que c’est très con car comme beaucoup je n’ai pas créé le dossier /var/log/journal donc les logs sont dans /run une partition tmpfs de moins de 500 Mo dans la plupart des cas. Si c’est un serveur (à priori vous tenez donc à vos logs) alors vos logs disparaissent à l’extinction. Bref à moins que j’ai mal compris quelque chose, je vais passer cette option à persistent (notez que dans l’absolu ForwardToSyslog=yes rend inutile cette manipulation).

7) Globalement aucun problème de fonctionnement, tous les services sont passés à systemd sans problème (y compris des scripts installés en service).

8) Pour ceux qui ont des serveurs web, il faut faire très attention car on passe de Apache 2.2 à 2.4 et ne pas oublier la montée de version de php.

9) Pour ceux qui préfèrent apt-get à aptitude, petit rappel on peut maintenant utiliser apt tout court au lieu de apt-get (exemple : apt update && apt upgrade), il y a quelques différences mineures avec apt-get que vous pouvez découvrir en faisant man apt.

10) Je comprends en passant à Debian 8 les réticences et craintes vis à vis de systemd d’une partie de la communauté. Je ne suis ni pour ni contre car globalement je m’en fous mais il est clair que ça cannibalise certains fonctionnements. Je pense notamment aux logs et à rsyslog. Un article technique qui peut aider chez Red Hat pour la cohabitation de rsyslog et journal.

Bonne chance à tous ! Vos retours sont appréciés et je réponds aux questions si vous rencontrez des problèmes.

Déjà 8 avis pertinents dans Premier contact avec Debian 8 et systemd

« # Si vous avez déjà fait l’erreur voici comment revenir en arrière # »

Une manière de préserver (donc *préventivement*) certains paquets sensibles (en sus du hold) : dpkg-repack.

Concernant hold, doit y avoir une subtilité qui m’échappe (et cela depuis très longtemps, donc je n’utilise pas …)

Voilà, je hold cups (par exemple) / vérif :
hi cups 1.7.2-0ubuntu1

Et pourtant, juste après : apt-get install cups … me fait grimper dans la version suivante … !! Où est donc le blocage ? (*)

J’ai l’intuition que le blocage n’est qu’indirect (i.e. marche pas si demande directe concernant cups) … ou bien il y a un paramètre silencieux qui change tout…
??
(*) si je veux bloquer un paquet c’est également pour les cas où, en toute bonne foi, je fais pas gaffe …

Du coups je viens de prendre le temps de confirmer mon intuition (après plusieurs années ! ;-)
Effectivement, demander le retrait d’un paquet qui entraîne le retrait d’un paquet hold génère :
Les paquets suivants contiennent des dépendances non satisfaites :
deb-vda-systools : Dépend: gdebi mais ne sera pas installé
E: Erreur, pkgProblem::Resolve a généré des ruptures etc etc

Du coups, je vais enfin utiliser hold :)
Généralement, je construis des paquets virtuels (via equivs) qui mémorisent les paquets nécessaires sur telle ou telle machine… Mais il peut arriver que dans la bagarre, le paquet virtuel soit retiré avec l’eau du bain…
En mettant en hold les paquets virtuels, j’empêche de fait le retrait « involontaire » des dépendances…
C’est déjà ça.
Merci pour le petit pas dans le sens du progrès ;-)

Pour dpkg-repack, une utilisation qui peut être … bénéfique :
* à un instant t (« runtime »), détecter les binaires (ou librairies) en cours d’utilisation (via lsof)
* associer à cette liste, la liste des paquets correspondants (via dpkg -S par exemple)
* pour cette liste de paquets, contrôler la disponibilité apt des paquets (via apt-show-versions)
* si un paquet n’est plus « visible » par apt, le « repacker » localement pour sauvegarde (dans un dépôt local ?)
Voilà, voilà, en mode barbare ça donne ça, au fil de l’intuition :
lsof | grep ‘/usr/bin’ | awk ‘{print $9}’ | grep ‘/usr/bin’ | xargs dpkg -S | awk -F « : » ‘{print $1}’ | xargs apt-show-versions | grep -v uptodate$ | awk -F « : » ‘{print $1}’ | xargs dpkg-repack

Y-a probablement plus élégant…

    EDIT : Mystère de l’encodage ou du copier-coller, les ‘ (apostrophes) de la commande donnée doivent être retapés… sinon, ça ne fonctionne pas…
      Envoies moi la ligne dans un fichier texte, je ferai un edit sur l’article et je rajouterai ton one-liner.

      Merci, Tcho !

Laisser un commentaire

indique des champs obligatoire.