The compatibily wrapper for rtnl_addr_flags2str() did not
behave identical because libnl adds a trailing ',' if it
encounters unknown attributes.
Also add test cases.
We don't really know which version it's going to be -- and thus if we're going
to actually need it (version 5), or not (version 4). It's going to be decided
at configure time.
Also, drop the bogus Fedora 19 conditionals; Fedora < 20 has ModemManager that's
too old for the WWAN code anyway.
make[4]: Entering directory './NetworkManager/src'
CC libsystemd_nm_la-util.lo
systemd/src/basic/util.c: In function 'cunescape_length_with_prefix':
systemd/src/basic/util.c:1271:30: error: 'u' may be used uninitialized in this function [-Werror=maybe-uninitialized]
t += utf8_encode_unichar(t, u);
^
systemd/src/basic/util.c:1230:26: note: 'u' was declared here
uint32_t u;
^
NetworkManager uses wpa_supplicant, which in turn calls OpenSSL for verifying
certificates. wpa_supplicant calls
SSL_CTX_load_verify_locations(ctx, CAfile, CApath)
using its ca_cert and ca_path options as CAfile and CApath parameters.
We have a configure time option with_system_ca_path to override ca_path.
However, it doesn't work when a system (like Fedora) only uses bundled PEM
certificates instead of a directory with hashed certificates ([1], [2]).
So this commit allows setting --with_system_ca_path to a file name (the
trusted certificate bundle). Then the name is used to populate wpa_supplicant's
ca_cert instead of ca_path.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1053882
[2] https://www.happyassassin.net/2015/01/12/a-note-about-ssltls-trusted-certificate-stores-and-platforms/https://bugzilla.redhat.com/show_bug.cgi?id=1236548
priv->iface could change in device_link_changed() which reacts on platform link
changes caused by nm_platform_link_set_user_ipv6ll_enabled(). (The variable could
change between obtaining and using its value, because emitting a glib signal runs
callbacks synchronously).
Actually, the problem is already fixed by commit 04caae735f.
But still this is better.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1224366
Kernel does not allow to add the same route (as determined by network/plen,metric)
on two different interfaces (ifindex). In case of conflict, NMRouteManager used to
ignore any but the firstly added route.
On the other hand, we cannot add a gateway-route, if there is no direct
route to the gateway. Hence, skipping duplicate routes can mean that we
skip a direct route what was necessary to add another gateway-route,
which then leads to a failure to add that route.
This also applies to IPv4 device routes that since recently are managed
by NMRouteManager.
For example, say you connect two interfaces to the same IP subnet.
The route-metric can conflict if the interfaces are of the same type
or if the user explicitly configured a conflict.
In case of conflicts, NMRouteManager would only configure the first
appearing route and skip the shadowed route on the second interface.
Now we cannot configure gateway-routes on the second interface because
the gateway is unreachable.
There are many scenarios where this issue can happen, especially with
default-routes and user-configured-routes.
For example with default-routes, ip4_config_merge_and_apply() would check
if the default-gateway requires an explict route and possibly add it.
But then NMRouteManager might not add the route because it is shadowed
by a route on an other interface.
This patch solves the issue by having NMRouteManager configure shadowed
routes too, similar to what NMDefaultRouteManager does.
It does that by searching for an unused, non-conflicting, higher metric
for the route, i.e. bump the metric by 1 until we can add it without
conflict.
Also note that NMRouteManager still ensures that for conflicting routes
the best route sticks to the interface that configured it first. That
means if you later add the conflicting route on another interface, it
will be added with higher metric and the data is still routed along the
first interface.
We already support setting configuration values, either:
(1) set any internal section, i.e. groups starting with [.intern*].
Those values don't ever interfere with that the user can
configure.
(2) set individual properties that overwrite user configuration.
When doing that, we record the value from user configuration
and on load, we reject our internal overwrite if the user
configuration changed in the meantime.
This is done by storing the values with ".set." and ".was." prefixes.
Now add support for "atomic sections". In this case, certain groups
can be marked as "atomic". When writing to such sections, we overwrite
the entire user-provided setting.
We also record the values from user configuration, and reject our
internal value if we notice modifications. This basically extends
(2) from individual properties to the entire section.
Internal configuration is written as keyfile to
NMSTATEDIR"/NetworkManager-intern.conf"
Basically, the content of this file is merged with user
configuration from "NetworkManager.conf" files. After loading
the configuration, NMConfig exposes a merged view of user-provided
settings and internal overwrites.
All sections/groups named [.intern*] are reserved for internal
configuration values. They can be written by API, but are ignored
when the user sets them via "NetworkManager.conf". For these
internal sections, no conflicts can arise.
We can also overwrite individual properties from user configuration.
In this case, we store the value we want to set, but also remember
the value that the user configuration had, at the time of setting.
If on a later reload the user configuration changed, we ignore our
internal value -- as we assume that the user modified the value
afterwards.
We can also hide/delete value from user configuration.
This works on a per-setting basis.
Originally, ibft settings were handled by "ifcfg-rh" plugin. Later, we added
a separate "ibft" plugin and moved the functionality there.
The problem was that users quite possibly had a configuration like
[main]
plugins=ifcfg-rh
in their "NetworkManager.conf". That meant, after upgrade users would
no longer have ibft support.
We fixed that by installing "/etc/NetworkManager/conf.d/10-ibft-plugin.conf"
which was read after the main file and contained:
[main]
plugins+=ibft
We no longer want to install configuration snippets with our core packages to
/etc. Avoid the regression by changing the meaning of "ifcfg-rh". By enabling
"ifcfg-rh" you now implicitly enable "ibft" plugin as well. This can be
turned off via "no-ibft". And you can continue to enable "ibft" plugin
alone.
'main.plugins' is the only configuration options for which we
have a default value and which we always want to set.
This property has a compile time default and can be set via command line,
fix the logic to set the value.
The proper way is:
- first set it (always) to the compile time default
- then read the configuration files, which potentially modify
the value.
- finally, if set via command line, overwrite it because
command line always wins.
Also comment-out the setting from our default file in
"contrib/fedora/rpm/NetworkManager.conf". We don't really need it to be
configured there, as we have a compile time default. Commenting it out
makes this clearer to the user.
Note that we cannot drop "10-ibft-plugin.conf" snippet from
NetworkManager package, because many users might have an old
"NetworkManager.conf" file with "plugin=ifcfg-rh".
This is a change in behavior if the user has no explicit
"plugins=ifcfg-rh" setting but followed by "plugins+=ibft".
Don't move "10-ibft-plugin.conf", because we need it to be
read *after* "NetworkManager.conf". Many users might have
an old "NetworkManager.conf" file that contains "plugin=ifcfg-rh".
This allows packages to install their configuration snippets to
"/usr/", which is a better place for system-provided configuration
files then "/etc".
"/usr/lib/NetworkManager/conf.d/" is read first, so that the values
in /etc have higher priority.
In general, we want to move system-provided configuration away from
/etc, so that a user can do a "factory-reset" by purging /etc.
https://bugzilla.gnome.org/show_bug.cgi?id=738853
Early part of fixes and improvements to NMConfig.
This is mostly refactoring and adding of new utility functions.
But it also fixes the way how to parse configuration options from
"NetworkManager.conf" keyfile. So this brings behavioral changes
in the way how we parse the configuration. But unless the user had
unusual configurations (whitespaces, backslash escapes), there should
be no visible changes.
https://bugzilla.gnome.org/show_bug.cgi?id=738853
It is wrong to blindly merge keys that have an 'option+' or 'option-'.
Merging options is only possibly when we understand what the option
means and how to merge it.
No longer handle every setting but only those that are explicitly known
to be string-lists (or device-specs).
We have a special implemenation nm_match_spec_split() to split
a string. We also need the reverse operation to be able to convert
a list of specs to string without loss.
In some cases we want the returned value to be stripped. In some cases,
we want to read the raw value instead of the string parsed by GKeyFile.
Add an flags argument to nm_config_data_get_value(). It is up to the caller
to determine the exact meaning (and whether to strip).
By adding the flags argument, the caller can get the desired behavior easier
without having to workaround it afterwards. But more importantly, it becomes
apparent that there are different ways to retrieve the value and the caller
should decide on the details.
