[zfs-discuss] ZFS on root: Additional question

Schlacta, Christ aarcane at aarcane.org
Fri May 20 05:29:24 EDT 2016

On May 20, 2016 2:08 AM, "Gregor Kopka via zfs-discuss" <
zfs-discuss at list.zfsonlinux.org> wrote:
> Am 19.05.2016 um 00:56 schrieb D. R. Evans via zfs-discuss:
>> Manuel Amador (Rudd-O) via zfs-discuss wrote on 05/18/2016 03:43 PM:
>>> The jury is still out on /var.   Not sure what in early boot demands
>>> files in /var.
>> I don't recall the details, but I discovered that on my jessie system I
had to
>> have /var on the root filesystem. (But in my case, I was specifically NOT
>> running ZFS on the root filesystem. Still, my experience suggests that
>> also should have /var available.)
> I have encrypted servers (with ZFS root) on which I need to restart and
unlock without physical access, they boot into a minimal root (running SSH
to get key material into them) so they need some stuff in /var to boot.

Have you looked into doing this from initrd? That would save you the later
mount shuffles. You can add everything sshd needs into a hook,  and fire it
up under a different name before the system starts actually running stuff
> Solution I came up with: the unlocking script imports the encrypted pool
without mounting the filesystems in it, overloads/replaces populated
filesystems like /var/log, /var/run and others like ~/.ssh (from the root
pool) with datasets from the then decrypted pool, with them in place
restart anything anchored in the original filesystems (on the root pool,
getting list of processes to restart by lsof prior to the filesystem mount
juggling, this is mainly sshd), zfs mount -a and then init into a custom
runlevel to start the services the box should provide.

If you're just trying to prevent a thief from gaining access and are
comfortable with the machine posting automatically when it's in the right
location,  you can use something like curl with client https certs to
retrieve the unlock key from a remote https server on site.   Mutual
verification prior to post.server won't be able to boot off site.
> Gregor
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at list.zfsonlinux.org
> http://list.zfsonlinux.org/cgi-bin/mailman/listinfo/zfs-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.zfsonlinux.org/pipermail/zfs-discuss/attachments/20160520/d6aa8091/attachment.html>

More information about the zfs-discuss mailing list