Soit l'erreur suivante lors d'un apt-get update :

« E: Erreur de GPG : ftp://ftp.uk.debian.org stable-updates InRelease : Les signatures suivantes ne sont pas valables : NODATA 2 »

Solution :

Keep an eye on your /tmp/ -- I had run out of disk space

Dans mon cas, j'avais monté un tmpfs trop petit sur /tmp.

C'est très vicieux comme message d'erreur car ça foire pour une seule distribution d'un dépôt apt (ici : jessie-updates), toujours le même donc on est tenté d'accuser ce dépôt…

Bref, pensez à bien dimensionner vos tmpfs. Attention : bien dimensionner, ça ne veut pas dire de se contenter de doubler/tripler la valeur affichée par un du -hs pour en prévoir l'usage. Nonononono.

Il y a des logiciels (apt, mysql, etc.) qui écrivent de gros fichiers temporaires de manière instantanée (même un while true ne permet pas de les voir avec leur taille complète, pour donner un ordre de grandeur). MySQL y écrit le temps d'une requête (et si vous utilisez tiny tiny rss en conservant beaucoup d'items bah il vous faudra un /tmp de plusieurs centaines de Mo), apt y écrit le temps d'un update, etc.

Pensez aussi à un upload HTTP traité par PHP (fichier ou même envoi d'un billet de blog, voir http://shaarli.guiguishow.info/?ShqsQg ) : le fichier sera temporairement stocké dans /tmp. Votre tmpfs devra donc être plus grand que upload_max_filesize et post_max_size.

Pour rappel : l'espace d'un tmpfs n'est pas pré-réservé : il n'est pas consommé en RAM tant qu'il n'est pas utilisé. Seule la quantité utilisée est consommée en RAM. ;)

Perso :

• Sur un serveur (ou un laptop ou autre) qui a 4G de RAM ou plus, je n'hésite pas : 1G sur /tmp direct ;
  
  
• Sur un serveur plus modeste en RAM (1G, 2G) avec un usage faible (mail, jabber, etc.), je file 20M de tmpfs ;
  
  
• Sur une machine modeste en RAM avec un usage conséquent (site web fréquenté, tiny tiny rss, etc.), je file 500M.

Sur des machines équipées de SSD (ou de DRBD), je monte aussi des tmpfs là où les applications web écrivent des données temporaires. Genre /var/tmp (mais attention à allouer suffisamment d'espace, genre 50M car mkinitramfs et autres écrivent ici le temps d'une mise à jour), genre tmp et cache de shaarli ou data/cache de dokuwiki ou le système de cache d'un CMS.

Merci à b4n ( http://ban.netlib.re/shaarli/ ) qui a su jouer de la pokéflute auprès d'un moteur de recherche pour obtenir la bonne réponse. \o/ Je ne trouvais rien à part des histoires de proxy ou de corruption de la base de données apt ou du keyring… Et oui, je case pokéflute pour faire genre que je suis à la mode.

Pour la première fois en plus de 10 ans, le S.M.A.R.T. a prédit une panne sur un de mes disques durs ! Une panne parmi toutes les pannes de disques (facilement une bonne 15aine) que j'ai connue !

Comme c'est absolument incroyable (waaaaaah le S.M.A.R.T qui prédit quelque chose ! Cheppa si vous réalisez !) et qu'il faut fêter ça, je me suis dit que j'allais m'intéresser à la configuration de smartd, le démon qui permet de vérifier régulièrement (toutes les trente minutes par défaut, ça se change dans /etc/default/smartmontools) que vos disques durs / SSD vont bien et/ou de vous envoyer un mail ou un message syslog quand ça ne va pas.


Pour une doc' sur la manipulation de smartctl, outil qui permet d'afficher les infos S.M.A.R.T. , j'aime vraiment beaucoup celle d'Ubuntu : https://doc.ubuntu-fr.org/smartmontools .

Pour une doc' sur smartd, le fameux démon que j'ai déjà présenté, la doc' pointée par ce shaarli fait le job.


Et voici, en une ligne, la config smartd.conf que j'utilise (elle me semble être une bonne base de départ) :

/dev/sda -d sat -H -l error -l selftest -s S/../01/./06 -m root

Pourquoi j'indique un disque dur en particulier au lieu de DEVICESCAN qui scannerait tous les disques et trouverait sda ? Parce que, dans mon cas, c'est un serveur qui aura toujours un seul disque dur. Il n'est pas prévu d'en ajouter. Inutile de perdre du temps à scanner et a potentiellement se vautrer.

-d sat permet de préciser le type de disque dur pour pas que smartd utilise des commandes SCSI sur un disque SATA et inversement. En vrai, osef de préciser ça, smartd trouve tout seul le type de disque dans l'écrasante majorité des cas (sauf bug du firmware, quoi). sat signifie que mon sda est derrière un adaptateur SCSI to SATA.

Que fait cette commande ?

• Smartd va surveiller l'état global du disque (-H), c'est-à-dire les attributs (comprendre les indicateurs, les métriques) pré-fail (qui indiquent que le disque va mourir bientôt) + le journal général des erreurs (-l error) + le journal des tests (-l selftest). Si les attributs préfail passent en dessous du seuil défini ou si le nombre d'erreurs dans le journal général ou le journal des test a augmenté, alors smartd envoie un mail à root.
  
  
• De plus, smartd va programmer (-s) un short test (le « S ») le premier jour de chaque mois à 6 heures du mat'. Si ce test détecte quelque chose, « -l selftest » fera que smartd vous enverra un mail. Oui, cron, c'est pour les chiens, il veut mieux réinventer son propre système. Pfff.

Notes :

• Pour que l'envoi de mail fonctionne, il faut qu'un MUA (client mail) soit installé sur la machine et disponible en /usr/bin/mail . Et évidemment, il faut aussi un MTA (serveur mail) pour acheminer le mail. Soit un vrai de vrai genre exim ou postfix, soit ssmtp (voir http://shaarli.guiguishow.info/?Qn9K_Q ) ;
  
  
• Pour tester l'envoi de mail, on peut ajouter « -M test » et systemctl reload smartd.service. Un mail bidon doit arriver ;
  
  
• Non, je n'ai pas programmé de long test, de conveyance test, d'offline test, de bidule test… Stop la parano.

Tout est dans le titre de ce shaarli : encore en 2016, il faut toujours mettre au moins une adresse IPv4 d'un récursif DNS dans /etc/resolv.conf , même en dernière position. Sinon des logiciels seront incapables de résoudre les noms de domaine. Un exemple ? mtr : « No nameservers defined. »

J'avais toujours compris qu'il ne faut jamais utiliser allow-hotplug comme un équivalent à auto dans un fichier interfaces.

Récemment, j'ai encore entendu le contraire mais je ne savais pas argumenter ma version. Maintenant que j'ai la réponse, je la note ici pour ne pas remettre ça en question encore une fois. :-

allow-hotplug n'est pas équivalent à auto.

Pour auto, le man nous dit :

Lines beginning with the word "auto" are used to identify the physical interfaces to be brought up when ifup is run with the -a option. (This option is used by the system boot scripts.)

Pour allow-hotplug, le man nous dit :

Lines beginning with "allow-" are used to identify interfaces that should be brought up automatically by various subsytems. This may be done using a command such as "ifup --allow=hot‐plug eth0 eth1", which will only bring up eth0 or eth1 if it is listed in an "allow-hotplug" line. Note that "allow-auto" and "auto" are synonyms.

Voilà : allow-XXXXXX attend un événement d'un sous-système. Forcément, au boot, on reçoit l'événement "la carte réseau devient up" ce qui donne l'illusion qu'allow-hotplug = auto. Mais, en réalité, allow-hotplug attend un retour de l'API udev. Et si l'on vire udevd ? Une interface en auto continue à monter au boot, une interface en allow-hotplug ne monte plus automatiquement.

Pourquoi virer udevd ?

• Parce que c'est parfois un peu la grouille quand ça se cumule avec systemd dans un LXC.
• Parce qu'il n'y en a pas besoin dans une machine virtuelle à usage serveur ou dans un LXC.

Attention si vous sauvegardez vos systèmes avec tar. C'est super mega simple et pratique à restaurer mais il y a des petites choses à savoir :

--numeric-owner

Par défaut, tar sauvegarde les UID et GID sous forme textuelle. Ça veut dire qu'il lit le UID+GID d'un fichier, qu'il regarde à quoi ces ID correspondent dans /etc/{passwd,group} et qu'il sauvegarde les intitulés qu'il a trouvés. Ça suppose deux choses :

1- que l'utilisateur et le groupe existent lors de la restauration ;
2- de créer l'archive sur le système lui-même.

Exemple : si vous sauvegardez vos LXC depuis l'hôte, c'est bien les fichiers /etc/{passwd,group} de l'hôte qui seront utilisés pour faire la traduction numéro->nom, pas les /etc/{passwd,group} de votre LXC donc, quand vous restaurerez votre sauvegarde, vous aurez des fichiers/dossiers qui n'appartiennent pas aux bons utilisateurs, ce qui empêchera les logiciels de démarrer.

Pour éviter cela, il faut utiliser --numeric-owner lors de la sauvegarde.

--xattrs

Par défaut, tar ne sauvegarde pas les file capabilities, ces droits très précis/fins que l'on accorde à une application au lieu de les setuid/setgid (ce qui leur donne plus de droits que ce dont elles ont besoin). L'exemple classique est ping, à qui on attribue la capability « cap_net_raw » pour qu'il puisse créer des sockets raw ICMP.

Pour sauvegarder les capabilites, il faut utiliser --xattrs lors de la sauvegarde. Il y a visiblement une subtilité lors de la restauration : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775495 .

Je parle des file capabilites mais c'est la même chose pour les ACL POSIX et/ou les contextes SELinux : tar ne les sauvegarde pas par défaut, il faut le demander explicitement.

Autant réparer une restauration qui n'a pas les bons UID/GID, c'est compliqué sans connaître les permissions d'origine (mais on peut les retrouver depuis les scripts de post-installation mais ça nécessite de retrouver quel package a livré tel fichier/dossier et ça, c'est chiant), autant réparer les capabilites, ça se fait plutôt bien. Les capabilites ne sont pas positionnées dans l'archive tar contenue dans un paquet debian (.deb, tout ça). dpkg ne s'en occupe pas non plus. C'est les scripts de postinstall qui s'en occupent. Il suffit donc de lire tous ces fichiers et de retrouver ceux qui affectent des capabilites : grep -R "setcap" /var/lib/dpkg/info/*.postinst. Il suffit d'exécuter manuellement les commandes setcap que l'on trouve et c'est réglè.

Pas de relatif

Si vous faites une sauvegarde relative, du genre cd / && tar --exclude='./tmp' --exclude='./dev' -cpJf save.tar.lzma ., ça complique la restauration : il vaut mieux faire : cd / && tar -cpJf save.tar.lzma bin boot [...]. Il faut réaliser la backup depuis la racine si l'objectif de la sauvegarde est de restaurer tout un système d'un coup.

Petite info intéressante qui va dans ce sens : on peut tar xf une arborescence sur un système en fonctionnement (genre cd / && tar xf save.tar.lzma) mais on ne peut pas cp ou mv une arborescence sur un système en fonctionnement (ici, rootfs est le dossier extrait par tar) :

# cp -R rootfs/* /
cp: cannot create regular file '/bin/bash': Text file busy
cp: cannot create regular file '/bin/cp': Text file busy
cp: cannot create regular file '/lib/x86_64-linux-gnu/ld-2.19.so': Text file busy

Je n'explique pas la différence entre tar et cp… tar est aussi lancé par bash et il utilise aussi la libld-2.19 située dans le même répertoire…