fdo-mirrors/NetworkManager
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git synced 2026-01-28 20:00:33 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
NetworkManager/src/nm-config-data.h

256 lines
12 KiB
C
Raw Normal View History

all: SPDX header conversion $ find * -type f |xargs perl contrib/scripts/spdx.pl $ git rm contrib/scripts/spdx.pl
2019-09-10 11:19:01 +02:00
// SPDX-License-Identifier: GPL-2.0+
all: manually drop code comments with file description
2019-09-25 13:13:40 +02:00
/*
config: add new NMConfigData class The NMConfig class should be immutable and its properties should not change, with one exception: the NMConfigData property. Later, when changing/reloading a configuration, NMConfig will only swap the NMConfigData instance. The NMConfigData instance itself is also immutable.
2014-07-11 17:57:20 +02:00
* Copyright (C) 2014 Red Hat, Inc.
*/
#ifndef NM_CONFIG_DATA_H
#define NM_CONFIG_DATA_H
core: add main.auth-polkit option "root-only" We always build with PolicyKit support enabled, because it has no additional dependencies, beside some D-Bus calls. However, in NetworkManager.conf the user could configure "main.auth-polkit" to disable PolicyKit. However, previously it would only allow to disable PolicyKit while granting access to all users. I think it's useful to have an option that disables PolicyKit and grants access only to root. I think we should not go too far in implementing our own authorization mechanisms beside PolicyKit (e.g. you cannot disable PolicyKit and grant access based on group membership of the user). However, disabling PolicyKit can be useful sometimes, and it's simple to implement a "root-only" setup. Note one change is that when NetworkManager now runs without a D-Bus connection (in initrd), it would deny all non-root requests. Previously it would grant access. I think there should be little difference in practice, because if we have no D-Bus we also don't have any requests to authenticate. (cherry picked from commit 6d7446e52f5bfe379c2b1f54f9244b33fd236e32)
2019-12-10 08:51:03 +01:00
/*****************************************************************************/
typedef enum {
/* an invalid mode. */
NM_AUTH_POLKIT_MODE_UNKNOWN,
/* don't use PolicyKit, but only allow root user (uid 0). */
NM_AUTH_POLKIT_MODE_ROOT_ONLY,
/* don't use PolicyKit, but allow all requests. */
NM_AUTH_POLKIT_MODE_ALLOW_ALL,
/* use PolicyKit to authorize requests. Root user (uid 0) always
* gets a free pass, without consulting PolicyKit. If PolicyKit is not
* running, authorization will fail for non root users. */
NM_AUTH_POLKIT_MODE_USE_POLKIT,
} NMAuthPolkitMode;
/*****************************************************************************/
config: add new NMConfigData class The NMConfig class should be immutable and its properties should not change, with one exception: the NMConfigData property. Later, when changing/reloading a configuration, NMConfig will only swap the NMConfigData instance. The NMConfigData instance itself is also immutable.
2014-07-11 17:57:20 +02:00
#define NM_TYPE_CONFIG_DATA (nm_config_data_get_type ())
#define NM_CONFIG_DATA(obj) (G_TYPE_CHECK_INSTANCE_CAST ((obj), NM_TYPE_CONFIG_DATA, NMConfigData))
#define NM_CONFIG_DATA_CLASS(klass) (G_TYPE_CHECK_CLASS_CAST ((klass), NM_TYPE_CONFIG_DATA, NMConfigDataClass))
#define NM_IS_CONFIG_DATA(obj) (G_TYPE_CHECK_INSTANCE_TYPE ((obj), NM_TYPE_CONFIG_DATA))
#define NM_IS_CONFIG_DATA_CLASS(klass) (G_TYPE_CHECK_CLASS_TYPE ((klass), NM_TYPE_CONFIG_DATA))
#define NM_CONFIG_DATA_GET_CLASS(obj) (G_TYPE_INSTANCE_GET_CLASS ((obj), NM_TYPE_CONFIG_DATA, NMConfigDataClass))
config: move main_file and description to NMConfigData Every reload might change the main_file and description. Move those properties to NMConfigData.
2015-01-06 20:16:10 +01:00
#define NM_CONFIG_DATA_CONFIG_MAIN_FILE "config-main-file"
#define NM_CONFIG_DATA_CONFIG_DESCRIPTION "config-description"
config: add write support for NMConfig 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.
2015-06-24 20:11:42 +02:00
#define NM_CONFIG_DATA_KEYFILE_USER "keyfile-user"
#define NM_CONFIG_DATA_KEYFILE_INTERN "keyfile-intern"
config: add an API to disable connectivity check via internal config file. https://bugzilla.gnome.org/show_bug.cgi?id=785117
2017-08-09 15:19:54 +08:00
#define NM_CONFIG_DATA_CONNECTIVITY_ENABLED "connectivity-enabled"
config: add new NMConfigData class The NMConfig class should be immutable and its properties should not change, with one exception: the NMConfigData property. Later, when changing/reloading a configuration, NMConfig will only swap the NMConfigData instance. The NMConfigData instance itself is also immutable.
2014-07-11 17:57:20 +02:00
#define NM_CONFIG_DATA_CONNECTIVITY_URI "connectivity-uri"
#define NM_CONFIG_DATA_CONNECTIVITY_INTERVAL "connectivity-interval"
#define NM_CONFIG_DATA_CONNECTIVITY_RESPONSE "connectivity-response"
config: move no-auto-default to NMConfigData With this change, NMConfig is really immutable and all modifyable parts migrated to NMConfigData. Another advantage is that components can now subscribe to NMConfig changes to pickup changes to no-auto-default.
2015-01-07 17:09:52 +01:00
#define NM_CONFIG_DATA_NO_AUTO_DEFAULT "no-auto-default"
config: move dns mode configuration to NMConfigData This will make is possible for the NMDnsManager to watch for configuration changes.
2015-02-12 17:35:14 +01:00
#define NM_CONFIG_DATA_DNS_MODE "dns"
config: add new NMConfigData class The NMConfig class should be immutable and its properties should not change, with one exception: the NMConfigData property. Later, when changing/reloading a configuration, NMConfig will only swap the NMConfigData instance. The NMConfigData instance itself is also immutable.
2014-07-11 17:57:20 +02:00
config,dns: support Reload flags to specify that only parts should be reloaded Support 3 new flags for Reload: - 0x01 (CONF): reload the configuration from disk - 0x02 (DNS_RC): write DNS configuration to resolv.conf - 0x04 (DNS_FULL): restart DNS plugin Omitting all flags is the same as reloading everything, thus SIGHUP.
2016-05-30 16:43:39 +02:00
typedef enum { /*< flags >*/
config: add NMConfigGetValueFlags argument to nm_config_data_get_value() 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.
2015-06-16 15:13:26 +02:00
NM_CONFIG_GET_VALUE_NONE = 0,
/* use g_key_file_get_value() instead of g_key_file_get_string(). */
NM_CONFIG_GET_VALUE_RAW = (1LL << 0),
/* strip whitespaces */
NM_CONFIG_GET_VALUE_STRIP = (1LL << 1),
/* if the returned string would be the empty word, return NULL. */
NM_CONFIG_GET_VALUE_NO_EMPTY = (1LL << 2),
/* special flag to read device spec. You want to use this before passing the
* value to nm_match_spec_split(). */
NM_CONFIG_GET_VALUE_TYPE_SPEC = NM_CONFIG_GET_VALUE_RAW,
} NMConfigGetValueFlags;
config: use flags argument in config-changed signal instead of a hash table
2015-01-21 12:58:32 +01:00
typedef enum { /*< flags >*/
NM_CONFIG_CHANGE_NONE = 0,
config: pass signals to nm_config_reload() Also react on SIGUSR1 and SIGUSR2, beside SIGHUP. Only for SIGHUP actually reload the configuration from disc. For the other signals only emit a config-changed signal.
2015-06-25 21:10:32 +02:00
config: refactor change-flags to be a cause/reason which triggered the change 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.
2016-05-30 14:53:27 +02:00
/**************************************************************************
* The external cause which triggered the reload/configuration-change
*************************************************************************/
NM_CONFIG_CHANGE_CAUSE_SIGHUP = (1L << 0),
NM_CONFIG_CHANGE_CAUSE_SIGUSR1 = (1L << 1),
NM_CONFIG_CHANGE_CAUSE_SIGUSR2 = (1L << 2),
NM_CONFIG_CHANGE_CAUSE_NO_AUTO_DEFAULT = (1L << 3),
NM_CONFIG_CHANGE_CAUSE_SET_VALUES = (1L << 4),
config,dns: support Reload flags to specify that only parts should be reloaded Support 3 new flags for Reload: - 0x01 (CONF): reload the configuration from disk - 0x02 (DNS_RC): write DNS configuration to resolv.conf - 0x04 (DNS_FULL): restart DNS plugin Omitting all flags is the same as reloading everything, thus SIGHUP.
2016-05-30 16:43:39 +02:00
NM_CONFIG_CHANGE_CAUSE_CONF = (1L << 5),
NM_CONFIG_CHANGE_CAUSE_DNS_RC = (1L << 6),
NM_CONFIG_CHANGE_CAUSE_DNS_FULL = (1L << 7),
config: refactor change-flags to be a cause/reason which triggered the change 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.
2016-05-30 14:53:27 +02:00
config,dns: support Reload flags to specify that only parts should be reloaded Support 3 new flags for Reload: - 0x01 (CONF): reload the configuration from disk - 0x02 (DNS_RC): write DNS configuration to resolv.conf - 0x04 (DNS_FULL): restart DNS plugin Omitting all flags is the same as reloading everything, thus SIGHUP.
2016-05-30 16:43:39 +02:00
NM_CONFIG_CHANGE_CAUSES = ((1L << 8) - 1),
config: refactor change-flags to be a cause/reason which triggered the change 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.
2016-05-30 14:53:27 +02:00
/**************************************************************************
* Following flags describe which property of the configuration changed:
*************************************************************************/
/* main-file or config-description changed */
NM_CONFIG_CHANGE_CONFIG_FILES = (1L << 10),
/* any configuration on disk changed */
NM_CONFIG_CHANGE_VALUES = (1L << 11),
/* any user configuration on disk changed (NetworkManager.conf) */
NM_CONFIG_CHANGE_VALUES_USER = (1L << 12),
/* any internal configuration on disk changed (NetworkManager-intern.conf) */
NM_CONFIG_CHANGE_VALUES_INTERN = (1L << 13),
/* configuration regarding connectivity changed */
NM_CONFIG_CHANGE_CONNECTIVITY = (1L << 14),
/* configuration regarding no-auto-default changed */
NM_CONFIG_CHANGE_NO_AUTO_DEFAULT = (1L << 15),
/* configuration regarding dns-mode changed */
NM_CONFIG_CHANGE_DNS_MODE = (1L << 16),
/* configuration regarding rc-manager changed */
NM_CONFIG_CHANGE_RC_MANAGER = (1L << 17),
/* configuration regarding global dns-config changed */
NM_CONFIG_CHANGE_GLOBAL_DNS_CONFIG = (1L << 18),
config: use flags argument in config-changed signal instead of a hash table
2015-01-21 12:58:32 +01:00
} NMConfigChangeFlags;
core: refactor private data in "src" - 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
2016-09-29 13:49:01 +02:00
typedef struct _NMConfigDataClass NMConfigDataClass;
config: add new NMConfigData class The NMConfig class should be immutable and its properties should not change, with one exception: the NMConfigData property. Later, when changing/reloading a configuration, NMConfig will only swap the NMConfigData instance. The NMConfigData instance itself is also immutable.
2014-07-11 17:57:20 +02:00
core: add support for reading global DNS configuration from keyfile Add to the NMConfigData object information about global DNS configuration, which is loaded from user or internal keyfile upon object construction.
2015-06-15 09:01:42 +02:00
typedef struct _NMGlobalDnsConfig NMGlobalDnsConfig;
typedef struct _NMGlobalDnsDomain NMGlobalDnsDomain;
config: add new NMConfigData class The NMConfig class should be immutable and its properties should not change, with one exception: the NMConfigData property. Later, when changing/reloading a configuration, NMConfig will only swap the NMConfigData instance. The NMConfigData instance itself is also immutable.
2014-07-11 17:57:20 +02:00
GType nm_config_data_get_type (void);
config: move main_file and description to NMConfigData Every reload might change the main_file and description. Move those properties to NMConfigData.
2015-01-06 20:16:10 +01:00
NMConfigData *nm_config_data_new (const char *config_main_file,
const char *config_description,
config: move no-auto-default to NMConfigData With this change, NMConfig is really immutable and all modifyable parts migrated to NMConfigData. Another advantage is that components can now subscribe to NMConfig changes to pickup changes to no-auto-default.
2015-01-07 17:09:52 +01:00
const char *const*no_auto_default,
config: add write support for NMConfig 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.
2015-06-24 20:11:42 +02:00
GKeyFile *keyfile_user,
GKeyFile *keyfile_intern);
NMConfigData *nm_config_data_new_update_keyfile_intern (const NMConfigData *base, GKeyFile *keyfile_intern);
config: move no-auto-default to NMConfigData With this change, NMConfig is really immutable and all modifyable parts migrated to NMConfigData. Another advantage is that components can now subscribe to NMConfig changes to pickup changes to no-auto-default.
2015-01-07 17:09:52 +01:00
NMConfigData *nm_config_data_new_update_no_auto_default (const NMConfigData *base, const char *const*no_auto_default);
config: move main_file and description to NMConfigData Every reload might change the main_file and description. Move those properties to NMConfigData.
2015-01-06 20:16:10 +01:00
config: use flags argument in config-changed signal instead of a hash table
2015-01-21 12:58:32 +01:00
NMConfigChangeFlags nm_config_data_diff (NMConfigData *old_data, NMConfigData *new_data);
config: add new function nm_config_data_diff()
2015-01-07 14:30:14 +01:00
main: add argument --print-config to NetworkManager
2015-11-20 17:52:54 +01:00
void nm_config_data_log (const NMConfigData *self,
core: log the content of "/var/lib/NetworkManager/no-auto-default.state" To understand why a profile gets not created, it's necessary to see the content of "/var/lib/NetworkManager/no-auto-default.state". Log it.
2019-09-26 09:52:23 +02:00
const char *prefix,
const char *key_prefix,
const char *no_auto_default_file,
/* FILE* */ gpointer print_stream);
config: log configuration at startup and on reload
2015-06-09 09:59:18 +02:00
config: move main_file and description to NMConfigData Every reload might change the main_file and description. Move those properties to NMConfigData.
2015-01-06 20:16:10 +01:00
const char *nm_config_data_get_config_main_file (const NMConfigData *config_data);
const char *nm_config_data_get_config_description (const NMConfigData *config_data);
config: refactor reloading not to create a second NMConfig instance
2014-12-16 16:52:34 +01:00
config: add config utility accessors
2015-06-11 23:43:29 +02:00
gboolean nm_config_data_has_group (const NMConfigData *self, const char *group);
config: add NMConfigGetValueFlags argument to nm_config_data_get_value() 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.
2015-06-16 15:13:26 +02:00
gboolean nm_config_data_has_value (const NMConfigData *self, const char *group, const char *key, NMConfigGetValueFlags flags);
char *nm_config_data_get_value (const NMConfigData *config_data, const char *group, const char *key, NMConfigGetValueFlags flags);
all: don't use gchar/gshort/gint/glong but C types We commonly don't use the glib typedefs for char/short/int/long, but their C types directly. $ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l 587 $ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l 21114 One could argue that using the glib typedefs is preferable in public API (of our glib based libnm library) or where it clearly is related to glib, like during g_object_set (obj, PROPERTY, (gint) value, NULL); However, that argument does not seem strong, because in practice we don't follow that argument today, and seldomly use the glib typedefs. Also, the style guide for this would be hard to formalize, because "using them where clearly related to a glib" is a very loose suggestion. Also note that glib typedefs will always just be typedefs of the underlying C types. There is no danger of glib changing the meaning of these typedefs (because that would be a major API break of glib). A simple style guide is instead: don't use these typedefs. No manual actions, I only ran the bash script: FILES=($(git ls-files '*.[hc]')) sed -i \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\> /\1 /g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \ "${FILES[@]}"
2018-07-11 07:40:19 +02:00
int nm_config_data_get_value_boolean (const NMConfigData *self, const char *group, const char *key, int default_value);
config: add nm_config_data_get_value_int64() util
2017-10-24 08:44:46 +02:00
gint64 nm_config_data_get_value_int64 (const NMConfigData *self, const char *group, const char *key, guint base, gint64 min, gint64 max, gint64 fallback);
config: move keyfile values to NMConfigData
2015-01-07 13:25:41 +01:00
config: optionally let nm_config_get_plugins() return compile time default 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.
2016-11-25 13:54:42 +01:00
char **nm_config_data_get_plugins (const NMConfigData *config_data, gboolean allow_default);
config: add an API to disable connectivity check via internal config file. https://bugzilla.gnome.org/show_bug.cgi?id=785117
2017-08-09 15:19:54 +08:00
gboolean nm_config_data_get_connectivity_enabled (const NMConfigData *config_data);
config: add new NMConfigData class The NMConfig class should be immutable and its properties should not change, with one exception: the NMConfigData property. Later, when changing/reloading a configuration, NMConfig will only swap the NMConfigData instance. The NMConfigData instance itself is also immutable.
2014-07-11 17:57:20 +02:00
const char *nm_config_data_get_connectivity_uri (const NMConfigData *config_data);
build: fix -Wignored-qualifiers warnings ./src/nm-config-data.h:163:1: error: 'const' type qualifier on return type has no effect [-Werror,-Wignored-qualifiers] const guint nm_config_data_get_connectivity_interval (const NMConfigData *config_data); ^~~~~~
2017-02-06 18:28:56 +01:00
guint nm_config_data_get_connectivity_interval (const NMConfigData *config_data);
config: add new NMConfigData class The NMConfig class should be immutable and its properties should not change, with one exception: the NMConfigData property. Later, when changing/reloading a configuration, NMConfig will only swap the NMConfigData instance. The NMConfigData instance itself is also immutable.
2014-07-11 17:57:20 +02:00
const char *nm_config_data_get_connectivity_response (const NMConfigData *config_data);
core: cache "autoconnect-retries-default" in NMConfigData It's not ever going to change(*), and NMPolicy calls reset() a lot. No need to lookup the configuration in the GKeyFile every time. (*) per NMConfigData instance. The config may be reloaded, in which case NMConfig creates a new NMConfigData instance, but the NMConfigData instance itself is immutable.
2017-11-22 21:19:40 +01:00
int nm_config_data_get_autoconnect_retries_default (const NMConfigData *config_data);
core: add main.auth-polkit option "root-only" We always build with PolicyKit support enabled, because it has no additional dependencies, beside some D-Bus calls. However, in NetworkManager.conf the user could configure "main.auth-polkit" to disable PolicyKit. However, previously it would only allow to disable PolicyKit while granting access to all users. I think it's useful to have an option that disables PolicyKit and grants access only to root. I think we should not go too far in implementing our own authorization mechanisms beside PolicyKit (e.g. you cannot disable PolicyKit and grant access based on group membership of the user). However, disabling PolicyKit can be useful sometimes, and it's simple to implement a "root-only" setup. Note one change is that when NetworkManager now runs without a D-Bus connection (in initrd), it would deny all non-root requests. Previously it would grant access. I think there should be little difference in practice, because if we have no D-Bus we also don't have any requests to authenticate. (cherry picked from commit 6d7446e52f5bfe379c2b1f54f9244b33fd236e32)
2019-12-10 08:51:03 +01:00
NMAuthPolkitMode nm_config_data_get_main_auth_polkit (const NMConfigData *config_data);
config: move no-auto-default to NMConfigData With this change, NMConfig is really immutable and all modifyable parts migrated to NMConfigData. Another advantage is that components can now subscribe to NMConfig changes to pickup changes to no-auto-default.
2015-01-07 17:09:52 +01:00
const char *const*nm_config_data_get_no_auto_default (const NMConfigData *config_data);
config: fix evaluation of no-auto-default setting 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.
2015-06-07 23:27:01 +02:00
gboolean nm_config_data_get_no_auto_default_for_device (const NMConfigData *self, NMDevice *device);
config: move no-auto-default to NMConfigData With this change, NMConfig is really immutable and all modifyable parts migrated to NMConfigData. Another advantage is that components can now subscribe to NMConfig changes to pickup changes to no-auto-default.
2015-01-07 17:09:52 +01:00
config: move dns mode configuration to NMConfigData This will make is possible for the NMDnsManager to watch for configuration changes.
2015-02-12 17:35:14 +01:00
const char *nm_config_data_get_dns_mode (const NMConfigData *self);
dns: allow runtime selection of resolv.conf manager Add a new 'rc-manager' configuration parameter that allows to select the strategy used to write resolv.conf; currently supported values are: none|resolvconf|netconfig, 'none' meaning that NM directly writes the file. The default value of the parameter is 'none'; however if a RESOLVCONF_PATH (or NETCONFIG_PATH) is specified at build time, the default value will be 'resolvconf' (or 'netconfig').
2015-04-20 11:11:32 +02:00
const char *nm_config_data_get_rc_manager (const NMConfigData *self);
dns: allow loading nm-dns-systemd-resolve alongside other DNS plugins Even when the system resolver is configured to something else that systemd-resolved, it still is a good idea to keep systemd-resolved up to date. If not anything else, it does a good job at doing per-interface resolving for connectivity checks. If for whatever reasons don't want NetworkManager to push the DNS data it discovers to systemd-resolved, the functionality can be disabled with: [main] systemd-resolved=false
2018-07-03 14:35:32 +02:00
gboolean nm_config_data_get_systemd_resolved (const NMConfigData *self);
config: move dns mode configuration to NMConfigData This will make is possible for the NMDnsManager to watch for configuration changes.
2015-02-12 17:35:14 +01:00
config: make ignore-carrier option reloadable Only move the ignore-carrier option from NMConfig to NMConfigData. The ignore-carrier option is still immutable after startup. https://bugzilla.gnome.org/show_bug.cgi?id=748050
2015-04-17 13:54:32 +02:00
gboolean nm_config_data_get_ignore_carrier (const NMConfigData *self, NMDevice *device);
device: don't assume by default IPv6LL-only connections Add the new configuration option 'assume-ipv6ll-only' which specifies the devices for which NM will try to assume an existing IPv6LL-only configuration. The new default behavior is to ignore such configurations since IPv6LL addresses are automatically assigned by the kernel when the device is brought up and thus the presence of an IPv6LL address doesn't mean that the device was configured by the administrator. The previous behavior was to always assume IPv6LL-only configurations but this often had the unwanted effect of preventing other on-disk configurations to be activated. To preserve the old behavior the option must be set to '*'. https://bugzilla.redhat.com/show_bug.cgi?id=1138426
2015-05-20 11:36:37 +02:00
gboolean nm_config_data_get_assume_ipv6ll_only (const NMConfigData *self, NMDevice *device);
core: allow setting SR-IOV num_vfs (cherry picked from commit 32975b6aa5b48118ec65a3790e763a530a4ad913)
2017-04-14 23:33:14 +02:00
int nm_config_data_get_sriov_num_vfs (const NMConfigData *self, NMDevice *device);
core: add support for reading global DNS configuration from keyfile Add to the NMConfigData object information about global DNS configuration, which is loaded from user or internal keyfile upon object construction.
2015-06-15 09:01:42 +02:00
NMGlobalDnsConfig *nm_config_data_get_global_dns_config (const NMConfigData *self);
config: make ignore-carrier option reloadable Only move the ignore-carrier option from NMConfig to NMConfigData. The ignore-carrier option is still immutable after startup. https://bugzilla.gnome.org/show_bug.cgi?id=748050
2015-04-17 13:54:32 +02:00
core: add checks on connection default properties Add a new CON_DEFAULT() macro that places a property name into a special section used at runtime to check whether it is a supported connection default. Unfortunately, this mechanism doesn't work for plugins so we have to enumerate the connection defaults from plugins in the daemon using another CON_DEFAULT_NOP() macro.
2018-11-14 14:52:21 +01:00
extern const char *__start_connection_defaults[];
extern const char *__stop_connection_defaults[];
#define NM_CON_DEFAULT_NOP(name) \
static const char *NM_UNIQ_T (connection_default, NM_UNIQ) \
_nm_used _nm_section ("connection_defaults") = "" name
#define NM_CON_DEFAULT(name) \
({ \
static const char *__con_default_prop \
_nm_used _nm_section ("connection_defaults") = "" name; \
\
name; \
})
config: support a [connection] section to NetworkManager.conf to specify connection defaults Add support for a new section [connection] in NetworkManager.conf. If the connection leaves an option at "unknown"/"default", we can support overwriting the value from global configuration. We also support other sections that are named with "connection" as a prefix, such as [connection2], [connection-wifi]. This is to support multiple default values that can be applied depending on the used device. I think this has great potential. Only downside is that when the user looks at a connection value, it will see that it is unspecified. But the actually used value depends on the device type and might not be obvious. https://bugzilla.gnome.org/show_bug.cgi?id=695383 https://bugzilla.redhat.com/show_bug.cgi?id=1164677
2015-05-15 11:36:28 +02:00
char *nm_config_data_get_connection_default (const NMConfigData *self,
const char *property,
NMDevice *device);
core: add nm_config_data_get_connection_default_int64()
2018-09-05 09:24:33 +02:00
gint64 nm_config_data_get_connection_default_int64 (const NMConfigData *self,
const char *property,
NMDevice *device,
gint64 min,
gint64 max,
gint64 fallback);
config: add support for per-device configuration to NetworkManager.conf 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.
2016-06-22 13:14:10 +02:00
char *nm_config_data_get_device_config (const NMConfigData *self,
const char *property,
NMDevice *device,
gboolean *has_match);
core: add nm_config_data_get_device_config_by_pllink() to lookup per-device config ... by platform link. One caveat is that without having a NMDevice instance, matching by several paramters won't work. Like, matching against the driver would require us to look it up via ethtool. When having an NMDevice instance, the driver is cached there, it's unclear we want to call ethtool for lookup in this case -- though it could be done. For other options, it's more complicated. Like, the type basically depends on the NMDevice class. Usually that also works without a netdev known to kernel (like bluetooth). The inconsistency that certain matches are not implemented is ugly indeed. But the effect is as if the spec doesn't match.
2017-12-13 15:33:33 +01:00
char *nm_config_data_get_device_config_by_pllink (const NMConfigData *self,
const char *property,
const NMPlatformLink *pllink,
core: extend nm_match_spec_device_by_pllink() with the device-type nm_match_spec_device_by_pllink() does not support matching on all parameters, unlike nm_match_spec_device(). The reason is that certain parameters are only available when having a NMDevice instance. Add an argument "match_device_type", so that the caller can inject the device type to be used. Note that for NMDevice, the device-type is nm_device_get_type_description(), which usually depends on the device class only. The only caller of nm_match_spec_device_by_pllink() is the wifi factory, and it already knows that it wants to create a device of type NMDeviceWifi. Hence, it knows and can specify "wifi" as match_device_type.
2017-12-27 09:30:49 +01:00
const char *match_device_type,
core: add nm_config_data_get_device_config_by_pllink() to lookup per-device config ... by platform link. One caveat is that without having a NMDevice instance, matching by several paramters won't work. Like, matching against the driver would require us to look it up via ethtool. When having an NMDevice instance, the driver is cached there, it's unclear we want to call ethtool for lookup in this case -- though it could be done. For other options, it's more complicated. Like, the type basically depends on the NMDevice class. Usually that also works without a netdev known to kernel (like bluetooth). The inconsistency that certain matches are not implemented is ugly indeed. But the effect is as if the spec doesn't match.
2017-12-13 15:33:33 +01:00
gboolean *has_match);
config: add support for per-device configuration to NetworkManager.conf 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.
2016-06-22 13:14:10 +02:00
gboolean nm_config_data_get_device_config_boolean (const NMConfigData *self,
const char *property,
NMDevice *device,
all: don't use gchar/gshort/gint/glong but C types We commonly don't use the glib typedefs for char/short/int/long, but their C types directly. $ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l 587 $ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l 21114 One could argue that using the glib typedefs is preferable in public API (of our glib based libnm library) or where it clearly is related to glib, like during g_object_set (obj, PROPERTY, (gint) value, NULL); However, that argument does not seem strong, because in practice we don't follow that argument today, and seldomly use the glib typedefs. Also, the style guide for this would be hard to formalize, because "using them where clearly related to a glib" is a very loose suggestion. Also note that glib typedefs will always just be typedefs of the underlying C types. There is no danger of glib changing the meaning of these typedefs (because that would be a major API break of glib). A simple style guide is instead: don't use these typedefs. No manual actions, I only ran the bash script: FILES=($(git ls-files '*.[hc]')) sed -i \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\> /\1 /g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \ "${FILES[@]}"
2018-07-11 07:40:19 +02:00
int val_no_match,
int val_invalid);
config: add support for per-device configuration to NetworkManager.conf 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.
2016-06-22 13:14:10 +02:00
config: add config utility accessors
2015-06-11 23:43:29 +02:00
char **nm_config_data_get_groups (const NMConfigData *self);
char **nm_config_data_get_keys (const NMConfigData *self, const char *group);
config: add write support to atomic-sections 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.
2015-06-10 11:59:46 +02:00
gboolean nm_config_data_is_intern_atomic_group (const NMConfigData *self, const char *group);
config: add config utility accessors
2015-06-11 23:43:29 +02:00
config: add write support for NMConfig 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.
2015-06-24 20:11:42 +02:00
GKeyFile *nm_config_data_clone_keyfile_intern (const NMConfigData *self);
config/trivial: rename dns_config local variable The variable serves a similar purpose, but is called "dns", "conf", and "dns_config". Choose one name: "dns_config".
2018-03-26 08:17:11 +02:00
const char *const *nm_global_dns_config_get_searches (const NMGlobalDnsConfig *dns_config);
const char *const *nm_global_dns_config_get_options (const NMGlobalDnsConfig *dns_config);
guint nm_global_dns_config_get_num_domains (const NMGlobalDnsConfig *dns_config);
NMGlobalDnsDomain *nm_global_dns_config_get_domain (const NMGlobalDnsConfig *dns_config, guint i);
NMGlobalDnsDomain *nm_global_dns_config_lookup_domain (const NMGlobalDnsConfig *dns_config, const char *name);
core: add support for reading global DNS configuration from keyfile Add to the NMConfigData object information about global DNS configuration, which is loaded from user or internal keyfile upon object construction.
2015-06-15 09:01:42 +02:00
const char *nm_global_dns_domain_get_name (const NMGlobalDnsDomain *domain);
const char *const *nm_global_dns_domain_get_servers (const NMGlobalDnsDomain *domain);
const char *const *nm_global_dns_domain_get_options (const NMGlobalDnsDomain *domain);
config/trivial: rename dns_config local variable The variable serves a similar purpose, but is called "dns", "conf", and "dns_config". Choose one name: "dns_config".
2018-03-26 08:17:11 +02:00
gboolean nm_global_dns_config_is_internal (const NMGlobalDnsConfig *dns_config);
gboolean nm_global_dns_config_is_empty (const NMGlobalDnsConfig *dns_config);
void nm_global_dns_config_update_checksum (const NMGlobalDnsConfig *dns_config, GChecksum *sum);
void nm_global_dns_config_free (NMGlobalDnsConfig *dns_config);
core: add support for reading global DNS configuration from keyfile Add to the NMConfigData object information about global DNS configuration, which is loaded from user or internal keyfile upon object construction.
2015-06-15 09:01:42 +02:00
manager: export DNS global configuration D-Bus property
2015-07-03 11:06:39 +02:00
NMGlobalDnsConfig *nm_global_dns_config_from_dbus (const GValue *value, GError **error);
void nm_global_dns_config_to_dbus (const NMGlobalDnsConfig *dns_config, GValue *value);
config: add nm_config_data_get_warnings() to get additional warnings about wrong configuration No additional warnings are implemented yet. (cherry picked from commit 8d20b9363b4461c7e86f2310a2fbfe88a09d5284)
2019-12-11 11:35:11 +01:00
void nm_config_data_get_warnings (const NMConfigData *self,
GPtrArray *warnings);
config: add write support for NMConfig 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.
2015-06-24 20:11:42 +02:00
/* private accessors */
GKeyFile *_nm_config_data_get_keyfile (const NMConfigData *self);
GKeyFile *_nm_config_data_get_keyfile_user (const NMConfigData *self);
GKeyFile *_nm_config_data_get_keyfile_intern (const NMConfigData *self);
device: add "dhcp-plugin" match spec for device The need for this is the following: "ipv4.dhcp-client-id" can be specified via global connection defaults. In absence of any configuration in NetworkManager, the default depends on the DHCP client plugin. In case of "dhclient", the default further depends on /etc/dhcp. For "internal" plugin, we may very well want to change the default client-id to "mac" by universally installing a configuration snippet [connection-use-mac-client-id] ipv4.dhcp-client-id=mac However, if we the user happens to enable "dhclient" plugin, this also forces the client-id and overrules configuration from /etc/dhcp. The real problem is, that dhclient can be configured via means outside of NetworkManager, so our defaults shall not overwrite defaults from /etc/dhcp. With the new device spec, we can avoid this issue: [connection-dhcp-client-id] match-device=except:dhcp-plugin:dhclient ipv4.dhcp-client-id=mac This will be part of the solution for rh#1640494. Note that merely dropping a configuration snippet is not yet enough. More fixes for DHCP will follow. Also, bug rh#1640494 may have alternative solutions as well. The nice part of this new feature is that it is generally useful for configuring connection defaults and not specifically for the client-id issue. Note that this match spec is per-device, although the plugin is selected globally. That makes some sense, because in the future we may or may not configure the DHCP plugin per-device or per address family. https://bugzilla.redhat.com/show_bug.cgi?id=1640494
2018-10-24 08:43:45 +02:00
/*****************************************************************************/
/* nm-config-data.c requires getting the DHCP manager's configuration. That is a bit
* ugly, and optimally, NMConfig* is independent of NMDhcpManager. Instead of
* including the header, forward declare the two functions that we need. */
struct _NMDhcpManager;
struct _NMDhcpManager *nm_dhcp_manager_get (void);
const char *nm_dhcp_manager_get_config (struct _NMDhcpManager *self);
config: add new NMConfigData class The NMConfig class should be immutable and its properties should not change, with one exception: the NMConfigData property. Later, when changing/reloading a configuration, NMConfig will only swap the NMConfigData instance. The NMConfigData instance itself is also immutable.
2014-07-11 17:57:20 +02:00
#endif /* NM_CONFIG_DATA_H */
Reference in a new issue Copy permalink