Re: Temporarily halt boot process to enter encryption keys?
On Thu, 10 Dec 2009 14:54:11 +, RW wrote: > It's fairly trivial to write an rc.d script that pauses the boot > process and waits for devices, but sshd runs after LOGIN, and nfs runs > before, so you can't easily reorder then without maintaining modified > rc.d scripts. I think it's possible to work with the PROVIDE, REQUIRE and BEFORE comments. But as you said, this will change the default rc.d scripts and may cause (minor?) trouble when upgrading the OS. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Temporarily halt boot process to enter encryption keys?
RW wrote: > On Wed, 09 Dec 2009 01:31:47 -0600 > "Corey J. Bukolt" <0...@mail.ru> 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. >> >> > > It's fairly trivial to write an rc.d script that pauses the boot > process and waits for devices, but sshd runs after LOGIN, and nfs runs > before, so you can't easily reorder then without maintaining modified > rc.d scripts. > > > I don't see the point though. Why not just write a script to do > what you are doing now? > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" > > > You are right that I could very well just write a script and be done with it, but I'm trying to find a more elegant approch. Starting up a whole bunch of services that are going to error, killing them, then restarting seems to me as a messy approch. Perhaps if I put a rc.d script before nfs that calls a lightweight sshd, such as dropbear, and waits for all the drives to be attached with geli. Once they are, the script kills sshd and the boot continues as normal. Think that would work? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Temporarily halt boot process to enter encryption keys?
On Wed, 09 Dec 2009 01:31:47 -0600 "Corey J. Bukolt" <0...@mail.ru> 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. > It's fairly trivial to write an rc.d script that pauses the boot process and waits for devices, but sshd runs after LOGIN, and nfs runs before, so you can't easily reorder then without maintaining modified rc.d scripts. I don't see the point though. Why not just write a script to do what you are doing now? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Temporarily halt boot process to enter encryption keys?
Modulok wrote:
> 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...
Exactly.
>
> 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-
>
Oooo.Not a bad idea at all.
It might be even simpler just to disable the services in rc.conf, then
use a simple shell script with something like:
#!/bin/sh
/etc/rc.d/nfsd start
/etc/rc.d/samba start
.etc
Then all that would have to be done is boot the system, ssh in, attach
the drives using geli, then run engage.sh (or whatever).
Thank you very much for the idea. :)
~Corey
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Temporarily halt boot process to enter encryption keys?
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...@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-unsubscr...@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-unsubscr...@freebsd.org"
>
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Temporarily halt boot process to enter encryption keys?
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-unsubscr...@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-unsubscr...@freebsd.org"
Temporarily halt boot process to enter encryption keys?
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-unsubscr...@freebsd.org"
