Verifies that RAUC bundles can be installed using NETCONF.
We choose to not add this to the "all" suite for now, as the qeneth
topologies do not run with full disk emulation.
To test locally, configure your "make run" instance to use the UEFI
loader, launch `make run`, and then run:
make INFIX_TESTS=test/case/ietf_system/upgrade.py test-run
This let's us report the installed software versions, before any
updates have been made. Since the info should _not_ be erased in a
factory reset (since the installed software versions will not change),
move the status file to aux, which is the proper place for this class
of information.
- When running with full disk emulation (via GRUB on x86, or U-Boot on
aarch64), there's no way for us to influence the commandline passed
to the kernel, so the console is fixed to ttyS0/AMA0. Therefore,
reintroduce an option to choose the console.
- Use a fixed `nr`s for virtconsoles, so that the gdbserver always
listens on `hvc1`. Ideally, we should use udevs `/dev/virtio-ports/*`
symlinks, but for some reason these point to `/dev/vportXpY` and not
to `/dev/hvcY`. TODO: Figure out what the difference is.
- While we're here, remove the duplicated RTC setup which was
introduced with the virtio-console work a while back.
/dev/ram is accepted by the kernel during boot, but there's no actual
file with this name in /dev, so RAUC will get confused about which
slot is actually one we booted from.
Launches an interactive ipython environment, attached to Infix nodes.
This can be used as a playground for developing tests, testing out
NETCONF operations, etc.
This patch affects the various artiact file names in release tarballs.
The files /etc/os-release and /etc/version in the image use the actual
GIT commit (git describe), as per post-build.sh
Guiding principle: artifacts without release suffix are development or
"nightly" builds. Artifacts *with* release suffix are released ones.
This drops the $GITVER from .img files for consistency with the other
artifacts, e.g. .gns3a and .pkg.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
To set up proper factory defaults in Infix we need to drop the default
/etc/sysrepo datastores, initialized at compile-time by Buildroot when
installing netopeer2. The pre-initialized datastores cannot be set up
with new {factory} data in any other way.
The system factory-config is constructed from two parts: static data and
generated data. The latter is:
- hostname (product name + the three last octets of the base MAC)
- interface defaults (depends on number of ports on the device) that
enable IPv6 link-local on all interfaces, and
- per-device unique SSH hostkey for remote NETCONF access, requires
openssl binary on target. Can maybe use openssh for this (TODO).
The hostkeys are saved in /cfg/factory.d/ to prevent them from being
regenerated on every boot.
The script gen-hostkeys and the update of 10-netconf-server.json are
inspired by the netopeer2 scripts merge_hostkey.sh and merge_config.sh,
which do just about the same thing for regular systems.
We bootstrap sysrepo early with all the required models, netopeer2 as
well as our own, by calling sysrepoctl with initial data for {factory}
and {startup} datastores. A local patch to sysrepo is used to allow it
to look for an /etc/factory-default.json instead of compile-time default
data, the patch allows us to have variable amount of objects in the init
data, e.g. number of interface objects.
A system startup-config is generated, if one is mising, from {running}.
We then drop the initial {running} datastore before starting the daemons
sysrepo-plugind and netopeer2-server so that they, and our plugins, are
ready when we load the system startup-config.
Some sanity checks and debug possibilities:
- Ensure /etc/sysrepo exists before copying factory-config
- Keep factory-default.json for debug
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
- Collect all test related targets under the test- prefix.
- Add target to run test suite against a `make run` instance. The
intended use-case is that you are testing out a new build with `make
run`, and then realize that you want to run some tests. With this
change, it is now possible to run `make infix-run-check` from a
separate terminal - which attaches to the running instance and runs
the tests.
- Provide -sh targets to spawn interactive environments, which is
useful during debugging.
- Allow the user to supply a custom suite or list of tests to be run
by 9PM.
Primarily intended for minimal/testing images, but likely also useful
for other use-cases as well.
Defaults remain to sign all images.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Since qemu.sh is now tied to the directory it's ran from, it makes
sense to change into that directory before starting to resolve any
file paths. This let's us start the script from any directory without
the need for any (cd && qemu) subshell.
This change drops Qemu menuconfig from the regular 'make menuconfig' in
favor of full release tarball support. Meaning "make update-defconfig"
will not longer cause unwanted diffs for Qemu defaults checked in when
the defconfigs are updated.
Details:
- For "make run, run-menuconfig" and bootstrapping qemu.cfg we want to
use the Buildroot menuconfig system. However, we must set the proper
environment variables for it to not overwrite our product's .config,
so the calls to conf and mconf are not pretty.
- The qemu.sh script can probably be cleaned up further, I've just set
a CONFIG_ prefix to all variables and dropped any images/ prefix vs.
the original. The CONFIG_ prefix is to make the qemu.cfg compatible
with kconfig-mconf from the kconfig-frontends package.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
First basic step, we also want a menuconfig-like way of changing the
settings, e.g., networking options.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
When evolving to a new generation fails, users will typically abandon
it (so that a new attempt can be made). However, the generated
scripts and the logged output is very valuable from a debugging
perspective.
Therefore, keep the data around by just renaming the generation
directory.
Later, we can include these directories in the garbage collecting
process, if we want to.
- Keys stored in system specific directory /var/run/sshd/$USER.keys
- Keys are regenerated on each corresponding reconfiguration event
- Deletion of key(s) or user remove all keys
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
On May 10, 2023, @troglobit wrote:
> Initial proposal for factory-config, based on example from RFC8341.
This gives the admin user the ability to configure the device over
NETCONF.
This patch adds a new user "admin" with the password "admin". The
password is hashed with sha512 ($6) as a hint to new users attempting
to change the password (avoid the weakest algorithms).
Signed-off-by: Richard Alpe <richard@bit42.se>
Initial analysis of system default users gives that there is no real
need for a default 'factory' user to trigger a factory reset. On an
actual physical device we will have a reset button or a menu option in
the bootloader to trigger factory reset, and in both physical and
virtual (GNS3) devices a logged in admin user can call the factory
command.
A virtual device that cannot be logged in to will have to be removed and
have its persistent backing store deleted, but that is the only real
downside to removing this user. The idea is to set a kernel command
line flag from the bootloader, and that could also be done from, e.g.,
GNS3.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
The /var, and particularly /var/lib, directories are used for persistent
storage for various system daemons. While adding support for containers
it became clear we had to change how we make these directories writable.
Both LXC and Podman use OverlayFS for the writable layer, and you cannot
set up an overlay on top of another overlay.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Podman (POD manager) is an open source tool for developing, managing,
and running containers on your Linux systems.
Based on work by Christian Stewart and Nathaniel Husted.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
A generic replacement for src/net with some advantages:
- Shell script is well-suited to these kinds of tasks, making this
implementation much simpler.
- Allow arbitrary number of actions (not just init/exit), this can be
used to implement things like `dagger exec up/down`.
- Allow arbitrary number of scripts for each action/node tuple. This
will let us handle more complex scenarios in confd without having to
fiddle about with src/net.
This allows you to define a single "logical" config that can be
tailored to the specific system based on the available interfaces,
base MAC address etc.
This commit enables support for running custom startup scripts at boot,
allowing a mix of a NETCONF-based system and Classic /etc. For example,
use NETCONF to set up network interfaces, users, etc. and runparts for
enabling and configuring the device as an OSPF router.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
