g_key_file_get_value() returns the raw value as stored in the file.
When accessing a string value, in most cases it is correct to use
g_key_file_get_string() instead.
When working with internals, such as comparing two keyfiles for
equality, g_key_file_get_value() is correct.
When parsing booleans, we parse it based on the raw value.
Fix the usages. This is a change in behavior if the config file
contained unusual strings.
Some plugins had their local defines for the name of the sections and
keys in NMConfig. Move those defines to "nm-config.h".
Usually plugins make use of code in core, but not the other
way round. Defining the names inside "nm-config.h" is no violation of
that because the config section names are anyway not local to the
plugin, but global in the shared name-space with other settings.
For example, another plugins shouldn't reuse the section "ifnet".
For that reason, it is correct and consistent to move these defines
to "nm-config.h".
We don't use those names in core, we merely signal their existance.
Add function to parse as boolean according our NMConfig convention.
Split this out from nm_config_keyfile_get_boolean() so that we can use
it independently. Also, change the return type to gint, so that one might
pass -1 to indicate an invalid/missing boolean value.
Thereby also don't log a warning in nm_config_keyfile_get_boolean()
We don't want to log a warning every time we access a keyfile value.
If we want to warn about invalid values, we should do it once after
the configuration is loaded. And then we should not only do it
for booleans, but for other types as well.
GKeyFile considers the order of the files, so add a possibility
to check whether to keyfiles are equal -- also with respect to
the order of the elements.
The content of the no-auto-default state file is part of NMConfig.
During a reload, also reload that.
This way, a user could edit the no-auto-default file and it would
be properly reloaded.
We used to merge the spec list for no-auto-default from keyfile with the
content of the state file. Since the addition of the "except:" spec this
is wrong.
For example, if the user configured:
no-auto-default=except:mac:11:11:11:11:11
and statefile contained "11:11:11:11:11" and "22:22:22:22:22", we would
wrongly not match "11:11:11:11:11". The two lists must be kept separate,
so that devices that are blocked by internal decision always match.
This separation is also clearer. Now the spec list is devided into a
part that comes from user configuration, and a part that comes from
internal decision.
We have a hack to extend GKeyFile to support specifying an 'option+'
key. Also add support for 'option-'.
Options that make use of these modifiers can only be string lists.
So do the concatenation not based on plain strings, but by treating
the values as string lists. Also, don't add duplicates.
We support the "NetworkManager.conf" sections '[connection]' and
'[connection.\+]' (with arbitrary suffix).
Fix the order of how we evaluate these section.
Note that the literal '[connection]' section is always evaluated lastly
after any other '[connection.\+]' section.
Within one file, we want to evaluate the sections in top-to-bottom
order. But accross multiple files, we want to order them
later-files-first. That gives a reasonable behavior if the user
looks at one file, and also if he wants to overwrite configuration
via configuration snippets like "conf.d/99-last.conf".
Note that if a later file extends/overwrites a section defined in an
earlier file, the section is still considered with lower priority
This is intentional, because the user ~extends~ a lower priority
section. If he wants to add a higher priority section, he should
choose a new suffix.
Fixes: dc0193ac02
We ought to set an error if we're returning NULL from
connection_from_file_full(). Also, printing out a warning ourselves makes no
sense -- the caller communicates this if we signal an error by returning NULL.
Use the editor to obtain a list of possible properties for a type of
connection. Let 'nmcli c modify' completion reuse it as well, to avoid code
duplication.
The initsystem should stop nm-dispatcher before stopping D-Bus
service. However, on some systems that is not implemented, so
nm-dispatcher should not exit with a failure message when the
system bus disappears.
Instead just assume that D-Bus service was stopped during shutdown
and exit gracefully.
Based-on-patch-by: Jacob <jacobgodserv@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=751017
When adding an IPv4 address, kernel will also add a device-route.
We don't want that route because it has the wrong metric. Instead,
we add our own route (with a different metric) and remove the
kernel-added one.
This could be avoided if kernel would support an IPv4 address flag
IFA_F_NOPREFIXROUTE like it does for IPv6 (see related bug rh#1221311).
One important thing is, that we want don't want to manage the
device-route on assumed devices. Note that this is correct behavior
if "assumed" means "do-not-touch".
If "assumed" means "seamlessly-takeover", then this is wrong.
Imagine we get a new DHCP address. In this case, we would not manage
the device-route on the assumed device. This cannot be fixed without
splitting unmanaged/assumed with related bug bgo 746440.
This is no regression as we would also not manage device-routes
for assumed devices previously.
We also don't want to remove the device-route if the user added
it externally. Note that here we behave wrongly too, because we
don't record externally added kernel routes in update_ip_config().
This still needs fixing.
Let IPv4 device-routes also be managed by NMRouteManager. NMRouteManager
has a list of all routes and can properly add, remove, and restore
the device route as needed.
One problem is, that the device-route does not get added immediately
with the address. It only appears some time later. This is solved
by NMRouteManager watching platform and if a matchin device-route shows up
within a short time after configuring addresses, remove it.
If the route appears after the short timeout, assume they were added for
other reasons (e.g. by the user) and don't remove them.
https://bugzilla.gnome.org/show_bug.cgi?id=751264https://bugzilla.redhat.com/show_bug.cgi?id=1211287
When checking whether an address from platform should be deleted, we
compare the address with our list of @known_addresses.
For that we must also check for expired lifetimes, because
@known_addresses might contain expired addresses.
