Files
infix/doc/variant.md
T
Joachim Wiberg 2eb487ebcd doc: refactor, let first page be table of contents
- Drop doc/README.md symlink to variant.md
 - Make doc/README.md the table of contents
 - Clean up variant.md, OSPF and containers now fully supported

Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
2024-03-22 05:34:36 +01:00

2.6 KiB

Infix Variants

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

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 CLI1 .

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.

For more information, see Containers in Infix.

Classic

Infix Classic is very much like a traditional embedded Linux system. Stripped down, single read-only image, reusing the same Linux kernel and Buildroot base as the NETCONF variant. Unlike the NETCONF variant, it is up to the administrator to manually modify system configuration files in /etc2 and control system services using the initctl tool.

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

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.

Note: the Classic builds are legacy at this point. They were initially used for educational purposes, and sometimes as slightly more useful end-devices in GNS3. Little to no testing is done on them and they may eventually be migrated to a separate repository.


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

  2. In Classic builds the /etc directory is saved across reboots on a separate read-write partition. ↩︎