Veth interfaces should be shown as Ethernet from
nm_device_get_type_description in order to provide backward
compatibility.
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
As NMDeviceVeth has a NMDeviceEthernet as parent, it should use PRIO_20
in order to report NMDeviceVeth when configured and do not report
NMDeviceEthernet.
An unit test case has been added.
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
In commit 201c153e25 ('libnm: fix GObject Introspection annotations
for functions returning a GPtrArray') these annotations were changed
to fix Vala bindings. However, bindings may treat the transfer
annotation for GPtrArray differently, so depending on the binding
we either get a leak or a double free.
It's unclear how to fix that. For now, just add a warning to the
documentation to avoid it.
The following reproducer leads to a crash:
#!/bin/python
import gi
gi.require_version("NM", "1.0")
from gi.repository import NM
def _pr(msg):
NM.utils_print(0, msg + "\n")
def process(nmc):
for device in nmc.get_devices():
cons = device.filter_connections(nmc.get_connections())
_pr(
"device %s (%s) has %s compatible connections"
% (device.get_iface(), NM.Object.get_path(device), len(cons))
)
process(NM.Client.new())
See-also: https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/305
GObject's dispose() functions may be called multiple times
to break reference cycles.
As dispose() calls _init_release_all(), the object might
already be partially destroyed.
Fixes: ce0e898fb4 ('libnm: refactor caching of D-Bus objects in NMClient')
NetworkManager is now able to configure veth interfaces throught the
NMSettingVeth. Veth interfaces only have "peer" property.
In order to support Veth interfaces in NetworkManager the design need
to pass the following requirements:
* Veth setting only has "peer" attribute.
* Ethernet profiles must be applicable to Veth interfaces.
* When creating a veth interface, the peer will be managed by
NetworkManager but will not have a profile.
* Veth connection can reapply only if the peer has not been modified.
* In order to modify the veth peer, NetworkManager must deactivate the
connection and create a new one with peer modified.
In general, it should support the basis of veth interfaces but without
breaking any existing feature or use case. The users that are using veth
interfaces as ethernet should not notice anything changed unless they
specified the veth peer setting.
Creating a Veth interface in NetworkManager is useful even without the
support for namespaces for some use cases, e.g "connecting one side of
the veth to an OVS bridge and the other side to a Linux bridge" this is
done when using OVN kubernetes [1][2]. In addition, it would provide
persistent configuration and rollback support for Veth interfaces.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1885605
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1894139
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
NMDeviceEthernet will be used to support Veth interfaces. Therefore, it
needs to be defined on libnm/nm-libnm-utils.h
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
The type information of NMObject is entirely static. And there
are certain conditions how this information should be. Add some
more checks.
We need priv_ptr_offset set if (and only if) we also have
property_ao_info or property_o_info registered.
This patch is replacing NML_DBUS_META_INTERFACE_PRIO_INSTANTIATE_LOW
with NML_DBUS_META_INTERFACE_PRIO_INSTANTIATE_10 and
NML_DBUS_META_INTERFACE_PRIO_INSTANTIATE_HIGH with
NML_DBUS_META_INTERFACE_PRIO_INSTANTIATE_30. In addition it is
introducing NML_DBUS_META_INTERFACE_PRIO_INSTANTIATE_20 which is a
middle point between the existing priorities.
This new priority is needed due to Veth support incoming. It will be
used to prevent the creation a NMDeviceWired instance.
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
[thaller@redhat.com: split original patch]
We will need more levels of priority. Change the naming
to make room for that.
sed 's/NML_DBUS_META_INTERFACE_PRIO_INSTANTIATE_LOW/NML_DBUS_META_INTERFACE_PRIO_INSTANTIATE_10/g' `git grep -l NML_DBUS_META_INTERFACE_PRIO_INSTANTIATE_ ` -i
sed 's/NML_DBUS_META_INTERFACE_PRIO_INSTANTIATE_LOW/NML_DBUS_META_INTERFACE_PRIO_INSTANTIATE_10/g' `git grep -l NML_DBUS_META_INTERFACE_PRIO_INSTANTIATE_ ` -i
./contrib/scripts/nm-code-format-container.sh
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
[thaller@redhat.com: split original patch]
libnm supports verbose debug logging by setting "LIBNM_CLIENT_DEBUG"
environment variable. That mechanism uses g_printerr() (or g_print()).
When testing an application it's useful to combine printf debugging
with this debug logging. However, python's print() statement is
additionally buffered and not in sync with the logging functions that
libnm uses.
As far as I see, g_print() and g_printerr() is not accessible via
introspections/pygobject, probably because these are variadic functions.
Add nm_utils_print() to libnm. This ensures to use the same logging
mechanism as libnm.
Run:
./contrib/scripts/nm-code-format.sh -i
./contrib/scripts/nm-code-format.sh -i
Yes, it needs to run twice because the first run doesn't yet produce the
final result.
Signed-off-by: Antonio Cardace <acardace@redhat.com>
nm_setting_ip4_config_get_dhcp_vendor_class_identifier() was
backported to nm-1-26 branch, and will be released as 1.26.4.
As such, on the stable branch the symbol will be placed in a
separate symbol version ("libnm_1_26_4").
To support the upgrade path from 1.26.4+ to 1.28+, we
want this symbol also present on master.
Signed-off-by: Antonio Cardace <acardace@redhat.com>
Use a macro that uses NM_CAST_STRV_CC() to cast the strv argument. Note that
NM_CAST_STRV_CC() uses C11's _Generic() to check whether the argument is
of a valid type.
Trace logging from libnm is verbose. So, by default we print trace
messages to stderr. However, that means that messages printed to stdout
are not in sync with the trace logging.
That means, if the libnm application prints messages to stdout, and
you'd like to correlate them with trace messages, it is difficult.
Add an option to allow printing trace messages to stdout.
$ LIBNM_CLIENT_DEBUG=trace,stdout nmcli
Possibly redirecting stderr to stdout might also work around the
ordering issue. However, it's not entirely clear how buffering of
the file streams affects this.
When the get_hw_address() method is called on a device object through
GObject-introspection, the device-specific
(e.g. nm_device_ethernet_get_hw_address()) C function is called
instead of the more generic nm_device_get_hw_address().
Those device-specific functions were deprecated in commit 067a3d6c08
('nm-device: expose via D-Bus the 'hw-address' property') and so libnm
will print out deprecation warnings like:
DeprecationWarning: NM.DeviceEthernet.get_hw_address is deprecated
Omit the device-specific function from the introspection output so
that the generic function will be called instead.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/544
Add a new "path" property to the match setting, which can be used to
restrict a connection to devices with a given hardware path. The new
property is a list of patterns that are matched against the ID_PATH
udev property of devices.
ID_PATH represents the topological persistent path of a device and
typically contains a subsystem string (pci, usb, platform, etc.) and a
subsystem-specific identifier. Some examples of paths are:
pci-0000:00:02.0
pci-0000:00:14.0-usb-0:5:1.0
platform-1c40000.ethernet
systemd-networkd also has a "Path=" option to match a device by udev
ID_PATH.
"nm-settings-docs-nmcli.xml" will be generated by a tool that depends on
"clients/common/". The file should thus not be in libnm directory, otherwise
there is a circular dependency.
Move the file to "man/" directory.
For consistency, also move "nm-settings-docs-dbus.xml". Note that we
cannot move "nm-settings-docs-gir.xml" to "man/", because that one is
needed for building clients.
Like the previous commit. Move code that depends on libnm out
of shared to avoid circular dependency.
Also add a readme file explaining the reason for existence of
the helper library.
There is no need that two XML files that essentially hold similar
information are fundamentally different. Make them more alike.
This way, we can use the same tools that operate on either of
these input files.
A significant part of NetworkManager's API are the connection profiles, documented
in `man nm-settings*`. But there are different aspects about profiles, depending
on what you are interested. There is the D-Bus API, nmcli options, keyfile format,
and ifcfg-rh format. Additionally, there is also libnm API.
Add distinct manual pages for the four aspects. Currently the two new manual
pages "nm-settings-dbus" and "nm-settings-nmcli" are still identical to the
former "nm-settings.5" manual. In the future, they will diverge to
account for the differences.
There are the following aspects:
- "dbus"
- "keyfile"
- "ifcfg-rh"
- "nmcli"
For "libnm" we don't generate a separate "nm-settings-libnm" manual
page. That is instead documented via gtk-doc.
Currently the keyfile and ifcfg-rh manual pages only detail settings
which differ. But later I think also these manual pages should contain
all settings that apply.
"nm-settings-docs-dbus.xml" is "nm-settings-docs-gir.xml" merged with
"nm-property-infos-dbus.xml". The name should reflect that, also because
we will get more files with this naming scheme.
The name is bad. For one, we will have more files of the same format
("nm-settings-docs-nmcli.xml").
Also, "libnm/nm-settings-docs.xml" and "libnm/nm-property-docs.xml" had
basically the same file format. Their name should be similar.
Also the tool to generate the file should have a name that reminds to
the file that it creates.
The naming was inconsistent. Rename.
- all the property infos of this kind a now consistently called
"libnm/nm-property-infos-$TAG.xml".
- the script to generate files "libnm/nm-property-infos-$TAG.xml" is
now called "libnm/generate-docs-nm-property-infos.pl".
The script "libnm/generate-setting-docs.py" generates property info based
on GObject introspection data.
Optionally, when creating the manual for D-Bus documentation, it would accept
an argument "--override" to merge the generated information with the information
from an XML generated by "libnm/generate-plugin-docs.xml". Change this.
Instead, let "libnm/generate-setting-docs.py" just do one thing: generate
the XML based on GObject introspection data. Then, a second script
"libnm/generate-docs-nm-settings-docs-merge.py" can merge the XMLs.
Note that currently the manual for "nm-settings-keyfile" only contains
information about properties that are explicitly mentioned for keyfile.
It think that is not right. In NetworkManager there are multiple "aspects"
about connection profiles: D-Bus, libnm, nmcli, keyfile and ifcfg-rh.
When we generate a manual page for any of these aspects, we should always
detail all properties. At least for nmcli and D-Bus. That means, we will
do the merging multiple times. Hence, keep the steps for parsing GObject
introspection data and the merging separate.
Also, "generate-setting-docs.py" and "generate-plugin-docs.pl" should
generate the same XML scheme, so that merge doesn't need special hacks.
That is currently not the case, for example, the override XML contains a
"format" attribute, while the other one contains a "type". Merging these
is a special hack. This should be unified.
Note that nm_setting_ethtool_set_coalesce() used to coerce
"coalesce-adaptive-[rt]x" values to 0 or 1. The alternative
API doesn't do that. But so does nm_setting_option_set()
not tell you whether the value you set is valid. That is
not the options of the setters, for that we have verify().
More general purpose API for generic options of settings.
The predicate function is also nicely usable via bindings.
One question is about the form of the predicate. In this case,
it is convenient to pass nm_ethtool_optname_is_coalesce(). On the
other hand, it's not very flexible as it does not accept a user
data argument. Use NMUtilsPredicateStr here, which is not flexible
but convenient for where it's used.
