Je travaille sur une machine Linux exécutant Ubuntu Bionic Beaver, version 18.04.
L’autre jour, j’ai modifié par erreur le /usr/
répertoire appartenant à un utilisateur plutôt qu’à un compte root. Malheureusement, je l'ai fait de manière récursive et j'ai donc perturbé une bonne partie du système car il a également modifié les suid
autorisations sur certaines des commandes (par exemple passwd
, sudo
). Nous ne pouvons vraiment pas réinstaller (mais nous pouvons le faire, mais ça va coûter!), Alors j’ai démarré à partir de LiveUSB et modifié manuellement tous les droits utilisateur / groupe / autorisations appropriés pour chaque fichier que j’avais pu identifier Root:Root
. . Je l’ai fait en comparant la sortie d’un autre ordinateur Ubuntu ls -lha /usr/
.
Cela semble être en grande partie résolu, mais maintenant, je rencontre l'erreur 'std :: bad_alloc' après l'exécution de scripts python assez standard. La partie étrange à ce sujet est que cela ne vient que parfois. Par exemple, si j’ouvre python à partir de la ligne de commande et que je copie et colle du code, le code s’exécutera sans erreur. Cependant, si j'exécute l'intégralité du script à partir de la ligne de commande (par exemple python script.py
), j'obtiens cette erreur. Le message d'erreur complet est:
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Aborted (core dumped)
Mais pour ajouter une autre tournure - parfois je peux exécuter le même script python à partir de la ligne de commande sans aucun problème, et d’autres j’obtiens cette erreur comme ci-dessus.
Si quelqu'un a des idées sur les endroits où chercher spécifiquement pour résoudre ce problème, ce serait génial! Je vais essayer de faire la même chose qu'avant, mais avec la ls -lha /usr/
sortie d'une version 18.04, car je n'avais qu'une sortie en version 16.
la source
/usr
, vous risquez de manquer un fichier avec des autorisations incorrectes rendant votre système vulnérable.apt-get reinstall python2
ouapt-get reinstall python3
depuis un terminal root pourrait faire l'affaire. Et c'est plus facile que de réinstaller le système entier.Réponses:
Réinstallez tous les paquets Debian qui impliquent
/usr
Exécutez cette commande pour dire
apt
de réinstaller chaque paquet qui place des fichiers dans/usr
:Avertissement: La réinstallation se produit sans invite de confirmation.
Si vous recevez un message comme
où
PACKAGE-NAME
est un paquet impossible à obtenir, vous pouvez exclure le paquet pour la réinstallation de la manière suivante:Vous pouvez chaîner autant de
grep -v
commandes que nécessaire.Explication
Il est possible que le système Ubuntu que vous avez comparé ne possède pas les mêmes packages, ce qui signifie qu'il pourrait y avoir plus de fichiers avec les mauvaises autorisations
/usr
.En
apt
réinstallant les packages, vous pouvez être sûr que tous les fichiers/usr
installés par le système d’exploitation disposent des autorisations voulues.Réinstaller tous les paquets pip
Cette section suppose que vous avez installé les packages Python avec en
pip
tant que root.Exécutez cette commande pour réinstaller tous les packages pip:
Exécutez cette commande pour supprimer les fichiers de bytecode Python:
Explication
Étant donné que votre problème concerne Python, je suppose que vous avez peut-être installé des packages Python à l’échelle du système dans des chemins tels que
/usr/local/lib/python2.7/dist-packages
et/usr/local/lib/python3/dist-packages
.Lorsque l'interpréteur Python s'exécute, il crée également des fichiers de code intermédiaire (
*.pyc
), dont les autorisations ont peut-être également été affectées lorsque vous avez gâché de manière récursive les/usr
autorisations de votre dossier. La suppression des.pyc
fichiers garantit que Python les régénérera à la prochaine exécution de vos scripts.Réinstaller tous les paquets Debian
Si réinstaller uniquement les paquets impliquant un répertoire ne résout pas votre problème, il existe une option plus extrême.
Exécutez cette commande pour dire
apt
de réinstaller chaque paquet sur le système:Avertissement: La réinstallation se produit sans invite de confirmation.
Explication
Peut-être que quelque chose en dehors de votre
/usr
dossier a éclaté.C'est ce que j'ai découvert le 07 février 2018 lorsque j'ai découvert qu'un hyperviseur Debian 8 (Jessie) de production s'était écrasé. Le nœud n'est pas entré en ligne après un redémarrage.
Lorsque j'ai chargé une image de secours Ubuntu, je ne pouvais même pas
chroot
entrer dans l'hyperviseur endommagé, car/bin/bash
une erreur de segmentation (un peu comme votre script Python annulé) m'a été donnée. En fait, la plupart des fichiers système étaient en quelque sorte corrompus.Il y avait une machine virtuelle de production sur cet hyperviseur qui nécessiterait beaucoup d'efforts pour être redéployé ailleurs à cause de l'état défaillant de l'hyperviseur. J'ai donc pensé à essayer une réparation.
J'ai copié de bons fichiers binaires et de bibliothèque connus de Debian 8 dans la machine jusqu'à ce que je sois capable de les
chroot
exécuterapt
et de les exécuterdpkg
. À partir de là, je pourrais vous demanderapt
de réinstaller tout le système.Après avoir traité quelques bizarreries de paquet, chaque paquet a réussi à être réinstallé. Une fois que j'ai redémarré, le serveur est revenu comme s'il n'avait jamais été corrompu.
J'ai dû redéployer les packages Python du serveur séparément car ils étaient également étrangement corrompus, mais au moins la machine virtuelle de production n'a pas été endommagée.
Il est possible de réparer un système gravement endommagé en réinstallant ce que vous pouvez. Pour l’avenir, il est recommandé de rendre les versions de votre serveur aussi reproductibles que possible, afin que, si vous rencontrez des problèmes d’ accident dans votre logiciel , vous puissiez facilement réorganiser le système avec un minimum d’effort.
la source