Selfhosted

40183 readers

508 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.

Resources:

selfh.st Newsletter and index of selfhosted software and apps
awesome-selfhosted software
awesome-sysadmin resources
Self-Hosted Podcast from Jupiter Broadcasting

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago

MODERATORS

[email protected]

Advice on encrypted storage (lemmy.world)

submitted 9 months ago* (last edited 9 months ago) by [email protected] to c/[email protected]

9 comments fedilink hide all child comments

I currently have a storage server with the following config.

Multiple raid6 volumes (mdadm) -> aggregated into a lvm volume group -> lvm volumes -> encrypted with luks1 -> (no partitioning) xfs file systems mounted and used by the os

I have the following criteria: I want to keep software raid (mdadm) with multiple raid sets, xfs, and lvm. I don't mind using 2fa, but I don't want to just store my secret keys on a dongle attached to my PC because that seems to defeat the point of encryption at rest.

My questions:

Is there a better way to encrypt my data at rest?
Is there a better layer at which to apply the encryption?

I'm mostly unhappy with luks1 over a whole lvm volume and looking for alternatives.

Thank you everyone for these great responses! I'll be looking into these ideas :)

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 3 points 9 months ago* (last edited 9 months ago) (3 children)

Have not looked through the setup steps of that link, but using FDE with luks and remote ssh unlock for years and have not had any problems.

Also, when you update the kernel you have to rebuild the initramfs with sudo update-initramfs -k all -u, or it won't be able to boot to the new kernel.

Shouldn't that be automatically handled by apt? I dont remember that i have setup a hook for that and i never rebuild my initramfs manually.

[–] [email protected] 1 points 9 months ago (2 children)

I was a bit surprised at it as well, but it doesn't for me running Debian headless. If I reboot after a kernel update it'll try to boot into the new kernel and fail waiting for the initramfs, but it'll boot just fine into the previous kernel. Once I update the initramfs it works fine.

If you know what resources you used to set it up, I'd be curious to take a look and see if I missed something.

[–] [email protected] 2 points 9 months ago (1 children)

Steps are basically not more then this (Can not find the original blog i followed but this is the small write up i have made years ago)

install dropbear
update config to your liking
copy public ssh keys over
run update-initramfs -u (has to be rerun on config change)
done (for the server part)

For some reason i install busybox too in the personal write up. But i do not think it is necessary.

[–] [email protected] 1 points 9 months ago

That's basically the same as my writeup from when I did it. Except I also had a -k all on update-initramfs. Not sure about the switches, so I'll look into them. Thanks.