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.
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
