summaryrefslogtreecommitdiff
path: root/src/nm-config.h
Commit message (Collapse)AuthorAgeFilesLines
* device: make carrier-wait-timeout configurable per deviceThomas Haller2017-11-281-0/+1
| | | | | | | | As this depends on the particular host configuration, it's hard to find a default that suits everybody. At least make it configurable per-device. https://bugzilla.redhat.com/show_bug.cgi?id=1483343 https://bugzilla.redhat.com/show_bug.cgi?id=1515027
* core: use #define for "autoconnect-retries-default" configThomas Haller2017-11-271-0/+1
| | | | | All our known configuration keys should have a #define, so that all keys are collected in the header file.
* device: add configuration option to mark devices as unmanagedThomas Haller2017-09-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We already have various ways to mark a device as unmanaged. 1) via udev-rule ENV{NM_UNMANAGED}. This can be overwritten via D-Bus at runtime. 2) via settings plugin. That is NM_CONTROLLED=no for ifcfg-rh and keyfile.unmanaged-devices in NetworkManager.conf. 3) at runtime, via D-Bus. This is persisted in the run state file and persists restarts (but not reboot). This adds another way via NetworkManager.conf file. Note that the existing keyfile.unmanaged-devices (above 2) is also a configuration optin in NetworkManager.conf. However it has various downsides: - it cannot be overwritten at runtime (see commit c210134bd58ea40ee3458aff27ab41958e1f48b4). - you can only explicitly mark a device as unmanaged. That means, you cannot use it to manage a device which is unmanaged due to a udev rule. - the name "keyfile.*" sounds like it's only relevant for the keyfile settings plugin. Nowadays the keyfile plugin is always loaded, so the option applies to NetworkManager in general. https://github.com/NetworkManager/NetworkManager/pull/29
* config: add an API to disable connectivity check via internal config file.James Henstridge2017-08-171-0/+2
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=785117
* config: allow persisting the device nm-owned stateBeniamino Galvani2017-06-071-1/+6
|
* core: add configuration flag to choose slaves activation orderBeniamino Galvani2017-05-241-0/+1
| | | | | | | | | Commits 39d0559d9a7a ("platform: sort links by name instead of ifindex") and 529a0a1a7f19 ("manager: sort slaves to be autoconnected by device name") changed the order of activation of slaves. Introduce a system-wide configuration property to preserve the old behavior. https://bugzilla.redhat.com/show_bug.cgi?id=1452585
* config: add first_start paramter to NMConfig to detect restartThomas Haller2017-04-201-1/+3
| | | | (cherry picked from commit 2131954a190244714e8b27b48567594c7b103fb9)
* config: remove unused NMConfig self argument from nm_config_device_state_*() APIThomas Haller2017-04-201-5/+3
| | | | | | | | | | | nm_config_device_state_*() always access the file system directly, they don't cache data in NMConfig. Hence, they don't use the @self argument. Maybe those functions don't belong to nm-config.h, anyway. For lack of a better place they are there. (cherry picked from commit 1940be410cc0272de2f690542f43ef7dcb7bc4e1)
* core: allow setting SR-IOV num_vfsBeniamino Galvani2017-04-191-0/+1
| | | | (cherry picked from commit 32975b6aa5b48118ec65a3790e763a530a4ad913)
* core: only persist explicit managed state in device's state fileThomas Haller2017-04-071-1/+1
| | | | | | | | | | | For example, when starting without Wi-Fi plugin, a generic device is created. On stop, we should not store the unmanaged state on the state file, otherwise after restart the device is unmanaged. Only store explicit user decisions. https://bugzilla.redhat.com/show_bug.cgi?id=1440171 (cherry picked from commit 142ebb10376ec592593f15b0359f38be89c97620)
* policy: add support to configurable hostname modeFrancesco Giudici2017-03-241-0/+1
|
* config: drop nm_config_get_debug() and access config directlyThomas Haller2016-11-251-1/+1
|
* config: drop nm_config_get_dhcp_client() and access config directlyThomas Haller2016-11-251-1/+1
| | | | | | | | | | | | Also, ifnet plugin would read the configuration value, which is just wrong because: - the configuration might not be set and ifnet would fail to fallback to the compile time default. - the configuration only is in effect if the plugin is also available. Otherwise, we fallback to the next plugin. Only the dhcp-manager knows which DHCP plugin is in use.
* config: drop nm_config_get_auth_polkit() and access value directlyThomas Haller2016-11-251-1/+1
|
* config/trivial: unify name of compile time config defaultsThomas Haller2016-11-251-1/+1
|
* config: optionally let nm_config_get_plugins() return compile time defaultThomas Haller2016-11-251-1/+0
| | | | | | | | | | | Instead of having the caller do the fallback to the compile time default plugins, let it be handled by nm_config_get_plugins(). The knowledge of fallback to a compile time default (and how to do that properly) should be inside NMConfig/NMConfigData alone. Also, as this function is only called once, let NMConfig not cache the string list but create it once as needed.
* core: persist the fake permanent hardware address to the device's statefileThomas Haller2016-10-281-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On devices that have no real permanent hardware address (as returned by ethtool), we take the current MAC address of the device. Currently, NM is a bit flaky about whether to accept such fake permanent addresses for settings like keyfile.unmanaged-devices or the per- connection property ethernet.mac-address. Probably, we should allow using fake addresses there in general. However, that leads to problems because NetworkManager itself changes the current MAC address of such devices. For example when configuing keyfile.unmanaged-device=22:33:44:55:66:77 and later activating a connection with ethernet.cloned-mac-address=22:33:44:55:66:77 we have a strange situation after restart and the device becomes unmanaged. We are going to avoid that, by remembering the fake permanent address in the device state file. This only matters: - for devices that don't have a real permanent address (veth) - if the user or NetworkManager itself changed the MAC address of the device - after a restart of NetworkManager, without reboot. A reboot clears the device state for /var/run/NetworkManager.
* config: print default value for logging.auditThomas Haller2016-10-111-1/+3
|
* config: pass default auth-polkit value as string instead of booleanBeniamino Galvani2016-10-041-0/+1
| | | | It is less efficient, but allows us to easily print the default value.
* core: refactor private data in "src"Thomas Haller2016-10-041-10/+3
| | | | | | | | | | | | | | | | - use _NM_GET_PRIVATE() and _NM_GET_PRIVATE_PTR() everywhere. - reorder statements, to have GObject related functions (init, dispose, constructed) at the bottom of each file and in a consistent order w.r.t. each other. - unify whitespaces in signal and properties declarations. - use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() - drop unused signal slots in class structures - drop unused header files for device factories
* core: forward-declare NMConfigDeviceStateData in nm-types.hThomas Haller2016-10-031-2/+2
|
* config: store and load device runtime state to fileThomas Haller2016-09-261-0/+23
| | | | | | | | | The data is still unused, the actual fields might change. Note that the actual state we store is subject to change, according to which data we need. The file format is non stable, as the files don't survive reboot. So there is no backward compatibility to maintain and the format can be changed later.
* main: create /run/NetworkManager/devices runtime directoryThomas Haller2016-09-261-0/+6
|
* config: make "ignore-carrier" a per-device configuration optionThomas Haller2016-06-301-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | NetworkManager.conf already contains several per-device settings, that is, settings that have a device-spec as argument. main.ignore-carrier main.no-auto-default main.assume-ipv6ll-only keyfile.unmanged-devices Optimally, these settings should be moved to the new [device*] section. For now, only move main.ignore-carrier there. For the others it may not make sense to do so: - main.no-auto-default: is already merged with internal state from /var/lib/NetworkManager/no-auto-default.state. While NMConfig's write API would be fine to also persist and merge the no-auto-default setting, we'd still have to read the old file too. Thus, deprecating this setting gets quite cumbersome to still handle the old state file. Also, it seems a less useful setting to configure in the global configuration aside setting main.no-auto-default=*. - main.assume-ipv6ll-only: one day, I hope that we no longer assume connections at all, and this setting becomes entirely obsolete. - keyfile.unmanged-devices: this sets NM_UNMANAGED_USER_SETTINGS, which cannot be overruled via D-Bus. For a future device.managed setting we want it it to be overwritable via D-Bus by an explicit user action. Thus, a device.managed property should have a different semantic, this should be more like a device.unmanaged-force setting, which could be done.
* config: add support for per-device configuration to NetworkManager.confThomas Haller2016-06-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | Add a new [device*] section to NetworkManager.conf. This works similar like the default connection settings in [connection*]. This will allow us to express per-device configuration in NetworkManager.conf in our familar style. Later, via NMConfig's write API it will be possible to make settings accessible via D-Bus and persist them in NetworkManager-intern.conf. This way, the user can both edit configuration snippets and modify them via D-Bus, and also support installing default configuration from the package. In a way, a [device*] setting is similar to networkd's link files. The match options is all encoded in the match-device specs. One difference is, that the resulting setting can be merged together by multiple section by partially overwriting them. This makes it more flexible and allows for example to drop a configuration snippet that only sets one property, while the rest can be merged from different snippets.
* config: cleanup includesThomas Haller2016-06-011-6/+0
|
* config: refactor change-flags to be a cause/reason which triggered the changeThomas Haller2016-06-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | For the most part, this patch just renames some change-flags, but doesn't change much about them. The new name should better express what they are. A config-change signal can be emitted for different reasons: when we receive a signal (SIGHUP, SIGUSR1, SIGUSR2) or for internal reasons like resetting of no-auto-default or setting internal values. Depending on the reason, we want to perform different actions. For example: - we reload the configuration from disk on SIGHUP, but not for SIGUSR1. - For SIGUSR1 and SIGHUP, we want to update-dns, but not for SIGUSR2. Another part of the change-flags encodes which part of the configuration actually changed. Often, these parts can only change when re-reading from disk (e.g. a SIGUSR1 will not change any configuration inside NMConfig). Later, we will have more causes, and accordingly more fine-grained effects of what should be done on reload.
* core: rename nm_config_run_state* to nm_config_state*Thomas Haller2016-04-071-12/+12
| | | | | | | | | | | After all, this state is stored persistently to /var/lib/NetworkManager, and not to volatile storage in /var/run. Hence the name is better. It's also shorter, so rename it. The commit is mostly trivial, including update of code comments and logging messages. Fixes: 1b43c880ba43260fe551b0ac923826f16737484f
* config: let NMConfig handle "NetworkManager.state" file (bgo#764474)Thomas Haller2016-04-071-0/+27
| | | | | | | | | | | | | Move reading and writing of the state file to NMConfig ("/var/lib/NetworkManager/NetworkManager.state" file). Originally, I intended to persist more state, thus it made sense to cleanup handling of the state file and move it all at one place. Now, it's not clear that will happen anytime soon. Still, the change is a worthy cleanup, so do it anyway. https://bugzilla.gnome.org/show_bug.cgi?id=764474
* config: implement nm_config_change_flags_to_string() via ↵Thomas Haller2016-01-191-1/+1
| | | | NM_UTILS_FLAGS2STR_DEFINE()
* config: add defines for key names for keyfileThomas Haller2015-12-081-0/+2
|
* keyfile: make the keyfile location configurableThomas Haller2015-10-141-0/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=755995
* config: drop global-dns.enable option in favor of .config.enableThomas Haller2015-10-051-1/+2
| | | | | | | | No longer support disabling the global-dns configuration via the "enable" option. Instead, the user can put the entire dns-configuration in one separate snippet, and disable it altogether with ".config.enable".
* config: allow to enable/disable configuration snippetsThomas Haller2015-10-051-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Support a new configuration option [.config] enable=<ENABLED> for configuration snippets. This new [.config] section is only relevant within the snippet itself and it is not merged into the combined configuration. Currently only the "enable" key is supported. If the "enable" key is missing, it obviously defaults to being enabled. It allows snippets to be skipped from loading. The main configuration "NetworkManager.conf" cannot be skipped. <ENABLED> can be a boolean value (false), to skip a configuration snippet from loading. It can also be a string to match against the NetworkManager version, like "enable=nm-version-min:1.1,nm-version-min:1.0.6" There are several motivations for this: - the user can disable an entire configuration snippet by toggeling one entry. This generalizes the functionality of the global-dns.enable setting, but in a way that applies to configuration on a per-file basis. - for developing, we often switch between different versions of NetworkManager. Thus, we might want to use different configuration. E.g. before global-dns options, I want to use "dns=none" and manage resolv.conf myself. Now, I can use global-dns setting to do that. That can be achieved with something like the following (not exactly, it's an example only): [.config] enable=nm-version-min:1.1 [main] dns=default [global-dns-domain-*] nameserver=127.0.0.1 Arguably, this would be more awesome, if we would bump our micro devel version (1.1.0) more often while developing 1.2.0 (*hint*). - in principle, packages could drop configuration snippets and enable them based on the NetworkManager version. - with the "env:" spec, you can enable/disable snippets by configuring an environment variable. Again, useful for testing and developing.
* config/trivial: rename nm_config_get_device_match_spec() to ↵Thomas Haller2015-10-051-1/+1
| | | | | | | nm_config_get_match_spec() We want to use the term match-spec more generally and not only for "device-specs".
* manager: export DNS global configuration D-Bus propertyBeniamino Galvani2015-10-011-0/+2
|
* core: add support for reading global DNS configuration from keyfileBeniamino Galvani2015-10-011-0/+8
| | | | | | Add to the NMConfigData object information about global DNS configuration, which is loaded from user or internal keyfile upon object construction.
* config: fix wrong signature of class-method config_changed() for signalThomas Haller2015-09-041-3/+0
| | | | Actually, just drop it. It's unused anyway.
* all: make use of new header file "nm-default.h"Thomas Haller2015-08-051-2/+1
|
* core: add audit supportBeniamino Galvani2015-08-041-0/+1
| | | | | | Introduce some primitives to deliver messages about relevant configuration changes to the Linux audit subsystem through libaudit (if enabled at build time) and to the logging system.
* all: rename nm-glib-compat.h to nm-glib.h, use everywhereDan Winship2015-07-241-2/+1
| | | | | | | | | | | | | | | | Rather than randomly including one or more of <glib.h>, <glib-object.h>, and <gio/gio.h> everywhere (and forgetting to include "nm-glib-compat.h" most of the time), rename nm-glib-compat.h to nm-glib.h, include <gio/gio.h> from there, and then change all .c files in NM to include "nm-glib.h" rather than including the glib headers directly. (Public headers files still have to include the real glib headers, since nm-glib.h isn't installed...) Also, remove glib includes from header files that are already including a base object header file (which must itself already include the glib headers).
* logging: make use of journal configurableThomas Haller2015-07-141-0/+1
|
* config: move debug command line option to NMConfigThomas Haller2015-07-141-0/+1
| | | | | | | | | | Whether NM runs in debug mode is also interesting to other components outside of "main.c". Expose global_opt.debug via a new nm_config_get_is_debug() function. Actually, we should move parsing of all command line options to NMConfig, as NMConfig is the central instance to provide such information.
* config: add write support to atomic-sectionsThomas Haller2015-07-021-2/+4
| | | | | | | | | | | | | | | | | | | 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.
* config: add write support for NMConfigThomas Haller2015-07-021-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* config: only handle 'option+' and 'option-' keys for known settingsThomas Haller2015-07-021-0/+1
| | | | | | | | | 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).
* config: add NMConfigGetValueFlags argument to nm_config_data_get_value()Thomas Haller2015-07-021-0/+4
| | | | | | | | | | | | 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.
* config: fix usage of g_key_file_get_value() vs. g_key_file_get_string()Thomas Haller2015-07-021-1/+1
| | | | | | | | | | | | | | 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.
* config: add defines for keyfile groups to "nm-config.h"Thomas Haller2015-07-021-0/+14
| | | | | | | | | | | | | | 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.
* config: add nm_config_parse_boolean() functionThomas Haller2015-07-021-8/+10
| | | | | | | | | | | | | 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.
View Lorry Controller Status