OPNsense Forum

English Forums => Development and Code Review => Topic started by: oneplane on June 12, 2021, 09:29:01 pm

Title: ONIE integration
Post by: oneplane on June 12, 2021, 09:29:01 pm
Preamble
I've been running OPNSense on a number of refurbished/retargeted hardware devices that are slowly trickling down from the high-end NFV enterprise boxes down to us mortals, and ONIE availability has been coming in more frequently over the past few years.

For example, a relatively large amount of Dell VEP devices is becoming available due to their enterprise lifecycle nearing the end of the first support phase, those boxes generally come with multicore C3000 series SoCs, 4+ GB of RAM and some combination of eMMC and mSATA or M.2 SSDs with a number of high quality network interfaces (some via the C3000 embedded interfaces, some i3xx series). Due to the low cost and relatively high reliability and performance this makes for a very neat platform to run a variety of network functions on top of.

One of the features of a lot of uCPE and NFV hardware devices have is ONIE support. This is essentially an embedded Linux environment that serves to install/update/replace the main OS. It doesn't need to target a Linux OS, examples (commercial mostly) running NetBSD and even VxWorks are in use at scale. The benefit is that you get integrated support for recovery methods, as well as embedded diagnostics, and device-specific information about the ports, locations, naming, and other chassis features. It's not quite as 'fat' or complex as a BMC or SPS but more comparable to an extension of a DTB.

The actual idea
Wouldn't it be great if we could package an OPNSense installation into a format that can be 'installed' and 'recovered' using ONIE? This way, we can run on a variety of network hardware while only adding a single installation option. It is similar to developing an AMI for AWS or a CF image for x86 devices with no VGA. As far as I can tell, this boils down to a package with a disk image, a deployment script so whatever bootloader the device comes with can chainload BTX, and an addition to that disk image that reads the configuration ONIE parks in a known spot so it can boot up and know what interfaces exist ahead of time.

I am by no means a BSD installer specialist, but looking at the scripts for the ARM build and AWS AMI build it should be feasible to prepare an architecture-specific image that can at least run without additional installation, and then inject a process or rc script to read a base configuration when a fresh install/image is detected.

I don't know if anyone else has thought of this or if this was attempted at an earlier time but some feedback on this idea would be neat.