search

EGI-Federation / documentation

Sources to build EGI documentation site.
https://docs.egi.eu/
MIT License
14 stars 48 forks source link

Added mkfs command #532

Closed EGI-ILM closed 2 years ago

EGI-ILM commented 2 years ago

I think there is a step missing. Otherwise there will be a filesystem error: mount: /storage1: wrong fs type, bad option, bad superblock on /dev/mapper/storage1, missing codepage or helper program, or other error.

EGI-ILM commented 2 years ago

Actually, I have done a reboot and I realised that maybe my suggested change is not what it was intended in the documentation, but then perhaps this bit can be removed: mkdir /storage1

And leave only:

$ cryptsetup luksOpen /dev/vdb storage1
$ mount -t ext4 /dev/mapper/storage1 /storage1
andrea-manzi commented 2 years ago

Actually, I have done a reboot and I realised that maybe my suggested change is not what it was intended in the documentation, but then perhaps this bit can be removed: mkdir /storage1

And leave only:

$ cryptsetup luksOpen /dev/vdb storage1
$ mount -t ext4 /dev/mapper/storage1 /storage1

ok but if you don't have the /storage1 folder created already the mount command will fail no?

gwarf commented 2 years ago

Apparently the filesystem is already created in step 2: https://docs.egi.eu/users/data/storage/block-storage/#storage-encryption, so I don't think mkfs should be used here. I agree that the mkdir may be useless as it got done in step 3, unless those commands are to be run from a different VM mounting the already encrypted and formatted disk. Maybe exact use case could be clarified, or mkdir -p could be used, as it wouldn't complain if the folder already exist.

EGI-ILM commented 2 years ago

@andrea-manzi Yes, it will fail, but these steps are assuming that mkfs.ext4 /dev/mapper/storage1 has been already done too, so it is reasonable to assume that other "permanent" operations, such as mkdir /storage1 have been done too. That is why I got confused, I initially thought that these were the steps for a "permanent" use, so it should include only permanent steps (and one was missing). On my reboot, I realised that these were the "routine" steps, so then the creation of the folder made no sense (unless used in a different VM, as pointed by @gwarf ) and then probably one is not needed.

Anyway, it is a minor detail. I found this documentation very clear and straightforward, very nicely written.

Is there a way to automate the mounting at each reboot? Because that could be a nice addition to the documentation.

gwarf commented 2 years ago

For the automatic mounting, one could use /etc/crypttab and /etc/fstab, but the main problem is probably the unlock of the encrypted FS, and the need to provide the passphrase. With luks you can use a key file to unlock a partition and have the key optionally without a passphrase, but it's also making this way less secure/useful, not that recommended if the data really needs to be protected...

andrea-manzi commented 2 years ago

aaah ok got it now, you are referring to the last part of the doc. Yes there we could remove the mkdir or add the -p option as reported by @gwarf

EGI-ILM commented 2 years ago

I have made a change based on the comments here. I also changed the word "following" to be more explicit, as it confused me.

gwarf commented 2 years ago

@andrea-manzi can you please check/approve this one?