| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=750659
|
| |
|
|
|
| |
Via escape sequences, the user still can specify trailing and leading
white spaces: such as "\s \s" will result in 3 spaces.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
We don't want to log a warning every time we access a keyfile value.
If we would like 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.
For now, just drop this.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
This removes duplicate parsing, but also makes all places use the
same str-to-boolean convention.
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
We don't use this argument, for every practical purpose, an failure
to retrieve a key means that there is no such key.
|
| |
|
|
|
|
| |
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 from user configuration, and a part that comes from
internal decision.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'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".
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
| |
"/usr/lib/NetworkManager/conf.d"
Don't move 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
|
| | |
|
| |
|
|
| |
Make them match to the variable names that we assign them to.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- move all hostname-related functions from plugins to the core
- allow to specify the method used to load and store the hostname at
build time
- add hostnamed support
- remove unused setting plugins
https://bugzilla.gnome.org/show_bug.cgi?id=740409
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| | |
When the systemd-hostnamed daemon is available, use it to read and
change the hostname.
Based on 'danw/wip/hostnamed' branch by Dan Winship <danw@redhat.com>
|
| | | |
|
| | |
| |
| |
| |
| | |
Remove all hostname-related code from plugins since this functionality
has been moved to the core.
|
