Infix now supports static /etc/factory-config.cfg from a rootfs overlay
or /usr/share/product/<VPD.PRODUCT>/etc/factory-config.cfg in addition
to the autogenerated /run/confd/*-config.gen files.
Update the Branding & Releases document with a bit more information on
this rather complex topic.
[skip ci]
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This patch mainly updates the static routing chapter, and adds a new
section on route preferences, but it also makes slight touch-ups at
a few other places as well.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Since /etc is not retained across reboots, the sysrepo startup datastore
is not used to bootstrap the Infix. Instead, /cfg/startup-config.cfg is
used and loaded directly to the running datastore.
For some use-cases when operating directly on sysrepo this causes a lot
of confusion because startup == factory ds until any user calls the CLI
command `copy running-config startup-confg`.
This patch fixes this initial "glitch" by loading the starup datastore
at boot on successful loading of startup-config to unning.
To prevent any unintentional "auto-save" of, e.g., failure-config to
startup-config, we make confd aware of this "sync" operation during
bootstap.
Fixes#625
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This patch allows a user to specify a specific 169.254/16 address that
the zeroconf client starts with when probing for a free address. If the
probe fails it falls back to its default algorithm.
Fixes#628
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
- The test mode, introduced at the config/build phase (commit 241f3f2),
causes the device to start in test-mode when used in GNS3 (or other
environments). This has unintentionally become the default
configuration for the image, which is not desirable and is only
acceptable for the Infix test system. With this update, the original
configuration is preserved, and the test mode is applied only within
the test environment.
- Align the 'dual' topology to use the same template as 'quad'
Fixes#603
To prevent the kernel from setting a random mac address on new bridges,
before we have added any bridge ports, we create bridges using the:
1. Custom mac address from the configuration (phys-address)
2. System base mac from /run/system.json
3. None, if there is no base mac address in system.json, e.g. r2s
Fixes#357
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Now that we have a unified timeout value that all front-ends should
honor, make sure to do so when loading startup-config and
failure-config during boot.
This fixes an issue where the system would fallback to failure-config
even though a legitimate startup-config was available, but took more
than 10s to apply.
Joachim Wiberg