infix/doc

Infix Variants

Infix has two main flavors. Both have a default admin account, which is allowed to log in from remote, default password admin -- customer specific builds may have something else, e.g., per-device generated factory password.

See Infix Discovery to locate your device.

NETCONF

Infix use by sysrepo and Netopeer to provide NETCONF support. A set of sysrepo plugins configure the network, using the Linux iproute2 tool suite, generate configuration files in /etc, and control the all system daemons, e.g., enable DHCP client on an interface.

Configuration of an Infix device can be done remotely, using command line tools like netconf-client and netopeer2-cli, or desktop GUI tools like NETCONFc and MG-SOFT NetConf Browser. It is also possible to log in to the device using SSH and set it up locally using the built-in CLI¹ .

Note: unlike Infix Classic, the /etc directory is a volatile RAM disk populated on each boot from the startup-config, ensuring a coherent centralized view of the system.

Classic

Infix Classic is very much like a traditional embedded Linux system. It use the same kernel as NETCONF builds, but unlike them it is up to the administrator to manually modify system configuration files in /etc and control the system services using the initctl tool.

For example, networking is configured by editing the ifupdown-ng files in /etc/network/interfaces.

In Classic builds the /etc directory is saved across reboots.

To perform a factory reset, wiping all changes in /etc, and all other areas of the file system that are persistent, use the factory tool.

See the online help command for an introduction to the system and help on available tools, like text editors, network debugging, etc.

Hybrid Mode

Since Infix is under heavy development, it does not yet have all bells and whistles in place in the NETCONF builds. To that end it is possible to manually manage certain properties and services. It's a little bit tricky since any changes to the /etc directory is lost at reboot.

To work around that we use the run-parts(8) feature of the system, available in some customer specific images. The system runs any user scripts in /cfg/start.d before leaving runlevel S (bootstrap).

Note: a vanilla Infix build does not support Hybrid Mode out of the box. You can enable it, and build your own images by adding the following line to board/common/rootfs/etc/finit.conf:

    runparts /cfg/start.d

See the Developer's Guide for a build HowTo.

Starting OSPF

For example, the following starts OSPF:

root@infix:~$ cp -a /etc/frr /cfg/
root@infix:~$ mkdir /cfg/start.d
root@infix:~$ cd /cfg/start.d
root@infix:/cfg/start.d$ cat <<EOF >10-enable-ospf.sh
#!/bin/sh
# Use vtysh to modify the OSPF configuration
mount --bind /cfg/frr /etc/frr
initctl enable zebra
initctl enable ospfd
initctl enable bfdd
(sleep 1; vtysh -b) &
exit 0
EOF
root@infix:/cfg/start.d$ chmod +x 10-enable-ospf.sh

The /cfg area is persistent across reboots. Here we assume the user has already created the /cfg/frr directory, populated it with the original files from /etc/frr, and then modified the appropriate files to enable OSPF and BFD.

Starting Containers

Using /cfg/start.d is also the way to start containers (provided the images have been downloaded with podman pull first):

root@infix:/cfg/start.d$ cat <<EOF >20-enable-container.sh
#!/bin/sh
podman-service -e -d "Nginx container" -p "-p 80:80 -v /cfg/www:/usr/share/nginx/html:ro" nginx:alpine
exit 0
EOF
root@infix:/cfg/start.d$ chmod +x 20-enable-container.sh

Reboot to activate the changes. To activate the changes without rebooting, run the script and call initctl reload.

For more information, see Containers in Infix.

Note: Neither Frr (Zebra/OSPF/BFD) or podman are enabled in the official Infix builds. Some customers have them enabled in their specific builds, and you can of course also enable it yourself in Infix by using make menuconfig followed by rebuilding the image.

Customizing Services

When running containers a common question is: "what if we want an outside SSH connection on port 22 to be forwarded to the container instead of the Infix system?" There are two possible answers that currently require a Hybrid Mode fix since it is not yet possible to configure the SSH daemon:

1. Disable SSH daemon
2. Run SSH daemon on another port

The first one is simple, use what you have learned above about start.d scripts and add one that does initctl disable sshd.

The second is a little bit more involved:

root@infix:/cfg/start.d$ cat <<EOF >10-custom-sshd-port.sh
#!/bin/sh
echo SSHD_OPTS=\"-p222\" > /etc/default/sshd
EOF
root@infix:/cfg/start.d$ chmod +x 10-custom-sshd-port.sh

---

1. A RESTCONF based WebUI is also in progress. ↩︎