NANOBSD: How does it work / how is it used?

bb-mitch

I looked on the FreeBSD site, and searched the forum and looked at the wiki…

NanoBSD gives us two boot slices. Does anything cause automatic failover of the booted slice? I thought I saw this happen but wasn't sure why?

What about the config - it is shared across both nano boot slices - correct?

Is there a way to implement a "last known good" config?

I was hoping that the following was possible, but am not sure if it's in existance yet or even possible...

Scenario:

an upgrade is attempted (could be pfSense version, OR possibly a radical firewall / Ip address change).
the upgrade fails
the user on site CRASHES the system (pulls the power) when the system fails to be usable
upon reboot, the alternate slice is booted with the last safe config

Is this already in the works?

Thanks!!

jimp

NanoBSD has two system slices, but they are only changed during an upgrade, or by manual intervention.

When you boot, there is an F1/F2 prompt that lets you select which slice to boot from.

The config is on a third slice which is not related to the boot slices, it only stores the config and related files.

As such, the config should always be safe from failed upgrades or corrupt files on a system slice.

bb-mitch

Thanks for the reply.

Ahhh - ok - unless the config is the problem ;-)

What I'm looking for is a way to use the technology to recover from admin screw up (or ISP screw up). We've had several cases where the ISP has issued incorrect IP configuation information - the system works BEFORE the config - can be reverted to it's old config manually, but once you made the change you are screwed if the changes are not correct.

So as it stands, first slice or second, the same config is used. I think I'll canoodle about a "deadman switch" package. Maybe a pipe dream til I get more time or experience on the platform in coding, but something to allow making it failsafe…

Thoughts:

create a backup config / manual "last known good"
on reboot, try to load current config - if no one logs in and "confirms" the config then continue...
reboot, try to use last known good config... wait for login / confirm - it not, continue...
set boot slice default to alternate
reboot, using alternate boot slice with last known good config and give up at this point - if it doesn't work now you are fubar'd

This would allow (with a user capable of no more than a reboot) to remotely revert / roll back your config / upgrades.

Has anyone tried / implemented something similar?

Thanks again for the confirmation of what NanoBSD does - cheers!

m/

jimp

I would advice against any such automation, though, as what if the router rebooted when nobody was around to 'confirm' that it worked? (for example, during a power failure)

The last 20-30 or so configs are kept in /conf/backup/ so you don't have to worry about keeping your own copies.

An option from the console menu to restore might be handy, but it's pretty simple:

Drop to a shell
cp /conf/backup/<blah>.xml /conf/config.xml
rm /tmp/config.cache

And then rebooting is probably the safest thing to do at that point.</blah>

bb-mitch

Excellent - thanks for the tip!
The "false alarm" could be prevented by recording the first successful confirmed boot so that the process is not triggered again until "armed".
Again - thinking out loud - not coding yet.
My issue is that users on sites are not nessecarily capable or trusted with access to the routers. And a 60 minute drive is a high price to pay for a 2 minute change.

A pipe dream at the moment, but I'll think on it - thanks again!