Forum Linux.debian/ubuntu Énorme connerie, sauvez moi !

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
6
10
mar.
2019

Bonjour à tous,

Je viens de faire une connerie monstrueuse sur mon serveur de prod, aidez moi, SVP, vraiment !

Étant connecté au shell, en SSH, j'étais en train de bricoler diverses choses d'administration.

Sauf que mon clavier a ripé et j'ai lancé cette commande infernal :
"sudo chown -R userquelconque:groupquelconque ./dossierquelconque /"

au lieu de :
"sudo chown -R userquelconque:groupquelconque ./dossierquelconque/"

Vous comprenez la petite subtilité de connard (oui, je m'insulte) ?

Je viens de changer les droits d'utilisateur de tout mon système (sauf les dossiers protégés et read-only).

Pensez vous qu'il existe une possibilité de restaurer les droits d'accès ? (ceux du systèmes, ceux de mes utilisateurs ne sont pas vraiment problématiques, j'ai de quoi restaurer).

Merci d'avance

  • # Autre solution que réinstall?

    Posté par  . Évalué à 2. Dernière modification le 10 mars 2019 à 21:10.

    Si tu as la réponse, ça m'intéresserait, parce que ça m'est déja arrivé sur une machine perso, et ça s'est fini par une réinstall.

    • [^] # Re: Autre solution que réinstall?

      Posté par  . Évalué à 1.

      J'ai des sauvegardes de tous mes virtualhosts, faut juste que je fasse une sauvegarde de mes confs, et ça devrait aller.

      mais d'ici là, si y'a une autre solution que la réinstall, ça m'intéresse.

      • [^] # Re: Autre solution que réinstall?

        Posté par  . Évalué à 3. Dernière modification le 10 mars 2019 à 21:48.

        mon premier réflexe serait de forcer la réinstallation de tous les packages ?

        apt reinstall $(dpkg -l | awk '{print $2}')

        Je viens d'essayer en modifiant l'utilisateur propriétaire d'un fichier puis en réinstallant le package concerné et cela semble résoudre le souci.

        Par contre ça ne corrige pas l'utilisateur propriétaire des dossiers, mais si c'est pour du temporaire, tu peux tenter un chown root:root uniquement sur les dossiers puisque les permissions n'ont pas été touchées. Ce n'est pas forcément safe, mais ca peut dépanner.

        Attention aux éventuels effets de bord que je n'ai absolument pas anticipé !

  • # dpkg --audit

    Posté par  (site web personnel) . Évalué à 5.

    La commande dpkg --audit devrait t'aider à cibler un certain nombre de points problématiques, en utilisant les infos de dpkg. Cela ne résoudra pas tout mais…

    Debian Consultant @ DEBAMAX

  • # Ouais, je connais le chemin.... ---------> []

    Posté par  . Évalué à 7.

    …

    serveur de prod

    …

    bricoler

    …

    mon clavier cerveau a ripé

    (je compatis quand même hein, malgré les sarcasmes).

  • # pas glop

    Posté par  . Évalué à 2.

    J'ai déjà vu un chmod plutôt que chown, et franchement, je ne sais pas dire lequel est le pire (parce que le chmod fait des ravages dans /dev/). On s'en était sorti en recopiant les permissions de la machine ayant la config la plus proche (en hardware et version d'OS) qu'on avait sous la main. C'était pas marrant, et c'était pas parfait, mais pour du patch temporaire en attendant une maintenance de fond en comble, c'était mieux que rien.

    Bon courage

  • # À creuser

    Posté par  . Évalué à 2. Dernière modification le 10 mars 2019 à 21:50.

    Restaurer le backup de ton virtualhost de prod dans un coin et creuser un peu du côté de

    chown --reference

    histoire de cloner l'ownership des fichiers de ton restore vers ta prod ?

    Genre là

    • [^] # J'ai creusé

      Posté par  . Évalué à 1. Dernière modification le 15 mars 2019 à 21:35.

      Une solution qui fonctionne est :

      1. Restaurer tout ton virtualhost cassé quelque part dans un coin quelconque sur une machine quelconque. On appellera ça "/source"

      2. Sauvegarder les ACLs depuis ce que tu viens de restaurer
        getfacl -R /source/ > acls.txt

      3. Modifier le contenu de acls.txt pour que ça colle avec les paths de ta prod cassée (à grands coups de sed par exemple)

      4. Restaurer les ACLs sur ton filesystem de prod
        setfacl --restore=acls.txt

      Je me doute que l'urgence est passée et que, depuis, tu as été remercié engueulé viré mais je me suis dit que ça pourrait peut-être servir à quelqu'un d'autre un jour.

  • # CTRL+Z.

    Posté par  . Évalué à 4.

    Pardon…

    (Bon courage)

    • [^] # Re: CTRL+Z.

      Posté par  (Mastodon) . Évalué à 3.

      Plus sérieusement, il n'y a pas des FS qui le permettent ?

      Tu fais un snapshot, tu fais tes bidouilles, merde tu as fais (encore) une connerie => undo !

      Là je pense qu'on a le use-case parfait.

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: CTRL+Z.

        Posté par  . Évalué à 3.

        Plus sérieusement, il n'y a pas des FS qui le permettent ?

        Btrfs. Système de fichier par défaut d’openSUSE.
        Et il fait un snapshot automatiquement lors d’une mise à jour du système, donc si on n’efface pas le dernier et qu’on fait des mises à jour assez souvent, on peut retourner à un état cohérent pas trop vieux en cas de grosse erreur.

        Sinon Red Hat, qui a abandonné Btrfs (les développeurs Btrfs sont chez SUSE… eux, ils ont plutôt les développeurs de XFS), se dirige vers un fonctionnement similaire en utilisant les snapshots de LVM. Je ne sais pas où ils en sont.

        Quelle que soit la distribution, on peut toujours faire des snapshots « à la main », pour peu qu’on utilise LVM ou Btrfs (enfin pas sur Red Hat, donc ; je ne sais pas pour Fedora)… et qu’on y pense.

        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

        • [^] # Re: CTRL+Z.

          Posté par  . Évalué à 2.

          Fedora et la prochaine version de Redhat, utilisent snapper pour faire leurs snapshots. Donc cela marche avec LVM et BTRFS.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.