• 0 Posts
  • 129 Comments
Joined 1 year ago
cake
Cake day: July 9th, 2023

help-circle




  • Having consistent interface names on servers that have several is useful, but we already had that option. The interface names they generate are not only hard to remember, but not terribly useful as they’re based on things like which PCI slot they’re in, rather than what their purpose is. You want interface names like wan0 and DMZ, not enp0s2. Of course, you can set it up to use useful names, but it’s more complicated than it used to be, so while the systemd approach looks like a good idea on the surface, it’s actually a retrograde step.




  • In news that will shock no-one, dbus was, of course, initially created by a Redhat engineer. I get the idea of having a general purpose bus that everything can communicate on, but they somehow managed to even make that complex.

    You make a compelling case for Void Linux. I use Debian or a RHEL derivative for work, primarily so there’s at least a chance to hand systems off to someone else to maintain, the less known distros seem to meet with blank looks.

    I want to give NixOS a try sometime, as I like the idea of declaritively defining the system




  • That’s fair, it does make sense to use it on a laptop, but it really should be the sort of thing you add when needed rather than having it jammed in whether it’s useful or not.

    Every time I need to do something even slightly different to a basic setup I find myself inventing new curses for those who screwed things up with these overblown, over complex, minimally functional abominations. Just give me vi and the basic configuration files and let me get on with it!



  • Personally I’d do away with NetworkManager too and just configure the interfaces directly, but that might just be me being old and grumpy!

    I think most distros go along because their upstream did. There are comparatively few ‘top level’ distributions, the main ones (by usage) being Redhat and Debian. Most everything else branches from those. Redhat’s got enough clout on the market that there’s a sort of pull towards complying with it just to not be left put.

    I use Debian, but I think they’re crazy for swallowing everything Redhat pushes, they could easily stick to the cleaner options and have a better system for it. At least they let you opt out of systemd, so life is a little more tolerable.






  • This seems like a very complicated way to achieve your goal! It sounds like sitting yourself down and giving you a stern talking to might be a beter aporoach.

    Having said that, if you have these very important files that you don’t want to lose, please make sure they’re backed up somewhere off of your machine. Storage fails, and it’s a horrible feeling losing something important. Unfortunately doing so would defeat the approach you’re thinking of.

    This might be a case of needing to reframe the question to get to the cause of the issue, and then solve that. So, why do you want to make it hard to reinstall your machine? Is it the amount of time you spend on it, the chance of screwing it up, needing it working, has it become a compulsion or something else? Maybe if we can get to the root of the issue we can find a solution.

    With regard to TPM, it’s basically just a key store, so you can use it fir anything really, althought it’s normally used by generating a TPM key and using it to encrypt the key that’s actually used to encrypt your data, storing the encrypted key with the OS. Just reinstalling won’t wipe the TPM, but unless you made an effort to save the encrypted key it’ll be gone. Given your problem statement above it just adds to the data you’d need to save, which isn’t helpful.


  • Ok, I’m still not clear on exactly what you’re trying to achieve as I can’t quite see the connection between somehow preventing certain files being duplicated when cloning the disk and preventing yourself from reinstalling the system.

    Bear in mind that reinstalling the system would replace all of the OS, so there’s no way to leave counter-measures there, and the disk itself can’t do anything to your data, even if it could detect a clone operation.

    If what you’re trying to protect against is someone who knows everything you do accessing your data, you could look to use TPM to store the encryption key for your FDE. That way you don’t know the password, it’s stored encrypted with a secret key that is, in turn, stored and protected by your CPU. That way a disk clone couldn’t be used on any hardware except your specific machine.


  • Nothing can prevent a disk clone cloning the data, and there’s no way to make something happen when a disk is cloned as you’re not in control of the process.

    If you wish to mask the existence of the files, use either full disk encryption, in which case cloning the disk doesn’t reveal the existence of the files without the decrypt password, or use a file based encrypted partition such as veracrypt in which case the cloner would just see a single encrypted blob rather than your file names.

    Ultimately encrypting the files with gpg means they have already effectively ‘destroyed or corrupted’ themselves when cloned. If you don’t want to reveal the filenames, just call them something else.

    If you could be a bit more specific about your threat model people may have better ideas to help.