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.
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.
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.
AUTOCONNECT_SLAVES is an NetworkManager extension. initscripts always activate
slaves with the master connection for bond and team, and doesn't activate
automatically slaves for bridge.
NetworkManager behaviour is controlled by this variable. If the variable is
missing the default value from configuration file is used.
The 'example' settings plugin is (obviously) unused, but it is also
badly maintained and no longer best-practice in several ways:
- it directly reads "NetworkManager.conf" instead of using NMConfig.
- it parses device specs itself, instead of using
nm_match_spec_split().
- read_connections() doesn't ensure that loading a file
does not replace a previously loaded one (due to conflicting
UUID). In general the example doesn't show/handle the complexity
of potential UUID conflicts.
Instead of fixing these issues it is better to ensure our main plugin
('keyfile') corresponds to current best practices. Should we ever add a
new pluginww, 'keyfile' should be the example.
Instead of parsing "/etc/NM/NetworkManager.conf" in keyfile plugin itself,
use NMConfig. Parsing it outside of NMConfig API has the significant disadvantage
of not considering files under "conf.d/".
This also has a behavioral change: keyfile no longer monitors
"NetworkManager.conf" file for changes, but instead only reacts
on explict "config-changed" signals from NMConfig.
This previous behavior of picking up file changes without
user-interaction is anyway not what we want. NM should not react
on mere file changes, but only on explicit reload commands. And
even if we want to support it, file watching should be implemented
properly inside NMConfig, watching *all* relevant files.
This was the last out-of-api access to the configuration after
refactoring NMConfig. Now that keyfile plugin no longer writes
the hostname, we can get rid of this.
After the hostname functionality has been moved from plugins to core,
the ifcfg-suse plugin contains only boilerplate code with no actual
functionality.
Remove the plugin, mark it as deprecated in manual page and print a
warning when it is selected in configuration file.
Previously, it would silently accept a value set to "empty".
This is however not a valid number and we should raise a
warning just like for any other invalid number.
Alias files have a ':' to separate the base name from their
alias. But we didn't always ensure not to write-out files without
colon, and also initscripts doesn't have that restriction.
We should detect alias files and handle them properly (e.g. by
reloading the base file).
This fixes an error that a `nmcli con load` would have tried to
load the alias file. Also extend load_connection() to support
passing filenames other then the base file.
We only have to handle this in plugin.c. Inside reader.c we always
have the normalized base filename.
Or detection of alias files only looks whether the filename has a ':'
and whether a corresponding base file exists.
Previously, if the main ifcfg file doesn't define any
static ip addresses, any alias files would be ignored.
We should also allow alias files with (pure) 'dhcp' connections,
just like initscripts do.
Reported-by: Marek Hulan <mhulan@redhat.com>
connection_from_file() used to log a warning about failure,
but only when an @error argument was given.
update_connection() didn't ensure that in several cases,
so we would not log any failure reason when an ifcfg file
failed to read.
This behavior of controlling logging by passing @error (or not)
is unexpected. Instead, refactor the code so that the caller
can do appropriate logging.
Another reason for this refactoring is that PARSE_WARNING() does
not mention the file for which the failure is and uses some extra
indention that looks wrong. IOW, connection_from_file() doesn't
have the context to give the logging line a proper formatting.
We already have "nm-utils*.h" and "NetworkManagerUtils.h" headers. Rename
"include/nm-utils-internal.h" to "nm-macros-internal.h". I think that
name is better, because this file is header-only, internal, and
repository-wide.
Also, it will never contain non-header-only declarations because
there is no backing object file under "include/".
It will only contain macros and inline functions.
With GCC 5, -Wlogical-not-parentheses is enabled by -Wall and warns
about suspicious code like:
int a;
...
if (!a > 1) { ... }
Fix the following warning:
test_all.c: In function ‘test_is_static’:
test_all.c:114:32: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
ASSERT (!is_static_ip6 ("eth0") == TRUE, "is static",
^
"nm-utils-private.h" should not be used outside of libnm-core/.
core/ should only use public API or "nm-core-internal.h".
Also, "nm-setting-ip-config.h" is a public header and should
not contain internal defines. Move them to "nm-core-internal.h"
too.
Fixes: 019943bb5d
Most nm_platform_*() functions operate on the platform
singleton nm_platform_get(). That made sense because the
NMPlatform instance was mainly to hook fake platform for
testing.
While the implicit argument saved some typing, I think explicit is
better. Especially, because NMPlatform could become a more usable
object then just a hook for testing.
With this change, NMPlatform instances can be used individually, not
only as a singleton instance.
Before this change, the constructor of NMLinuxPlatform could not
call any nm_platform_*() functions because the singleton was not
yet initialized. We could only instantiate an incomplete instance,
register it via nm_platform_setup(), and then complete initialization
via singleton->setup().
With this change, we can create and fully initialize NMPlatform instances
before/without setting them up them as singleton.
Also, currently there is no clear distinction between functions
that operate on the NMPlatform instance, and functions that can
be used stand-alone (e.g. nm_platform_ip4_address_to_string()).
The latter can not be mocked for testing. With this change, the
distinction becomes obvious. That is also useful because it becomes
clearer which functions make use of the platform cache and which not.
Inside nm-linux-platform.c, continue the pattern that the
self instance is named @platform. That makes sense because
its type is NMPlatform, and not NMLinuxPlatform what we
would expect from a paramter named @self.
This is a major diff that causes some pain when rebasing. Try
to rebase to the parent commit of this commit as a first step.
Then rebase on top of this commit using merge-strategy "ours".
