• 4 Posts
  • 42 Comments
Joined 2 years 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 know for me, at least with gnome, toggling between performance, balanced, and battery saver modes dramatically changes my battery life on Ubuntu, so I have to toggle it manually to not drain my battery life if it’s mostly sitting there. I don’t know if Mint is the same, but just throwing out the “obvious” for anyone else running Linux on a laptop.



  • 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.




  • I saw this complaint in another post online (paraphrased):

    The screen and use of a Pi seem at odds with each other. The screen is ultra-low power, but there are of course huge drawbacks for usability. Meanwhile the CPU is very powerful, but chews through, comparatively, a lot of power quickly.

    They argued that it would be better to either pair the Pi with a better screen for a more powerful/usable handheld, or go all in on longevity and use some kind of low-power chip to pair with the screen for a terminal that could last for days.

    … I’ve got to say, it’s a fair point. A low power hand-held that could run Linux and run for days would be pretty cool, even if it was underpowered compared to a Pi. No idea what you could use for such a thing though.










  • So I asked about this once before, and my understanding is that since beehaw defederated:

    • Beehaw won’t accept anything new from lemmy.world
    • Beehaw won’t send anything new to lemmy.world

    So even though lemmy.world didn’t block beehaw, it is still effectively cut off in all meaningful ways.

    You could still see:

    • Beehaw and lemmy.world users interacting together in communities on instances that neither has blocked (because in this case the third instance is acting like a middleman between them)
    • Lemmy.world users can still post to the “phantom” beehaw communities and it will be visible to all lemmy.world subscribers, but no one else will see it since it can’t reach Beehaw, and thus can’t be distributed to all the other instances.