[Evolution et nouveau coup de gueule contre systemd] : Effacer les fichiers qui ne sont contenus dans aucun paquet
Sébastien Dinot a écrit :
> BERTRAND Joël a écrit :
>> Existe-t-il un moyen d'effacer tous les fichiers d'un répertoire qui
>> ne sont pas dans l'un des paquets installé sur le système (autre que
>> l'algo trivial qui doit être en n² consistant à chercher pour tous les
>> fichiers du répertoire s'ils apparaissent dans l'une des sorties de
>> dpkg-query -L xx) ?
>
> Cela me semble très délicat car des fichiers ou des liens symboliques
> peuvent ne pas être fournis par les paquets, mais bel et bien créés par
> eux lors de l'installation.
>
> J'ai trouvé la commande élégante et efficace pour identifier tous les
> paquets non fournis par les paquets sur Stack Exchange :
>
> https://unix.stackexchange.com/questions/153260/how-to-find-files-that-are-not-owned-by-any-package
>
> La commande est :
>
> comm -23 <(find / -xdev -type f | sort) <(sort -u /var/lib/dpkg/info/*.list)
>
> Mais cette liste constitue une base de travail brute, qu'il faut
> minutieusement affiner. Par exemple, il faut en exclure tout ce qui est
> dans /home et dans d'autres répertoires tels que /usr/lib, /var/log,
> voire /var, etc.
>
> Sébastien
>
Merci à tous, je vais regarder ça.
Néanmoins, il y a un problème connexe qui pourrait éviter de faire ce
que j'ai fait à la hussarde (recopier /bin /sbin et les libs d'une
installation fraîche puis certaines bibliothèques...). Pourquoi n'y
a-t-il pas dans une installation Debian la même chose que dans NetBSD
par exemple ? Lors des débuts de Linux, c'était compréhensible, les
disques n'était pas énormes. Aujourd'hui, ça l'est nettement moins.
legendre:[/rescue] > ls -al
total 2409644
drwxr-xr-x 2 root wheel 3072 May 23 17:31 .
drwxr-xr-x 25 root wheel 1024 May 24 23:57 ..
-r-xr-xr-x 155 root wheel 7811464 May 23 17:16 [
-r-xr-xr-x 155 root wheel 7811464 May 23 17:16 atactl
-r-xr-xr-x 155 root wheel 7811464 May 23 17:16 badsect
-r-xr-xr-x 155 root wheel 7811464 May 23 17:16 brconfig
-r-xr-xr-x 155 root wheel 7811464 May 23 17:16 bunzip2
-r-xr-xr-x 155 root wheel 7811464 May 23 17:16 bzcat
-r-xr-xr-x 155 root wheel 7811464 May 23 17:16 bzip2
-r-xr-xr-x 155 root wheel 7811464 May 23 17:16 cat
-r-xr-xr-x 155 root wheel 7811464 May 23 17:16 ccdconfig
-r-xr-xr-x 155 root wheel 7811464 May 23 17:16 cgdconfig
-r-xr-xr-x 155 root wheel 7811464 May 23 17:16 chgrp
-r-xr-xr-x 155 root wheel 7811464 May 23 17:16 chio
-r-xr-xr-x 155 root wheel 7811464 May 23 17:16 chmod
...
-r-xr-xr-x 155 root wheel 7811464 May 23 17:16 tetris
-r-xr-xr-x 155 root wheel 7811464 May 23 17:16 ttyflags
-r-xr-xr-x 155 root wheel 7811464 May 23 17:16 tunefs
-r-xr-xr-x 155 root wheel 7811464 May 23 17:16 umbctl
-r-xr-xr-x 155 root wheel 7811464 May 23 17:16 umount
-r-xr-xr-x 155 root wheel 7811464 May 23 17:16 veriexecctl
-r-xr-xr-x 155 root wheel 7811464 May 23 17:16 vi
-r-xr-xr-x 155 root wheel 7811464 May 23 17:16 vnconfig
-r-xr-xr-x 155 root wheel 7811464 May 23 17:16 vndconfig
-r-xr-xr-x 155 root wheel 7811464 May 23 17:16 wdogctl
-r-xr-xr-x 155 root wheel 7811464 May 23 17:16 wsconsctl
-r-xr-xr-x 155 root wheel 7811464 May 23 17:16 zcat
-r-xr-xr-x 155 root wheel 7811464 May 23 17:16 zegrep
-r-xr-xr-x 155 root wheel 7811464 May 23 17:16 zfgrep
-r-xr-xr-x 155 root wheel 7811464 May 23 17:16 zgrep
legendre:[/rescue] > du -hs
20M .
legendre:[/rescue] >
Tous les utilitaires critiques sont naturellement dans /bin et /sbin,
mais sont aussi compilés statiquement dans /rescue (façon busybox, le
même programme (presque toujours) avec des liens hard, la détection de
la fonction étant faite par argc dans le code). Ces fichiers ne sont pas
effaçables directement par root (un rm -f demande explicitement si on
est d'accord parce les droits sont r-x). Même en cas de destruction
d'une partie de la racine par un script foireux, on peut toujours
redémarrer le NetBSD en passant /rescue/sh comme init et même tourner
quasiment normalement avec un lien de /bin et /sbin sur /rescue. C'est
vraiment très pratique.
Le problème qui ma posé le plus de souci n'est pas le contenu de /bin
ou /sbin, il n'y a pas tant de bibliothèques que cela, mais un truc
aussi bête que apt (pour forcer la réinstallation des paquets). Parce
que apt est lié avec un tas de bibliothèques qui en utilise à son tour
d'autres. J'ai dû bricoler avant d'obtenir un apt qui fasse autre chose
qu'un segfault.
Sinon, autre bug de systemd (vous allez dire que je n'aime pas l'outil,
certes, mais je l'aime de moins ne moins à mesure que le temps passe)
sur lequel j'ai passé quelques heures hier.
bertrand@rayleigh:~$ cat /etc/udev/rules.d/70-persistent-net.rules
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="50:46:5d:72:ef:a2", ATTR{dev_id}=="0x0",
ATTR{type}=="1", KERNEL=="eno*", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:08:02:af:da:70", ATTR{dev_id}=="0x0",
ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:08:02:af:da:71", ATTR{dev_id}=="0x0",
ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"
Ce script NE FONCTIONNE PLUS (plus exactement, udev fonctionne, mais
systemd sait mieux que moi ce que je veux faire). Les cartes eth1 et
eht2 sont une carte Intel double port. L'énumération par le noyau
5.6.0-2-amd64 se fait comme suit :
00:08:02:af:da:70 => eth0
00:08:02:af:da:71 => eth1
renommés immédiatement en eth1 et eth2, respectivement (enfin, je
suppose puisque la seconde carte est reconnue initialement en eth1).
50:46:5d:72:ef:a2 => eth1 (pourquoi ?) que udev tente de renommer en
eth0 et qui se prend un "failed" parce que eth0 est déjà utilisé et qui
devient eno1. Là, ça sent bon le problème d'accès concurrent puisque
eth0 et eth1 devraient être renommées en eth1 et eth2 de façon atomique
pour systemd. Or si le noyau associe eth1 à la seconde carte, c'est que
eth1 a été renommé en eth2, et s'il se vautre sur le renommage de eth1
en eth0, c'est parce que eth0 n'a pas encore été renommée en eth1 (soit
parce que eth1 est occupée, mais il n'y a aucune trace dans les logs,
soit que systemd démarrant tout en même temps, il se marche une fois de
plus sur les pieds).
Résultat des courses, systemd se vautre lamentablement partout parce
que apache attend l'activation du LAN pour monter, qu'un tas de services
attendent après apache, bref...
Solution, renommer les interfaces, dans mon cas, j'ai fait au plus simple :
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="50:46:5d:72:ef:a2", ATTR{dev_id}=="0x0",
ATTR{type}=="1", KERNEL=="eno*", NAME="lan0"
Mais ça signifie aussi passer sur toute la configuration de la machine
en remplaçant partout "eth0" par "lan0". Je précise à tous fins utiles
que le responsable n'est pas le noyau. Le même noyau avec systemd 244
fonctionne comme attendu. J'ai déjà eu ce gag il y a quelque temps, la
solution fut toute autre. J'avoue que ce genre de chose m'énerve. Il n'y
a plus aucune fiabilité dans le processus de démarrage de Linux (il y a
vraiment beaucoup de gens qui râlent après ce nouveau bug). On passe les
patches de sécurité, on redémarre confiant une machine à 500 bornes et,
paf, les interfaces réseau changent de nom. Pratique lorsqu'on a
firewall sur la machine et que le port n'est pas ouvert sur le nom de la
nouvelle interface, on peut même perdre le ssh !
J'avais un mauvais a priori sur systemd lorsque ce truc est apparu.
Plus le temps passe et plus je considère que c'est le fossoyeur de
Linux. D'autant que l'API a changé une fois de plus et que certains
mots-clef utilisés dans les unités sont maintenant ignorés (une partie
de ce qui touche à la gestion des priorités système). Je n'ai pas encore
creusé, mais je me tape des tas de warning avec la version 245 alors que
les unités étaient parfaitement traitées avec la 244.
Bien cordialement,
JKB
Reply to: