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