This is fixed in libnm. Resetting the GObject property clears the list
of watchers and tx-hashes.
Since nmcli requires a libnm version >= itself, this workaround
is no longer necessary.
For each artifical team property we need to track whether it was
explicitly set (i.e., present in JSON/GVariant or set by the user
via NMSettingTeam/NMSettingTeamPort API).
--
As a plus, libnm is now no longer concerned with the underling default values
that teamd uses. For example, the effective default value for "notify_peers.count"
depends on the selected runner. But libnm does not need to care, it only cares
wheher the property is set in JSON or not. This also means that the default (e.g. as
interesting to `nmcli -o con show $PROFILE`) is independent from other properties
(like the runner).
Also change the default value for the GObject properties of
NMSettingTeam and NMSettingTeamPort to indicate the "unset" value.
For most properties, the default value is a special value that is
not a valid configuration itself.
For some properties the default value is itself a valid value, namely,
"runner.active", "runner.fast_rate", "port.sticky" and "port.prio".
As far as NMTeamSetting is concerned, it distinguishes between unset
value and set value (including the default value). That means,
when it parses a JSON or GVariant, it will remember whether the property
was present or not.
When using API of NMSettingTeam/NMSettingTeamPort to set a property to the
default value, it marks the property as unset. For example, setting
NM_SETTING_TEAM_RUNNER_ACTIVE to TRUE (the default), means that the
value will not be serialized to JSON/GVariant. For the above 4
properties (where the default value is itself a valid value) this is a
limitation of libnm API, as it does not allow to explicitly set
'"runner": { "active": true }'. See SET_FIELD_MODE_SET_UNLESS_DEFAULT,
Note that changing the default value for properties of NMSetting is problematic,
because it changes behavior for how settings are parsed from keyfile/GVariant.
For team settings that's not the case, because if a JSON "config" is
present, all other properties are ignore. Also, we serialize properties
to JSON/GVariant depending on whether it's marked as present, and not
whether the value is set to the default (_nm_team_settings_property_to_dbus()).
--
While at it, sticter validate the settings. Note that if a setting is
initialized from JSON, the strict validation is not not performed. That
means, such a setting will always validate, regardless whether the values
in JSON are invalid according to libnm. Only when using the extended
properties, strict validation is turned on.
Note that libnm serializes the properties to GVariant both as JSON "config"
and extended properties. Since when parsing a setting from GVariant will
prefer the "config" (if present), in most cases also validation is
performed.
Likewise, settings plugins (keyfile, ifcfg-rh) only persist the JSON
config to disk. When loading a setting from file, strict validation is
also not performed.
The stricter validation only happens if as last operation one of the
artificial properties was set, or if the setting was created from a
GVariant that has no "config" field.
--
This is a (another) change in behavior.
The order of the fields in the JSON object does not really matter.
Note that with the recent rework the order changed. Before it was
arbitrarily, now it still is arbitrary.
Reorder again, to follow the same order as `man teamd.conf`.
This matters for properties that don't have 0/NULL/FALSE as
default value and when setting an empty property with
$ nmcli connection modify "$PROFILE" setting.property ''
Fixes: 3c82db710f ('cli: reset default value of properties via set_fcn()')
The early boot tooling gets the root-path from our state file due to a
lack of a better way to do that. However, when booting with NFS root,
the root path alone is not sufficient; the server address is communicated
via the next-server option. Save that one in the state file as well.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/168
clang on CentOS 7.6 (3.4.2-9.el7) warns:
CC clients/tui/newt/clients_tui_newt_libnmt_newt_a-nmt-newt-button.o
In file included from ../clients/tui/newt/nmt-newt-button.c:26:
In file included from ../shared/nm-default.h:280:
../shared/nm-glib-aux/nm-macros-internal.h:1617:2: error: unknown warning group -Wstringop-truncation, ignored [-Werror,-Wunknown-pragmas]
NM_PRAGMA_WARNING_DISABLE ("-Wstringop-truncation");
^
../shared/nm-glib-aux/nm-macros-internal.h:419:9: note: expanded from macro NM_PRAGMA_WARNING_DISABLE
_Pragma(_NM_PRAGMA_WARNING_DO(warning))
^
<scratch space>:109:25: note: expanded from here
GCC diagnostic ignored "-Wstringop-truncation"
^
This warning totally defeats the purpose of why we use the pragma in the
first place.
I saw this timeout reached in our gitlab-ci. I think it was due to the machine
being busy and taking more than 2 seconds. Assuming the timeout was just too short,
increase it to 4 seconds.
Clang (3.4.2-9.el7) on CentOS 7.6 fails related to nm_hash_update_vals().
Clang seems to dislike passing certain complex arguments to typeof().
I'd prefer to fix nm_hash_update_vals() to not have this problem,
but I don't know how.
This works around the issue.
clang (3.4.2-9.el7) on CentOS 7.6 fails related to nm_hash_update_vals().
I am not even quoting the error message, it's totally non-understandable.
nm_hash_update_vals() uses typeof(), and in some obscure cases, clang dislikes
when the argument itself is some complex macro. I didn't fully understand why,
but this works around it.
I would prefer to fix nm_hash_update_vals() to not have this limitation.
But I don't know how.
There is probably no downside to have this an inline function instead of
a macro.
Clang 3.4.2-9.el7 on CentOS7.6 complains about missing generic type match:
../dispatcher/nm-dispatcher.c:243:2: error: controlling expression type 'const Request *const' (aka 'const struct Request *const') not compatible with any generic association type
_LOG_R_D (request, "start running ordered scripts...");
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fixes: 17dc6a9da6 ('shared: add _NM_ENSURE_TYPE_CONST()')
This code is now unused.
Also, it does not seem state of the art to me
anymore.
Drop it, it could always be resurrected if need by, but maybe
GFileMonitor could be used instead.
It's deprecated and off by default for a long time.
It is bad to automatically reload connection profiles. For example, ifcfg
files may consist of multiple files, there is no guarantee that we
pick up the connection when it's fully written.
Just don't do this anymore.
Users should use D-Bus API or `nmcli connection reload` or `nmcli
connection load $FILENAME` to reload profiles from disk.
If the AddAndActivate() caller didn't explicitely a MAC address, default
to pinpointing the connection to the device by the means of an interface
name. This makes more sense than a MAC address with stable device names.
If the AddAndActivate() caller didn't explicitely a MAC address, default
to pinpointing the connection to the device by the means of an interface
name. This makes more sense than a MAC address with stable device names.
If the AddAndActivate() caller didn't explicitely a MAC address, default
to pinpointing the connection to the device by the means of an interface
name. This makes more sense than a MAC address with stable device names.
This is used to indicate the network dracut module should fall back to
configure network automatically (as with ip=dhcp was specified) if
there's no other network configuration present on the command line.
The option is documented in dracut.cmdline(7).
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/167
Before commit e3ac45c026 the reader set the private key in the
setting using the libnm function, which also set the key as client
certificate if it was in PKCS #12 format.
After the commit, existing connections with a PKCS #12 private key but
without a client certificate became invalid. Restore the old behavior.
Fixes: e3ac45c026 ('ifcfg-rh: don't use 802-1x certifcate setter functions')
When changing the number of VFs the kernel can block for very long
time in the write() to sysfs, especially if autoprobe-drivers is
enabled. Turn the nm_platform_link_set_sriov_params() into an
asynchronous function.
During shutdown, systemd should first stop NetworkManager and then
the dispatcher service. Note that dispatcher service is D-Bus activated,
so the two services don't Want/Require each other. But the ordering
still matters.
