• 7 Posts
  • 80 Comments
Joined 1 year ago
cake
Cake day: June 11th, 2023

help-circle

  • Doubling what Klaymore said, I’ve seen this “just work” as long as all partitions have the same password, no key files necessary.

    That said, if you needed to use a key file for some reason, that should work too, especially if your root directory is one big partition. Keep in mind too that the luks commands for creating a password-based encrypted partition vs a keyfile-based encrypted partition are different, so you can’t, for example, put your plaintext password into a file and expect that to unlock a LUKS partition that was setup with a password.

    But the kernel should be trying to mount your root partition first at boot time where it will prompt for the password. After that it would look to any /etc/crypttab entries for information about unlocking the other partitions. In that file you can provide a path to your key file, and as long as it’s on the same partition as the crypttab it should be able to unlock any other partitions you have at boot time.

    It is also possible, as one of your links shows, to automatically unlock even the root partition by putting a key file and custom /etc/crypttab into your initramfs (first thing mounted at boot time), but it’s not secure to do so since the initramfs isn’t (and can’t be) encrypted - it’s kind of the digital equivalent of hiding the house key under the door mat.







  • I’ll also throw out: aging infrastructure, build systems, coding practices, etc.

    I looked into contributing to the kernel - it’s already an uphill battle to understand such a large, complex piece of software written almost entirely in C - but then you also need to subscribe to busy mailing lists and contribute code via email, something I’ve never done at 30 and I’m betting most of the younger generation doesn’t even know is possible. I know it “works” but I’m really doubting it’s the most efficient way to be doing things in 2024 - there’s a reason so many infrastructure tools have been developed over the years.

    The barriers to entry for a lot of projects is way too high, and IMO a lot of existing “grey” maintainers, somewhat understandably, have no interest in changing their processes after so much time. But if you make it too hard to contribute, no one will bother.



  • Maybe I am not thinking of the access control capability of VLANs correctly (I am thinking in terms of port based iptables: port X has only incoming+established and no outgoing for example).

    I think of it like this: grouping several physical switch ports together into a private network, effectively like each group of ports is it’s own isolated switch. I assume there are routers which allows you to assign vlans to different Wi-Fi access points as well, so it doesn’t need to be literally physical.

    Obviously the benefits of vlans over something actually physical is that you can have as many as you like, and there are ways to trunk the data if one client needs access to multiple vlans at once.

    In your setup, you may or may not benefit, organizationally. Obviously other commenters have pointed out some of the security benefits. If you were using vlans I think you’d have at a minimum a private and public vlan, separating out the items that don’t need Internet access from the Internet at all. Your server would probably need access to both vlans in that scenario. But certainly as you say, you can probably accomplish a lot of this without vlans, if you can aggressively setup your firewall rules. The benefit of vlans is you would only really need to setup firewall rules on whatever vlan(s) have Internet access.








  • To add on to this answer (which is correct):

    Your “of” can also just be a regular file if that’s easier to work with vs needing to create a new partition for the copy.

    I’ll also say you might want to use the block size parameter “bs=” on “dd” to speed things up, especially if you are using fast storage. Using “dd” with “bs=1G” will speed things up tremendously if you have at least >1GB of RAM.


  • I ran into this exact situation at work - though for me it was more the case that getting approvals for new software / installing new dependencies in our system is a massive pain.

    So I went with Python since it’s already installed on basically any Linux system. It was fine - I mean Python is a good language and can certainly handle string processing and data manipulation with relative ease.

    I still think the Python docs are pretty bad, and I wasn’t thrilled with the options for calling a subprocess in Python - they all felt kinda clunky, though I was barred from using the newest versions since I had to run an older version of Python.

    But I ultimately got something that worked and it was certainly better executed / shorter than the bash equivalent it was replacing.



  • To expand on this a bit, git pull under the hood is basically a shortcut for git fetch (get the remote repository’s state) and git merge origin/main main (merge to remote changes to your local branch, which for you is always main).

    When you have no local changes, this process just “makes a line” in your commit history (see git log --graph --decorate), but when you have local changes and the remote has changed too, it has to put those together into a merge commit - think a diamond shape with the common ancestor at the bottom, the remote changes on one side, your changes on the other side, and the merge of the two at the top.

    Like the above comment says, normally this process is clarified at the command line - VSCode must be handling it automatically if there are no code conflicts.