Tobias WaldekranzandJoachim Wiberg
2bfc524546
Before this change, the following would happen in /lib/infix/mnt if a factory-reset was performed: 1. Copy the contents of /var from Squash into /mnt/var and bind mount /mnt/var over /var 2. Check for factory-reset 3. Clear /mnt/cfg/* and /mnt/var/* 4. Mount overlays This ordering leaves the system with a completely empty /var on the boot when a factory-reset is executed. Finit will fixup some of this via its tmpfiles scripts, but we want the ability to ship files under /var as part of the Squash and have these be available after the bind mount, just like what happens at every other boot, when we don't perform a factory-reset. We solve this by delaying the bind mount (1) until after the reset has been performed, together with all the overlays (4). While we're here, make the fallback case, where no persistent /var is available, use a bind mount as well. This should allow containers to be tested on such setups, and it's one less flavor to test. New order: 1. Check for factory-reset 2. Clear /mnt/cfg/* and /mnt/var/* 3. Mount overlays 4. Copy the contents of /var from Squash into /mnt/var and bind mount /mnt/var over /var Now the only difference between a regular boot and a "factory-reset-boot" is whether (2) executed or not.
Documentation
Infix is a Linux Network Operating System (NOS) based on Buildroot, and sysrepo. A powerful mix that ease porting to different platforms, simplify long-term maintenance, and provide made-easy management using NETCONF1 (remote) or the built-in command line interface (CLI) (click the foldout for an example).
Example CLI Session
The CLI configure context is automatically generated from the loaded YANG models and their corresponding sysrepo plugins. The following is brief example of how to set the IP address of an interface:
admin@infix-12-34-56:/> configure
admin@infix-12-34-56:/config/> edit interfaces interface eth0
admin@infix-12-34-56:/config/interfaces/interface/eth0/> set ipv4 <TAB>
address autoconf bind-ni-name enabled
forwarding mtu neighbor
admin@infix-12-34-56:/config/interfaces/interface/eth0/> set ipv4 address 192.168.2.200 prefix-length 24
admin@infix-12-34-56:/config/interfaces/interface/eth0/> show
type ethernetCsmacd;
ipv4 address 192.168.2.200 prefix-length 24;
ipv6 enabled true;
admin@infix-12-34-56:/config/interfaces/interface/eth0/> diff
interfaces {
interface eth0 {
+ ipv4 {
+ address 192.168.2.200 {
+ prefix-length 24;
+ }
+ }
}
}
admin@infix-12-34-56:/config/interfaces/interface/eth0/> leave
admin@infix-12-34-56:/> show interfaces brief
lo UNKNOWN 00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eth0 UP 52:54:00:12:34:56 <BROADCAST,MULTICAST,UP,LOWER_UP>
admin@infix-12-34-56:/> show ip brief
lo UNKNOWN 127.0.0.1/8 ::1/128
eth0 UP 192.168.2.200/24 fe80::5054:ff:fe12:3456/64
admin@infix-12-34-56:/> copy running-config startup-config
Click here for more details.
Infix can run on many different types of architectures and boards, much thanks to Linux and Buildroot. Currently the focus is on 64-bit ARM devices, optionally with switching fabric supported by Linux switchdev. The following boards are fully supported:
- Marvell CN9130 CRB
- Marvell EspressoBIN
- Microchip SparX-5i PCB135 (eMMC)
An x86_64 build is also available, primarily intended for development and testing, but can also be used for evaluation and demo purposes. For more information, see: Infix in Virtual Environments.
See the GitHub Releases page for our pre-built images. The Latest Build has the bleeding edge images, if possible we recommend using a versioned release.
For customer specific builds of Infix, see your product repository.
-
NETCONF or RESTCONF, https://datatracker.ietf.org/doc/html/rfc8040, for more information, see Infix Variants. ↩︎