[Bug 193302] New: modifiy /etc/rc.d/geli to handle multiple providers with the same password/keyfile

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Thu Sep 4 03:07:14 UTC 2014


            Bug ID: 193302
           Summary: modifiy /etc/rc.d/geli to handle multiple providers
                    with the same password/keyfile
           Product: Base System
           Version: 10.0-STABLE
          Hardware: Any
                OS: Any
            Status: Needs Triage
          Severity: Affects Some People
          Priority: ---
         Component: conf
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: karl at denninger.net

Created attachment 146761
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=146761&action=edit
addition to /usr/local/etc/rc.d

A common configuration with ZFS filesystems (in particular) contains many
volumes that are then aggregated into a pool, with ZFS filesystems associated. 
This leads to a requirement to type a password (if one is used) many times
(potentially a dozen or more!) on a boot, as the geli script makes no attempt
to get the password itself, but relies on the /sbin/geli code itself.

If the providers all have the same password and keyfile (or just a password)
then it would be much nicer to have to enter the password only once during
system boot time, or at most twice (if root is also encrypted.)

This modification of the "geli" script, named "encrypt" and placed in
/usr/local/etc/rc.d, replaces the "geli" script and permits this -- it accepts
the same options (for the most part) as geli does, except for the detach
parameter which is not supported, asks for the password itself and then
iterates over all the providers given and attempts to attach them sequentially.
 I modified and renamed the existing script rather than simply proposing a
patch for the instance where you may want to support both the previous (one
prompt per provider) and this (one prompt for a group of providers) paradigm on
the same system.

You are receiving this mail because:
You are the assignee for the bug.

More information about the freebsd-bugs mailing list