On 2009-05-21, Diana Eichert <deich...@wrench.com> wrote: > On Thu, 21 May 2009, Obiozor Okeke wrote: > >> >> Hi Diana (and Stuart) thanks for all your advice. >> >> The problem or nut we're trying to crack is that we're trying >> to deploy OpenBSD to remote clients and we wanted an inexpensive >> but very high reliability system with the flexibility to change >> configurations (switch in/out different VMs) and add/modify services >> remotely on-the-fly. For example we could upgrade a client from >> 4.A4 to 4.5 along with all the custom apps and client data packaged >> in a VM. We would grab the old 4.4 VM bring it back to our lab, then >> upgrade and re-configure it the way we wanted to and drop it back on >> the ESXi. Then just change the network configs and switch the old for >> the new all remotely without ever visiting the client >> >> Thanks again all. > > If you want to stick with the Soekris you might want to consider > basing your solution on flashboot, > http://lists.mindrot.org/pipermail/flashboot/2009-May/000223.html . > > Using a CF with multiple partitions would allow you to upgrade > remotely the flashboot kernel. Of course this would take some work > to fine tune the upgrade procedure to minimize failure mechanisms.
with flashboot, it's reasonably ok on a single partition too, just point boot.conf at the right one after downloading. failure recovery would usually involve a serial port, resetting, and typing at the boot prompt, but if it's not too disastrous a failure you might get away with setting the bios to turn the reset button over to software control and having some daemon check the gpio pin and, when the button's detected, revert to a previous boot.conf.
