I accidentally untarred archive intended to be extracted in root directory, which among others included some files for /etc directory.
I went on to rm -rv ~/etc, but I quickly typed rm -rv /etc instead, and hit enter, while using a root account.

    • underscores@lemmy.zip
      link
      fedilink
      English
      arrow-up
      56
      arrow-down
      2
      ·
      3 days ago

      I agree with this take, don’t wanna blame the victim but there’s a lesson to be learned.

      • neatchee@piefed.social
        link
        fedilink
        English
        arrow-up
        64
        arrow-down
        1
        ·
        3 days ago

        except if you read the accompanying text they already started the issue by accidentally unpacking an archive to their user directory that was intended for the root directory. that’s how they got an etc dir in their user directory in the first place

        • ThanksForAllTheFish@sh.itjust.works
          link
          fedilink
          arrow-up
          2
          arrow-down
          4
          ·
          3 days ago

          Could make one archive intended to be unpacked from /etc/ and one archive that’s intended to be unpacked from /home/Alice/ , that way they wouldn’t need to be root for the user bit, and there would never be an etc directory to delete. And if they run tar test (t) and pwd first, they could check the intended actions were correct before running the full tar. Some tools can be dangerous, so the user should be aware, and have safety measures.

          • neatchee@piefed.social
            link
            fedilink
            English
            arrow-up
            10
            ·
            3 days ago

            they acquired a tar package from somewhere else. the instructions said to extract it to the root directory (because of its file structure). they accidentally extracted it to their home dir

            that is how this happened. not anything like what you were saying

            • ThanksForAllTheFish@sh.itjust.works
              link
              fedilink
              arrow-up
              1
              ·
              edit-2
              13 hours ago

              I understand that they were intending to unpack from / and they unpacked from /home/ instead. I’m just arguing that the unpack was already a potentially dangerous action, especially if it had the potential to overwrite any system file on the drive. It’s in the category of “don’t run stuff unless you are certain of what it will do”. For this reason it would make sense to have some way of checking it was correct before running it. Any rms to clean up files will need similar steps before running as well. Yes this is slower, but would argue deleting /etc by mistake and fixing it is slower still.

              I’m suggesting 3 things:

              • Confirm the contents of the tar
              • Confirm where you want to extract the contents
              • Have backups in case this goes wrong somehow

              Check the contents:

              • use "tar t’’ to print the contents before extracting, this lists all the files in the tar without extracting the contents. Read the output and check you are happy with it

              Confirm where:

              • run pwd first, or specify “-C ‘/output-place/’” during extraction, to prevent output to the wrong folder

              Have backups:

              • Assume this potentially dangerous process of extracting to /etc (you know this because you checked) may break some critical files there, so make sure this directory is properly backed up first, and check these backups are current.

              I’m not suggesting that everyone knows they should do this. But I’m saying that problems are only avoidable by being extra careful. And with experience people build a knowledge of what may be dangerous and how to prevent that danger. If pwd is /, be extra careful, typos here may have greater consequences. Always type the full path, always use tab completion and use “trash-cli” instead of rm would be ways to make rm safer.

              If you’re going to be overwriting system files as root, or deleting files without checking, I would argue that’s where the error happened. If they want to do this casually without checking first, they have to accept it may cause problems or loss of data.

    • WatchfulConsole@sh.itjust.works
      link
      fedilink
      arrow-up
      2
      ·
      2 days ago

      I’ll provide some cover. This is my current home directory: bin/ bmp/ cam/ doc/ eot/ hhc/ img/ iso/ mix/ mku/ mod/ mtv/ mus/ pkg/ run/ src/ tmp/ vid/ zim/. It’s your home directory, enjoy it however you like.

    • Ephera@lemmy.ml
      link
      fedilink
      English
      arrow-up
      7
      ·
      3 days ago

      [OP] accidentally untarred archive intended to be extracted in root directory, which among others included some files for /etc directory.

    • vapeloki@lemmy.world
      link
      fedilink
      arrow-up
      2
      arrow-down
      3
      ·
      edit-2
      3 days ago

      So, you don’t do backups of /etc? Or parts of it?

      I have those tars dir ssh, pam, and portage for Gentoo systems. Quickset way to set stuff up.

      And before you start whining about ansible or puppet or what, I need those maybe 3-4 times a year to set up a temporary hardened system.

      But may, just maybe, don’t assume everyone is a fucking moron or has no idea.

      Edit Or just read what op did, I think that is pretty much the same

      • FauxLiving@lemmy.world
        link
        fedilink
        arrow-up
        2
        ·
        3 days ago

        But may, just maybe, don’t assume everyone is a fucking moron or has no idea.

        Well, OP didn’t say they used Arch, btw so it’s safe to assume.

        (I hate that this needs a /s)

    • palordrolap@fedia.io
      link
      fedilink
      arrow-up
      7
      ·
      3 days ago

      I dunno, ~/bin is a fairly common thing in my experience, not that it ends up containing many actual binaries. (The system started it, miss, honest. A quarter of the things in my system’s /bin are text based.)

      ~/etc is seriously weird though. Never seen that before. On Debians, most of the user copies of things in /etc usually end up under ~/.local/ or at ~/.filenamehere

        • palordrolap@fedia.io
          link
          fedilink
          arrow-up
          4
          ·
          2 days ago

          ~/bin is the old-school location from before .local became a thing, and some of us have stuck to that ancient habit.

      • db2@lemmy.world
        link
        fedilink
        arrow-up
        3
        ·
        3 days ago

        I use ~/config/* to put directories named the same as system ones. I got used to it in BeOS and brought it to LFS when I finally accepted BeOS wasn’t doing what I needed anymore, kept doing it ever since.