Date: Wed, 9 Dec 2009 21:01:39 -0700 From: Modulok <modulok@gmail.com> To: "Corey J. Bukolt" <0.23@mail.ru> Cc: freebsd-questions@freebsd.org Subject: Re: Temporarily halt boot process to enter encryption keys? Message-ID: <64c038660912092001t300e8dd9id6c27a01c4b3c65d@mail.gmail.com> In-Reply-To: <4B2044DA.8030300@mail.ru> References: <4B1F5263.1060907@mail.ru> <4B2044DA.8030300@mail.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Corey,
Umm...write a script perhaps?
Nobody else has taken a shot at this one yet, so I'll try. This is
just what I'd do. That said, it's probably not the best solution. It's
an idea. You may have to work out some bugs along the way.
In regards to interrupting the boot process, I don't think this is
what you're after, unless you have console access. In which case you'd
use geli to set the boot flag on your providers. The boot process will
stop, ask for a password and then continue. The problem is that this
occurs before daemons like sshd are started; Unless you have console
access, you're screwed. Thus, your problem...
You want the system to boot as usual, it's just you don't want it to
start any third party daemons such as samba ...yet!
(This is why runlevels on SysV style startups are useful. It would be
a matter of switching to a custom runlevel.)
You would first disable the various daemons by not having them in your
'rc.conf' file. You'd then write a wrapper script, in your language of
choice. The wrapper simply calls the various '/usr/local/etc/rc.d'
scripts to start all of your third party daemons as usual. ...and
whatever else you need to do. Remember to pass the 'onestart'
argument, because the rc scripts are no longer listed in /etc/rc.conf.
With all that in place you'd ssh in and execute the wrapper as the
root user.
(root)> engage
Poof done. You can put the wrapper script anywhere you want. Name it
anything you like. Just make sure it's executable by the root user.
(Thus be careful when writing it!) An example of a python wrapper
might look something like the one below. Change to fit your needs,
obviously. Admittedly it's not he most pythonic code ever written. It
also probably has bugs to work out, but again, it's an idea.
#!/usr/local/bin/python
""" Wrapper which executes a bunch of files."""
import os
import sys
import subprocess as sp
# Change this to suit your needs:
SCRIPTS_TO_CALL = [
'/usr/local/etc/rc.d/apache22',
'/usr/local/etc/rc.d/samba',
'/etc/rc.d/ntpd'
]
if os.geteuid() != 0:
sys.stderr.write("This script must be executed as the root user.
Aborting.\n")
for script in SCRIPTS_TO_CALL:
if os.path.exists(script):
command = script + " onestart"
p = sp.Popen(command, shell=True, stdout=sp.PIPE, stderr=sp.PIPE)
# Now write out any errors/output to their usual places:
sys.stdout.write(p.stdout.read()+"\n")
sys.stderr.write(p.stderr.read()+"\n")
else:
sys.stderr.write("File, '%s' does not exist. Skipping...\n" % script)
Hacky, perhaps buggy, but perhaps useful. Unless anyone has a better
idea? With a little more refinement you could probably even convert
your FreeBSD box into a sysV equivalent, making complex custom
startups easier in the future. Blasphemy, I know!
-Modulok-
On 12/9/09, Corey J. Bukolt <0.23@mail.ru> wrote:
> Corey J. Bukolt wrote:
>> Hello list,
>>
>> I have a FreeNAS box with a CF card for root, and 3 drives (soon to
>> be 4) set up with encryption and raidz on top of them. A less than
>> excellent detailed report of what I did is here:
>> http://bit.ly/5BeZq8 This setup is a bit hackish as after the
>> system boots I need to attach each drive using geli, run "zpool
>> import -f primary", and then restart all my services (nfs, samba,
>> etc).
>>
>> It's become a bit of a chore (especially when doing it all from a
>> N810), so I'm looking for a way to temporary halt the boot process
>> so that I can ssh in, attach the drives, and then allow the system
>> to continue to boot.
>>
>> A few ideas come to mind, such as meddling with rc scripts, but I'd
>> like to get some suggestions from the more experienced FreeBSD
>> hackers before I go off breaking my system.
>>
>> Thanks, ~Corey
>>
>> _______________________________________________
>> freebsd-questions@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-questions To
>> unsubscribe, send any mail to
>> "freebsd-questions-unsubscribe@freebsd.org"
>>
>>
>
> Anybody at all?
>
> _______________________________________________
> freebsd-questions@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?64c038660912092001t300e8dd9id6c27a01c4b3c65d>