The present version of the EC2 metadata API (IMDSv2) requires a header
with a token to be present in all requests. The token is essentially a
cookie that's not actually a cookie that's obtained with a PUT call that
doesn't put anything. Apparently it's too easy to trick someone into
calling a GET method.
EC2 now supports IMDSv2 everywhere with IMDSv1 being optional, so let's
just use IMDSv2 unconditionally. Also, the presence of a token API can
be used to detect the AWS EC2 cloud.
Conflicts:
- code format
- missing 494819bbbf ("cloud-setup: move common code for get_config()
to base class and improve cancellation"). From it we only needed
the `get_config_data->self` part, but used g_task_get_source_object
instead.
- missing 5fb2f7e717 ("cloud-setup/trivial: rename "response_data"
variable")
https://bugzilla.redhat.com/show_bug.cgi?id=2151986
(cherry picked from commit 8b7e12c2d6)
(cherry picked from commit 429f36cd81)
(cherry picked from commit e3ac982b32)
(cherry picked from commit c5a3e739b1)
(cherry picked from commit ee157ad48b)
(cherry picked from commit ae3ec36462)
(cherry picked from commit 865fe0732e)
(cherry picked from commit d75e307ebc)
(cherry picked from commit ef3d4758d6)
We'll need to be able to issue PUT calls.
Conflicts: code formatting, missing nmcs-provider-aliyun and azure,
missing commit 494819bbbf ("cloud-setup: move common code for
get_config() to base class and improve cancellation")
(cherry picked from commit cd74d75002)
(cherry picked from commit eff4372045)
(cherry picked from commit aaf66e9174)
(cherry picked from commit 3d94f4fdf9)
(cherry picked from commit 181466c6da)
(cherry picked from commit 7243307bb8)
(cherry picked from commit 1aa88024cb)
(cherry picked from commit 59b5a8fdcb)
(cherry picked from commit 0962b6e23d)
We're going to extend those to issue methods other than GET.
Also, "request" would've been too long, "req" looks nicer.
Conflicts: code formatting, missing trivial commit in,
provider-azure, missing 494819bbbf ("cloud-setup: move common
code for get_config() to base class and improve cancellation")
(cherry picked from commit 85ce088616)
(cherry picked from commit 6e8cfbae32)
(cherry picked from commit 20cd11ee49)
(cherry picked from commit 9ce530fa7a)
(cherry picked from commit d6d161a31d)
(cherry picked from commit 977fc2c8c5)
(cherry picked from commit 89ee76409b)
(cherry picked from commit e3d23c7ee0)
No need to do a deep clone. The strv array is not ever modified and we
pack it together in one memory allocation.
Conflicts: nm_strv_dup_packed is still called nm_utils_strv_dup_packed.
Code formatting.
(cherry picked from commit 599fe234ea)
(cherry picked from commit 3787eacac9)
(cherry picked from commit 89a6ce575d)
(cherry picked from commit d14dc95be3)
(cherry picked from commit 7e516418e0)
(cherry picked from commit becb47826a)
(cherry picked from commit 4704e14100)
(cherry picked from commit 23b03def98)
(cherry picked from commit b52cbad24b)
It's not used anywhere.
Conflicts: code formatting only
(cherry picked from commit ce225b2c06)
(cherry picked from commit 23b9514080)
(cherry picked from commit 36d417af60)
(cherry picked from commit d83537bff5)
(cherry picked from commit f584b9c97b)
(cherry picked from commit f59f629431)
(cherry picked from commit 1885ff2c65)
(cherry picked from commit cab0b16d3c)
(cherry picked from commit 3a55788885)
NetworkManager supports a very limited set of qdiscs. If users want to
configure a unsupported qdisc, they need to do it outside of
NetworkManager using tc.
The problem is that NM also removes all qdiscs and filters during
activation if the connection doesn't contain a TC setting. Therefore,
setting TC configuration outside of NM is hard because users need to
do it *after* the connection is up (for example through a dispatcher
script).
Let NM consider the presence (or absence) of a TC setting in the
connection to determine whether NM should configure (or not) qdiscs
and filters on the interface. We already do something similar for
SR-IOV configuration.
Since new connections don't have the TC setting, the new behavior
(ignore existing configuration) will be the default. The impact of
this change in different scenarios is:
- the user previously configured TC settings via NM. This continues
to work as before;
- the user didn't set any qdiscs or filters in the connection, and
expected NM to clear them from the interface during activation.
Here there is a change in behavior, but it seems unlikely that
anybody relied on the old one;
- the user didn't care about qdiscs and filters; NM removed all
qdiscs upon activation, and so the default qdisc from kernel was
used. After this change, NM will not touch qdiscs and the default
qdisc will be used, as before;
- the user set a different qdisc via tc and NM cleared it during
activation. Now this will work as expected.
So, the new default behavior seems better than the previous one.
https://bugzilla.redhat.com/show_bug.cgi?id=1928078
(cherry picked from commit a48edd0410)
(cherry picked from commit 2a8181bcd7)
(cherry picked from commit de1449375a)
If previously the profile would track two addresses ("10.116.1.130/24",
"10.116.1.65/24"), and during an update the second address was removed
(leaving "10.116.1.130/24"), then the addresses of the profile were
wrongly not changed.
The effect is that removing a secondary IP address might not take
effect.
Fix that.
https://bugzilla.redhat.com/show_bug.cgi?id=1920838
Fixes: 69f048bf0c ('cloud-setup: add tool for automatic IP configuration in cloud')
(cherry picked from commit bbd36be44a)
(cherry picked from commit c861e87b7f)
With "connection.multi-connect", a profile can be activated multiple
times on a device with `nmcli connection show`. Also, a profile may be
in the process of deactivating on one device, while activating on
another one. So, in general it's possible that `nmcli connection show`
lists the same profile on multiple lines (reflecting their multiple
activation states).
If the user requests no fields that are part of the activation state,
then the active connections are ignored. For example with `nmcli
-f UUID,NAME connection show`. In that case, each profile is listed only
once.
On the other hand, with `nmcli -g UUID,NAME,DEVICE connection show` the
user again requested also to see the activation state, and a profile can
appear multiple times.
To handle that, we need to consider which fields were requested.
There was a bug where the "ACTIVE" field was not treated as part of the
activation state. That results in `nmcli -f UUID,NAME,ACTIVE connection
show` always returning "no". Fix that.
Fixes: a1b25a47b0 ('cli: rework printing of `nmcli connection` for multiple active connections')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/547https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/642
(cherry picked from commit 4eb3b5b9dd)
(cherry picked from commit bb802507e4)
Seems with LTO the compiler can sometimes think that thes variables are
uninitialized. Usually those code paths are only after an assertion was
hit (g_return*()), but we still need to workaround the warning.
(cherry picked from commit 70971d1141)
A profile can configure "connection.wait-device-timeout" to indicate
that startup complete is blocked until a suitable device around.
This is useful for NetworkManager-wait-online and initrd mode.
Previously, we looked at NMPlatform whether a link with matching
interface-name was present. That is wrong because it cannot handle
profiles that rely on "ethernet.mac-address" setting or other "match"
settings. Also, the mere presence of the link does not yet mean
that the NMDevice was created and ready. In fact, there is a race here:
NMPlatform indicates that the device is ready (unblocking NMSettings),
but there is no corresponding NMDevice yet which keeps NetworkManager
busy to block startup complete.
Rework this. Now, only check whether there is a compatible device for
the profile.
Since we wait for compatible devices, it works now not only for the
interface name. Note that we do some optimizations so that we don't have
to re-evaluate all profiles (w.r.t. all devices) whenever something on the
device changes: we only care about this when all devices finally become
ready.
Also, we no longer start the timeout for "connection.wait-device-timeout"
when the profile appears. Instead, there is one system-wide start time
(NMSettingsPrivate.startup_complete_start_timestamp_msec). That simplifies
code and makes sense: we start waiting when NetworkManager is starting, not
when the profile gets added. Also, we wait for all profiles to become
ready together.
(cherry picked from commit 3df662f534)
It's not a severe issue, because the GetConfigMetadataData struct is
larger than GetConfigMetadataMac.
Fixes: 69f048bf0c ('cloud-setup: add tool for automatic IP configuration in cloud')
(cherry picked from commit 460afe6d50)
Without this, `nmcli device modify "$DEVICE"` leads to a crash. At least
since commit c5d45848dd ('cli: mark argv argument for command line
parsing as const'), when this happens.
That is, because it passes a NULL strv array with argc being set to
zero. nmc_process_connection_properties() is not supposed to access
the array, if there are no elements there.
Fixes: c5d45848dd ('cli: mark argv argument for command line parsing as const')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/492
(cherry picked from commit 09c94bc24f)
When configuring miimon settings, the updelay/downdelay fields with
value zero may not be stored in the setting.
For example:
- have a profile with "mode=balance-rr,arp_interval=11,arp_ip_target=10.10.10.1,miimon=10"
Switch the link monitoring mode to "MII" and press <OK>. Previously,
the change of the link monitoring did not update the settings, and
nothing was changed.
- when loading settings, initialize all fields with the values from the
settings, regardless whether they are currently visible or not.
Otherwise, if you edit a profile with
"mode=balance-rr,arp_interval=11,arp_ip_target=10.10.10.1,miimon=10"
and switch link monitoring mode to "MII", the miimon setting was not
initialized to 10.
- accept empty bond settings, for example for updelay. In that case,
initialize the text input to "0". Likewise, when the text entry is
empty, set the bond option to the respective default.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/488
(cherry picked from commit 61d4bc62e0)
Before 1.24, nm_setting_bond_add_option() would clear
miimon/arp_interval settings when the respective other was set.
That was no longer done, with the effect that enabling (for example)
miimon on a bond profile that has arp_interval enabled, sets both
conflicting options.
That is not a severe problem, because the profile still validates.
However, at runtime only one of the settings can be actually configured.
Fix that, by restoring the previous behavior for the client. But note
that this time it's implemented in the client, and not in libnm's
nm_setting_bond_add_option().
(cherry picked from commit b55578bf6e)
$ nmcli -f GENERAL.HWADDR device show ovsport0
GENERAL.HWADDR: (unknown)
but:
$ nmcli -f GENERAL.HWADDR --terse device show ovsport0
GENERAL.HWADDR:
This is an API change of nmcli.
(cherry picked from commit 2a1e621704)
This add a provider implementation for GCP that when detected fetches
the ip addresses of configured internal load balancers.
Once this information is fetched from the metadata server it instructs
NetworkManager to add local routes for each found forwarded-ip.
https://bugzilla.redhat.com/show_bug.cgi?id=1821787
(cherry picked from commit a2b699f40f)
libcurl's documentation for CURLMOPT_TIMERFUNCTION requires the
application to install a non-repeating timer.
https://curl.haxx.se/libcurl/c/CURLMOPT_TIMERFUNCTION.html
So let's remove the GSource once expired.
Fixes: 69f048bf0c ('cloud-setup: add tool for automatic IP configuration in cloud')
(cherry picked from commit e09bd2339a)
Since just a single pointer is used to store the socket's GSource
if more than 1 consecutive request was done through the same
HTTP provider the 2nd request would clear the GSource associated to
the second request causing the 1st HTTP request to never complete
and end up in a expired timeout.
Use a hashtable instead so we can correctly track all requests.
https://bugzilla.redhat.com/show_bug.cgi?id=1821787
Fixes: 69f048bf0c ('cloud-setup: add tool for automatic IP configuration in cloud')
(cherry picked from commit 427fbc85f0)
For simple matches like match.interface-name, match.driver, and
match.path, arguably what we had was fine. There each element
(like "eth*") is a wildcard for a single name (like "eth1").
However, for match.kernel-command-line, the elements match individual
command line options, so we should have more flexibility of whether
a parameter is optional or mandatory. Extend the syntax for that.
- the elements can now be prefixed by either '|' or '&'. This makes
optional or mandatory elements, respectively. The entire match
evaluates to true if all mandatory elements match (if any) and
at least one of the optional elements (if any).
As before, if neither '|' nor '&' is specified, then the element
is optional (that means, "foo" is the same as "|foo").
- the exclamation mark is still used to invert the match. If used
alone (like "!foo") it is a shortcut for defining a mandatory match
("&!foo").
- the backslash can now be used to escape the special characters
above. Basically, the special characters ('|', '&', '!') are
stripped from the start of the element. If what is left afterwards
is a backslash, it also gets stripped and the remainder is the
pattern. For example, "\\&foo" has the pattern "&foo" where
'&' is no longer treated specially. This special handling of
the backslash is only done at the beginning of the element (after
the optional special characters). The remaining string is part
of the pattern, where backslashes might have their own meaning.
This change is mostly backward compatible, except for existing matches
that started with one of the special characters '|', '&', '!', and '\\'.
(cherry picked from commit 824ad6275d)
The connection is automatically unreferenced when the function
returns.
Fixes: 9c5ea0917d ('devices: reuse the hotspot connection if we find appropriate one'):
(cherry picked from commit 3ecfd13ded)
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.
This does not match kernel behavior. You seem to be able to configure
multicast_snooping=auto,enabled with multicast_snooping off just fine.
Possibly this constrained was inspired by `ip link`, which says:
mcast_router MULTICAST_ROUTER - set bridge's multicast router if IGMP
snooping is enabled.
But kernel doesn't enforce this:
ip link delete br0 2>/dev/null; \
ip link add br0 type bridge mcast_router 1 mcast_snooping 0; \
grep ^ /sys/devices/virtual/net/br0/bridge/{multicast_router,multicast_snooping}
gives:
/sys/devices/virtual/net/br0/bridge/multicast_router:1
/sys/devices/virtual/net/br0/bridge/multicast_snooping:0
We probably should not implement additional constrains on top of what
kernel does, if the conditions are that obscure.
Fixes: e01d3b4c2b ('nm-setting-bridge: add 'multicast-router' bridge option')
We have the correct meta-data of supported properties for nmcli. It is
in clients/common. Use that for generating the manual page instead of
the properties that are part of libnm (some properties may be in libnm
but not supported by nmcli, or some properties may not be GObject
properties, and not detected as by GObject introspection).
"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.
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 'peer' property of ovs-patch is inserted into the 'options' column
of the ovsdb 'Interface' table. The ovs-vswitchd.conf.db man page says
about it:
options : peer: optional string
The name of the Interface for the other side of the patch. The
named Interface’s own peer option must specify this Interface’s
name. That is, the two patch interfaces must have reversed name
and peer values.
Therefore, it is wrong to validate the peer property as an IP address
and document it as such.
Fixes: d4a7fe4679 ('libnm-core: add ovs-patch setting')
Commit 37e7fa38c2 ("nm-supplicant-interface: enable OWE security
when transition mode is available") adds the OWE security flag in
case a valid OWE transtition mode IE is present on the beacon.
It also removes the OWE security flag in case the Iinformation elements
of a beacon are updated and a OWE transition mode IE can't be found.
When a pure OWE AP updates it's Information Elements (e.g. BSS Load
Element), the OWE security flag is falsely removed.
Introduce a new NM_802_11_AP_SEC_KEY_MGMT_OWE_TM security flag and use
it exclusively for OWE transition mode. Don't use the
M_802_11_AP_SEC_KEY_MGMT_OWE security flag on transition-mode APs.
Signed-off-by: David Bauer <mail@david-bauer.net>
