This patch adds operational data support for system services. The
data is in a generic format but is intended to be able to represent
finit information (initctl) nicely.
The reason for augmenting this to ietf-system and not to
infix-services is that we consider this generic system information
which is totally disconnected from what ever services infix might
provide.
In this first state we only support pid, name, description and state.
Making the data look something like:
"infix-system:services": {
"service": [
{
"pid": 1185,
"name": "udevd",
"status": "running",
"description": "Device event daemon (udev)"
}]
Signed-off-by: Richard Alpe <richard@bit42.se>
Add supoprt for infix-firewall.yang, modeled on the zone-based firewalld
The terminology is a mix of firewalld, classic netfilter and inspired by
Ubiquity. E.g., zone 'policy' -> 'action', and the zone matrix overview.
- Port forwarding allows forwarding a range of ports
- Operational data comes from firewalld active rules
- Firewall logging goes to /var/log/firewall.log
- Show implicit/built-in rules and zones (HOST) in firewall matrix,
includes "locked" policy for the default-drop behavior
- The zone services field in admin-exec 'show firewall' shows ANY when
the zone default action is set to 'accept'
- Zone 'forwarding' and 'masquerade' settings live in Infix in the
policys instead, meaning users need to explicitly add a policy
to allow both intra-zone and inter-zone forwarding
- Support for emergency lockdown (kill switch)
- Pre-defined services (xml+enums) are filtered and included as a
separate YANG model, extensions added for netconf and restconf
- Includes initial support for firewalld rich rules
firewalld policy rules, including rich rules, have an obnoxious priority
field which is extremely hard to get right, so in Infix we use the far
superior YANG construct 'ordered-by user;'. This ensure all rules are
generated in that order by setting the priority field, on read-back from
firewalld (operational) the priority field is used to sort the output
of rules in the CLI.
Fixes#448
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Fix a bug where systems with OSPF enabled on some, but not all,
interfaces would cause the OSPF iterator to fail when accessing
iface['area'], which was missing. This caused the ospf_status.py
tool to return {}, resulting in empty OSPF data in sysrepo.
Fixes#1169 Expected neighbors not shown in sysrepocfg
Signed-off-by: Richard Alpe <richard@bit42.se>
Prior to this commit yanger looked at the running system using
os.path..., this meant that the static reply / capture data wasn't
used properly. This resulted in strange behavior during unit testing
on GitHub runners where USB ports are missing.
Signed-off-by: Richard Alpe <richard@bit42.se>
Libyang is smart, it "fixes" the timezone for you, this was overriden by a
hack in netconf.py and restconf.py, but what you really want is to see
in operational what the current timezone is.
When running a DHCP test `resolvconf -l` looked like this:
admin@client:~$ resolvconf -l
search example.com # e5
admin@client:~$
This resulted in broken result when reading operational data from
system-state (which used resolvonf -l)
Counters should follow the format from ieee802-ethernet-interface
model, which use:
- in/out for Rx/Tx
- plural from
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
- dnsmasq:
- allow listening to all interfaces again to serve DHCP leases
- disable most of the default DHCP options, keep broadcast and
netmask because when dnsmasq can infer these they are better
than breaking networking for clients -- note, they can still
be overridden from global/subnet/host scope -- and for relay
setups they need to be supplied anyway
- confd:
- drop per-interface dnsmasq, although practical for many use-cases,
having a per-subnet focused server means improved integration with
future stand-alone dhcp relay setup
- implement suggested, simplified, yang model
Fixes#703
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This patch introduces a new yang yang model for DHCP server and relay,
using dnsmasq to provide the functionality on a per-interface basis.
Available DHCP options will be queried by confd on startup and can
then be configured in a flexible manner.
The DHCP option 82 feature has been realized by patching dnsmasq
(see patches/dnsmasq/2.90/0000-relay-agent-info.patch).
Signed-off-by: Stefan Schlosser <sgs@grmmbl.org>
Similar to the run_multiline() method, sometimes files contain more than
one line and a common read_multiline() quickly becomes useful. This is
currently only used by ietf-system for reading /etc/resolv.conf.head.
Also, fix pylint warning for missing encoding to all open() calls.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Due to #902 (which has not been root caused at this time), podman may
indicate the existance of an interface that yanger is not able to
locate in any namespace. Therefore, make sure that we verify that the
interface was actually found before trying to create the operational
data for it.
Break up the --test parameter into either:
--capture: Write system command output to a local directory for later
consumption by...
--replay: Which can replay a previous capture
Rename --wrap-commands => --cmd-prefix
Allow all host commands to be run with a prefix (e.g. `ssh
user@remotehost sudo`), such that yanger can be tested against the
current state of a remote system.
If a command wrapper _and_ a test directory is specified, the output
of all commands and files are recorded for use by a future test
execution.
Example:
1. Launch a `make run` instance and setup some config for which we
want to test yanger and cli-pretty
2. Capture the output of all commands needed to produce the data for
some YANG model:
`yanger -t /tmp/ifs -w "ixll -A ssh qtap1 sudo" ietf-interfaces`
3. Kill the instance (we do not need it any more)
4. Test cli-pretty using the captured state:
`yanger -t /tmp/ifs ietf-interfaces | cli-pretty show-interfaces
`
The yanger source grown significantly, code is disorganized, the
namespace is all over the place, etc.
Take a stab at remedying the situation by splitting out the individual
YANG models in separate Python modules, starting with ietf-system.
Rather than explicitly defining the sources, specify the package names
and let poetry figure out the details. Otherwise, subpackages are not
included, which we want to start using in yanger.
Joachim Wiberg