Re: Mounting encrypted drive on boot
On Wed, Jun 03, 2020 at 12:27:00AM +0100, Chris Narkiewicz wrote:
[...]
> My setup consist of OpenBSD 6.7 with full drive encryption using
> softraid, configured as described in FAQ:
>
> /dev/sd0a - encrypted volume
> /dev/sd1 - decrypted
>
> I have additional need to mount an encrypted /var volume on boot.
> This volume is separate drive attached to be VPS "machine".
>
> I want to mount this drive automatically on boot by adding
> relevant entries to /etc/fstab, but before this can be done,
> softraid device must be configured using bioctl.
>
[...]
>
> Somebody on StackOverflow advised on modifying /etc/rc
> and run bioctl before disks are mounted, but I'm not sure
> if this is a right approach, especially that attaching
> more disks might change the /dev/sd* numberign.
Don't modify /etc/rc itself.
rc(8): "Normally, rc.local contains commands and daemons that are not
part of the stock installation."
I don't fully understand your question, but I used to have an rc.local
to allow using /home from an encrypted USB drive that got loaded from
rc.local. I'm not endorsing this as a great solution, but maybe this
will serve as inspiration for you to come up with your own method.
/etc/rc.local (REPLACE with your disk's DUID):
# CRYPTO_DEV assumes that home is on the k partition of a disk with the DUID
.
CRYPTO_DEV=`sysctl hw.disknames | sed -n -E "s/.*(sd[0-9]{1,2}):.*/\1/p"`
fsck -y /dev/r${CRYPTO_DEV}k
mount -o softdep,nodev,nosuid .k /home
signature.asc
Description: PGP signature
Re: Mounting encrypted drive on boot
On 2020-06-02 23:27, Chris Narkiewicz wrote: > Somebody on StackOverflow advised on modifying /etc/rc > and run bioctl before disks are mounted, but I'm not sure > if this is a right approach, especially that attaching > more disks might change the /dev/sd* numberign. That would cause yourself maintenance pain/broken systems. A less broken solution, would be more targeted. I have retrofitted encryption before, to allow manual post boot activation of encryption via ssh, when abroad, without leaving a fob. Mounting a mail drive and also encrypted /var/spool and a backup drive from /etc/rc.securelevel. When it asks for a password on boot, rc.securelvel runs fsck -p ... && /sbin/mount ... (... = duid etc) It also reads the passwords for the extra volumes with bioctl -p, for convenience of only entering one password. Obviously the passwords are readable only by root and stored on the first encrypted drive.
Mounting encrypted drive on boot
My setup consist of OpenBSD 6.7 with full drive encryption using softraid, configured as described in FAQ: /dev/sd0a - encrypted volume /dev/sd1 - decrypted I have additional need to mount an encrypted /var volume on boot. This volume is separate drive attached to be VPS "machine". I want to mount this drive automatically on boot by adding relevant entries to /etc/fstab, but before this can be done, softraid device must be configured using bioctl. On Linux this is done by adding some entries to /etc/crypttab and the boot script performs required configuration before disks in fstab are mounted. How to do similar thing in OpenBSD? Somebody on StackOverflow advised on modifying /etc/rc and run bioctl before disks are mounted, but I'm not sure if this is a right approach, especially that attaching more disks might change the /dev/sd* numberign. What would be the best approach? Best regards, Chris signature.asc Description: PGP signature
Re: Mounting encrypted drive on boot
On 2020-06-02 19:27, Chris Narkiewicz wrote: > My setup consist of OpenBSD 6.7 with full drive encryption using > softraid, configured as described in FAQ: > > /dev/sd0a - encrypted volume > /dev/sd1 - decrypted > > I have additional need to mount an encrypted /var volume on boot. > This volume is separate drive attached to be VPS "machine". > > I want to mount this drive automatically on boot by adding > relevant entries to /etc/fstab, but before this can be done, > softraid device must be configured using bioctl. I don't think there is a good answer to your question *as asked*, so we just have to come up with a new question and solve your problem. :) I am GUESSING your real problem is "I didn't make /var big enough" You can add a second disk. And you did. I would look closely at what partitions you have on /dev/sd1c. Got a /home? Move that to your second drive, move the /var to your old /home. Or..what is the real problem with /var? Maybe /var/www? Move THAT to your second drive, leave /var (which is kinda important on boot for a lot of reasons!) on sd1. But in general, work out a way to keep /var on your primary boot drive, and put something that isn't needed in the first moments of boot on the secondary drive. Some other ideas that could be moved: /usr/local /usr/src /usr/bin /usr/ports /home Most of those would provide a good basic /var If you over-built some other partition, copy the data off, make it smaller, reload, and use the freed space for a /var. Nick.
Re: Mounting encrypted drive on boot
‐‐‐ Original Message ‐‐‐ On Wednesday, June 3, 2020 7:27 AM, Chris Narkiewicz wrote: > My setup consist of OpenBSD 6.7 with full drive encryption using > softraid, configured as described in FAQ: > > /dev/sd0a - encrypted volume > /dev/sd1 - decrypted > > I have additional need to mount an encrypted /var volume on boot. > This volume is separate drive attached to be VPS "machine". > > I want to mount this drive automatically on boot by adding > relevant entries to /etc/fstab, but before this can be done, > softraid device must be configured using bioctl. > > On Linux this is done by adding some entries to /etc/crypttab > and the boot script performs required configuration before disks > in fstab are mounted. > > How to do similar thing in OpenBSD? > > Somebody on StackOverflow advised on modifying /etc/rc > and run bioctl before disks are mounted, but I'm not sure > if this is a right approach, especially that attaching > more disks might change the /dev/sd* numberign. > > What would be the best approach? > > Best regards, > Chris Take look at https://xosc.org/enchome.html, and use the FAQ along with that document. It works for me with an encrypted /home, but /var might be a lot more problematic. Cheers Adam
