This document tries to describe the details of the network-ng data model and how all the pieces are combined.
and other associated classes represent the network configuration in a backend
agnostic way. It should not matter whether you are using
sysconfig files, NetworkManager or
The systems' configuration is read using configuration readers, which are special classes which implements the logic to find out the details and build a properobject. Once the wanted modifications are performed to this configuration object, it could be written in the filesystem by using a configuration writer.
+--------+ +---------+ reader ----> | config | -- user --> | config' |----> writer ^ +--------+ +---------+ | | | | +--------+ | +---------------------| system |<--------------------+ +--------+
Obviously, we should implement configuration readers and writers for whathever backend we would like
to support. At this point of time, only
Autoinst are supported.
The Configuration Classes
offers and API to deal with network configuration, but it collaborates with other classes. These are the most relevant ones:
- : this class holds a list of interfaces and offers a query API (e.g., find all the ethernet interfaces).
- : keeps interfaces information. There are one kind of interfaces at this point of time: physical and virtual ones.
- : this class holds a list of connection configurations and offers a query API.
- : describes a configuration that can be applied to an interface. Currently it is bound to an interface name, but we plan to provide more advanced matchers.
- : holds routing information, including IP forwarding settings, routing tables, etc.
- : holds the DNS configuration, including nameservers, search domains, etc.
- and : these classes offer and API to handle udev rules which are involved in interface renaming and driver assignment.
- and : API to ask for hardware information.
- : offers information about available drivers and their options.
As mentioned above, Y2Network is designed to support different backends. It is expected to implement a reader and a writer for each backend (except for AutoYaST, which is an special case). The reader will be responsible for checking the system's configuration and building aobject, containing interfaces, configurations, routes, etc. On the other hand, the writer will be responsible for updating the system using that configuration object.
As a developer, you rarely will need to access to readers/writers because
Yast::Lan already offers
an API to read and write the configuration. See the Accessing the
Configuration section for further details.
The sysconfig backend support is composed by these files:
src/lib/y2network/sysconfig ├── config_reader.rb <- READER ├── config_writer.rb <- WRITER ├── connection_config_reader.rb ├── connection_config_readers │ ├── ethernet.rb │ ├── wireless.rb │ └── ... ├── connection_config_writer.rb ├── connection_config_writers │ ├── ethernet.rb │ ├── wireless.rb │ └── ... ├── dns_reader.rb ├── dns_writer.rb ├── interface_file.rb ├── interfaces_reader.rb └── routes_file.rb
and are the reader and writer classes. Each of them cooperates with a set of ancillary classes in order to get the job done.
are involved in reading the configuration. The logic
to read the configuration for a connection (e.g.,
ifcfg-wlan0, etc.) is implemented
in a set of smaller classes (one for each time of connection) under
, and , including smaller classes under , are involved in writing the configuration.
Last but not least, there are additional classes like
AutoYaST is a special case in the sense that it reads the information from a profile, instead of
using the running system as reference. Additionally, it does not implement a writer because the
configuration will be written using a different backend (like
src/lib/y2network/autoinst/ ├── config_reader.rb ├── dns_reader.rb ├── interfaces_reader.rb ├── routing_reader.rb ├── type_detector.rb └── udev_rules_reader.rb
Another important aspect of the AutoYaST support is that, instead of using a big
information included in the profile is handled through a set of classes in
(see ). However, there
is some preprocessing that is still done using the original
Accessing the Configuration
Yast::Lan module is still the entry point to read and write the network configuration.
Basically, it keeps two configuration objects, one for the running system and another want for the
.import "Lan" ::.read(:cache) system_config = ::.system_config yast_config = ::.yast_config system_config == yast_config # => true # let's change IP forwarding settings yast_config.routing.forward_ipv4 = !system_config.routing.forward_ipv4 system_config == yast_config # => false # write the new configuration ::.Write
Any change you want to apply to the running system should be performed by modifying the
yast_config and writing the changes.
New UI layer
Interface Configuration Builders
In the old code, there was no clear separation between UI and business logic. In order to improve the situation, we introduced the concept of interface configuration builders.
We already have implemented support for several interface types. You can find them under the Y2Network::InterfaceConfigBuilders namespace.
The user interaction is driven by a set of sequences, which determines the dialogs are shown to the user. Each of those dialogs contain a set of widgets, usually grouped in tabs. The content of the dialog depends on the interface type.
Below you can find some pointers to relevant sequences, dialogs and widgets: