Currently, both man pages and gtk-doc HTML documentation are enabled by
the same build option. It is common for users to want to choose whether
to build HTML docs, as not everyone cares about HTML developer docs, but
manpages are intended directly for end-user consumption and should
always be available. At the very least, there should be a separate
option to disable them to avoid accidentally disabling them while trying
to disable HTML developer docs.
Resolves: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1653
When building from a release tarball of NetworkManager,
`meson.add_dist_script()` has copied various prebuilt manpages into the
tarball and building them again is not really necessary. We can just
install those directly.
This means that *all* manpages could be installed even without
introspection, even though some of them can only be *built* when
introspection is enabled.
It also means that manpages can be installed even when xsltproc is not
available at build time.
It's intrinsically used when building manpages, and also part of the
introspection-specific parts of the documentation build. There's no
particular guarantee either of those will actually be invoked during a
build, so don't unconditionally look it up.
This allows building with one fewer dependency in many cases.
The NVMe Boot Firmware Table (NBFT) is a mechanism of passing context
from a pre-OS Boot environment to an OS runtime, as defined by the
NVM Express Boot Specification. Exposed as an ACPI table it contains
network interface definitions along with NVMe subsystem and namespace
data structures.
This adds new nm-initrd-generator parser that uses libnvme NBFT parser
implementation.
Signed-off-by: Tomas Bzatek <tbzatek@redhat.com>
Previously, IPv4 shared method will automatically enable the IPv4
global forwarding, all the per-interface level IPv4 forwarding settings
may be changed to match the global setting. Also, all the per-inteface
level forwarding settings can not be restored when deactivating the
shared connection. This is problematic as it may disrupt custom
configurations and lead to inconsistent forwarding behavior across
different network interfaces.
To address this, the implementation now ensures that the original
per-interface forwarding settings are preserved. Upon activating a
shared connection, instead of enabling IPv4 global forwarding
automatically, the per-interface forwarding is enabled on all other
connections unless a connection explicitly has the forwarding set to
"no" in its configuration. Upon deactivating all shared connection,
per-interface forwarding settings are restored to sysctl's default
value. Furthermore, deactivating any connection explicitly sets the
forwarding to sysctl's default value ensuring that network forwarding
behavior remains consistent.
Add support for configuring per-interface IPv4 sysctl forwarding setting
in NetworkManager. The feature allows users to configure the
net.ipv4.conf.<interface>.forward setting directly through
NetworkManager, enabling targeted forwarding configurations for
interfaces. This is particularly useful for cases such as enabling
forwarding for MetalLB load balancing without requiring a global
ip_forward=1 setting.
While forwarding setting can be managed via /etc/sysctl.conf,
configuring sysctl options for dynamically created or
software-configured interfaces (e.g., bridges) poses challenges. With
this feature, NetworkManager can configure these settings when
interfaces are created or updated, users no longer need to rely on
nm-dispatcher scripts for per-interface sysctl configuration, which can
be error-prone and complex. This feature ensures a more seamless and
integrated way to manage per-interface forwarding configurations,
reducing user overhead and improving usability in complex network
setups.
We do not support configuring per-device IPv6 sysctl forwarding because
in order to make per-device IPv6 sysctl forwarding work, we also need to
enable the IPv6 global sysctl forwarding setting, but this has potential
security concerns because it changes the behavior of the system to
function as a router, which expose the system to new risks and
unintended traffic flows, especially when enabling forwarding on the
interface the user previously explicitly disabled. Also enabling
per-device IPv6 sysctl setting will change the behavior of router
advertisement (accept_ra), which is not expected. Therefore, we
only support configuring per-device IPv4 sysctl forwarding option in
NetworkManager.
Resolves: https://issues.redhat.com/browse/RHEL-60237https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2071https://gitlab.freedesktop.org/NetworkManager/NetworkManager-ci/-/merge_requests/1833
Prevents NetworkManager from trying to determine the
transient hostname via DHCP or other means if "localhost"
is already configured as a static hostname, as the transient
hostname will be ignored by hostnamed if a static hostname
has already been set.
Add support for two new command line arguments:
- `rd.net.dns-backend` used to control the "dns" option in
NetworkManager configuration;
- `rd.net.dns-resolve-mode` used to control the "resolve-mode" in the
global DNS configuration.
The use case for them is the installation of a new system where the
administrator wants to configure aspects of the DNS resolution
starting from the early boot, for example to enable DNS over TLS and
avoid that any query goes out unencrypted.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2123
Resolve-mode allows user to specify way how the global-dns domains
and DNS connection information should be merged and used.
Certification-authority allows user to specify certification
authority that should be used to verify certificates of encrypted
DNS servers.
The list describing the order of DHCP clients is confusing because it
doesn't take into account what clients are disabled at build
time. Instead, just show the available clients in the preferred order.
Describe in the NetworkManager.conf man page what DHCP clients the
user can set in this build, instead of showing a generic list and
letting the user try each one.
Introduce a new kernel command line option named "rd.net.dns" that can
be used to specify a global name server. It accepts name server in a
URI-like form, as for example:
rd.net.dns=dns+tls://[fd01::1]:5353#mydomain.com
Accept name servers specified with an URI syntax in the global
configuration. A plugin that doesn't support a specific scheme can
decide to ignore it and use only the servers it understands. At the
moment there is no plugin that supports DNS-over-TLS servers in the
global configuration.
We have encountered multiple incidents where users face connectivity
issues after booting, particularly due to hardware like switches that do
not pass traffic for a few seconds after startup. And services such as
NFS fail to mount because they try to initiate before the network is
fully reachable. Therefore, we are supporting
`connection.ip-ping-addresses` and `connection.ip-ping-timeout` to
allow administrators to configure the network to verify connectivity to
a specific target(such as a service like NFS) instead of relying on
gateway reachability, which may not always be relevant in certain
network configurations.
Resolves: https://issues.redhat.com/browse/RHEL-21160https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2034https://gitlab.freedesktop.org/NetworkManager/NetworkManager-ci/-/merge_requests/1797
In nmcli we have renamed dhcp-send-hostname and dhcp-send-hostname-v2 to
dhcp-send-hostname-deprecated and dhcp-send-hostname so users don't need
to worry about the details of the weird workarounds that we sometimes
need to do to expand and/or deprecate some properties.
However, the autogenerated documentation didn't include this names. Add
---nmcli--- specific documentation, adding a new property-infos field
called "rename" with the new name used in nmcli. This field can be used
for more properties if we use the same strategy in the future.
The user does not want to send machine hostname to the DHCP server
globally by default to avoid ddns record getting created in IPAM.
otherwise, IPAM creates ddns records which might interfere with user's
regular host record. Thus, introduce the ternary property
dhcp_send_hostname_v2 to warrant this behavior.
Notice that we set the GSpec of dhcp-send-hostname-v2 to int, because
defining it as enum would make that it cannot be expanded in a backwards
compatible way if we need to add more values: old clients using libnm
would reject it due to the new value being unknown. Follow the same
strategy than _nm_setting_property_define_direct_enum, defining the
NMSettInfoPropertType as enum, but the glib's GSpec as int.
Resolves: https://issues.redhat.com/browse/RHEL-56565https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2029https://gitlab.freedesktop.org/NetworkManager/NetworkManager-ci/-/merge_requests/1765
Initial support for OCI. It doesn't support VLAN configuration yet as
the requirements are not clear. It doesn't support secondary IP
addresses because the IMDS server doesn't expose them.
Instead of using plain text format, it gets a single response in JSON
format and parses it. The dependency to jansson is now mandatory for
that.
When the "ipvX.routed-dns" property is set to true, add a route for
each DNS server via the current interface. The feature works in the
following way.
A new routing rule is created ("priority $PRIO not fwmark $MARK lookup
$TABLE") where $PRIO, $MARK and $TABLE are fixed values and are the
same for all interfaces. This rule is evaluated before standard rules
and tries to look up routes in table $TABLE, where NM adds the routes
to DNS servers.
To determine the next-hop to the name server, NM issues a RTM_GETROUTE
netlink request to kernel, specifying to return the route via the
current interface. In order to avoid results from $TABLE, NM also sets
the fwmark as $MARK in the request.
As part of the conscious language effort we must provide an alternative
option to configure autoconnect-ports system-wide on NetworkManager
configuration file.
Adds an option in the connectivity section to change the timeout before
the interface is deemed "limited". Previously, it was hardcoded to
20 seconds, but for our usecase (failing over to cell modem if
hardwired ethernet drops), it's nice to be able to failover to another
interface more quickly.
Commit 797f3cafee ('device: fall back to saved use_tempaddr value
instead of rereading /proc') changed the behaviour of how to get the
last resort default value for ip6-privacy property.
Previously we read it from /proc/sys/net/ipv6/conf/default, buf after
this commit we started to read /proc/sys/net/ipv6/conf/<iface> instead,
because the user might have set a different value specific for that device.
As NetworkManager changes that value on connection activation, we used
the value read at the time that NetworkManager was started.
Commit 6cb14ae6a6 ('device: introduce ipv6.temp-valid-lifetime and
ipv6.temp-preferred-lifetime properties') introduced 2 new IPv6 privacy
related properties relying on the same mechanism.
However, this new behaviour is problematic because it's not predictable
nor reliable:
- NetworkManager is normally started at boot time. That means that, if a
user wants to set a new value to /proc/sys/net/ipv6/conf/<iface>,
NetworkManager is likely alread running, so the change won't take
effect.
- If NetworkManager is restarted it will read the value again, but this
value can be the one set by NetworkManager itself in the last
activation. This means that different values can be used as default in
the same system boot depending on the restarts of NetworkManager.
Moreover, this weird situation might happen:
- Connection A with ip6-privacy=2 is activated
- NetworkManager is stopped. The value in
/proc/sys/net/ipv6/conf/<iface>/use_tempaddr remains as 2.
- NetworkManager starts. It reads from /proc/sys/... and saves the value
'2' as the default.
- Connection B with no ip6-privacy setting is activated. The '2' saved
as default value is used. The connection didn't specify any value for
it, and the value '2' was set by another connection for that specific
connection only, not manually by a user that wanted '2' to be the
default.
A user shouldn't have to think on when NetworkManager starts or restarts
to known in an easy and predictable way what the default value for
certain property is. It's totally counterintuitive.
Revert back to the old behaviour of reading from
/proc/sys/net/ipv6/conf/default. Although this value is used by the
kernel only for newly created interfaces, and not for already existing
ones, it is reasonable to think on these settings as "systemwide
defaults" that the user has chosen.
Note that setting a different default in NetworkManager.conf still takes
precedence.
Replaced by full_path:
https://mesonbuild.com/Reference-manual_returned_external_program.html#external_programpath
ExternalProgram.full_path was added in meson 0.55 but we support meson
>= 0.51. Because of that, use path or full_path conditionally depending
on the meson version.
This gets rid of the following deprecation warning:
NOTICE: Future-deprecated features used:
* 0.48.0: {'module python3'}
* 0.55.0: {'ExternalProgram.path'}
Instead, meson.current_source_root or meson.project_source_root should
be used:
https://mesonbuild.com/Reference-manual_builtin_meson.html#mesonsource_root
Also, the documentation referenced above suggest to use `files()` as a
better alternative to refer to files, so do that at the same time.
This gets rid of the deprecation warning:
NOTICE: Future-deprecated features used:
* 0.56.0: {'meson.source_root'}
When IPv6 privacy extensions are enabled, by default temporary addresses
have a valid lifetime of 1 week and a preferred lifetime of 1 day.
That's far too long for privacy-conscious users, some of whom want a new
address once every few seconds. Add connection options that correspond
to /proc/sys/net/ipv6/conf/*/temp_valid_lft and
/proc/sys/net/ipv6/conf/*/temp_prefered_lft to allow configuring the
address rotation time on a per-connection basis.
The new properties are defined as 32-bit signed integers to match the
sysctl parameters which are also signed, although currently only
positive numbers are valid.
Introduce a new option to NMSettingIpConfig. The new option is ternary
type being the default value set to disabled. When enabled,
NetworkManager will instruct the DHCP client to send RELEASE message
when IP addresses are being removed.
The new option at NMSettingConnection allow the user to specify if the
connection needs to be down when powering off the system. This is useful
for IP address removal prior powering off. In order to accomplish that,
we listen on "Shutdown" systemd DBus signal.
The option is set to FALSE by default, it can be specified globally on
configuration file or per profile.
Device handlers need a way to pass data back to NetworkManager, such
as the ifindex and an error message. Allow them to return a dictionary
on standard output, where each line contains a "$key=$value" pair.
In the daemon, the dictionary is returned via the callback function.
Add a new "generic.device-handler" property that specifies the name of
a dispatcher script to be invoked to add and delete the interface for
this connection.
Properties in the "user" setting are a convenient way to associate any
kind of user-provided metadata to connections.
However, nmcli doesn't support the user setting at the moment and
adding this feature requires a significant effort. Without nmcli
support, dispatcher scripts can only access user properties by either
parsing connection files or by using D-Bus (with or without libnm and
GObject introspection). Since both these solutions are not very
convenient, provide an alternative way: pass the properties as
environment variables.
