fdo-mirrors/NetworkManager
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git synced 2026-01-10 09:20:20 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
NetworkManager/src/core/nm-hostname-manager.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

674 lines
21 KiB
C
Raw Normal View History

all: update deprecated SPDX license identifiers These SPDX license identifiers are deprecated ([1]). Update them. [1] https://spdx.org/licenses/ sed \ -e '1 s%^/\* SPDX-License-Identifier: \(GPL-2.0\|LGPL-2.1\)+ \*/$%/* SPDX-License-Identifier: \1-or-later */%' \ -e '1,2 s%^\(--\|#\|//\) SPDX-License-Identifier: \(GPL-2.0\|LGPL-2.1\)+$%\1 SPDX-License-Identifier: \2-or-later%' \ -i \ $(git grep -l SPDX-License-Identifier -- \ ':(exclude)shared/c-*/' \ ':(exclude)shared/n-*/' \ ':(exclude)shared/systemd/src' \ ':(exclude)src/systemd/src')
2020-12-23 22:21:36 +01:00
/* SPDX-License-Identifier: GPL-2.0-or-later */
all: manually drop code comments with file description
2019-09-25 13:13:40 +02:00
/*
all: unify format of our Copyright source code comments ```bash readarray -d '' FILES < <( git ls-files -z \ ':(exclude)po' \ ':(exclude)shared/c-rbtree' \ ':(exclude)shared/c-list' \ ':(exclude)shared/c-siphash' \ ':(exclude)shared/c-stdaux' \ ':(exclude)shared/n-acd' \ ':(exclude)shared/n-dhcp4' \ ':(exclude)src/systemd/src' \ ':(exclude)shared/systemd/src' \ ':(exclude)m4' \ ':(exclude)COPYING*' ) sed \ -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) *[-–] *\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C1pyright#\5 - \7#\9/' \ -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) *[,] *\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C2pyright#\5, \7#\9/' \ -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C3pyright#\5#\7/' \ -e 's/^Copyright \(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/C4pyright#\1#\3/' \ -i \ "${FILES[@]}" echo ">>> untouched Copyright lines" git grep Copyright "${FILES[@]}" echo ">>> Copyright lines with unusual extra" git grep '\<C[0-9]pyright#' "${FILES[@]}" | grep -i reserved sed \ -e 's/\<C[0-9]pyright#\([^#]*\)#\(.*\)$/Copyright (C) \1 \2/' \ -i \ "${FILES[@]}" ``` https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/298
2019-10-01 09:20:35 +02:00
* Copyright (C) 2017 Red Hat, Inc.
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
*/
all: add "src/core/nm-default-daemon.h" as replacement for "nm-default.h"
2021-02-04 18:04:13 +01:00
#include "src/core/nm-default-daemon.h"
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
#include "nm-hostname-manager.h"
#include <sys/stat.h>
#if HAVE_SELINUX
clang-format: use "IndentPPDirectives:None" instead of "BeforeHash" Subjectively, I think this looks better.
2021-07-09 08:48:48 +02:00
#include <selinux/selinux.h>
#include <selinux/label.h>
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
#endif
build: move "libnm-core/" to "src/" and split it "libnm-core/" is rather complicated. It provides a static library that is linked into libnm.so and NetworkManager. It also contains public headers (like "nm-setting.h") which are part of public libnm API. Then we have helper libraries ("libnm-core/nm-libnm-core-*/") which only rely on public API of libnm-core, but are themself static libraries that can be used by anybody who uses libnm-core. And "libnm-core/nm-libnm-core-intern" is used by libnm-core itself. Move "libnm-core/" to "src/". But also split it in different directories so that they have a clearer purpose. The goal is to have a flat directory hierarchy. The "src/libnm-core*/" directories correspond to the different modules (static libraries and set of headers that we have). We have different kinds of such modules because of how we combine various code together. The directory layout now reflects this.
2021-02-12 15:01:09 +01:00
#include "libnm-core-aux-intern/nm-common-macros.h"
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
#include "nm-dbus-interface.h"
#include "nm-connection.h"
#include "nm-utils.h"
build: move "libnm-core/" to "src/" and split it "libnm-core/" is rather complicated. It provides a static library that is linked into libnm.so and NetworkManager. It also contains public headers (like "nm-setting.h") which are part of public libnm API. Then we have helper libraries ("libnm-core/nm-libnm-core-*/") which only rely on public API of libnm-core, but are themself static libraries that can be used by anybody who uses libnm-core. And "libnm-core/nm-libnm-core-intern" is used by libnm-core itself. Move "libnm-core/" to "src/". But also split it in different directories so that they have a clearer purpose. The goal is to have a flat directory hierarchy. The "src/libnm-core*/" directories correspond to the different modules (static libraries and set of headers that we have). We have different kinds of such modules because of how we combine various code together. The directory layout now reflects this.
2021-02-12 15:01:09 +01:00
#include "libnm-core-intern/nm-core-internal.h"
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
#include "NetworkManagerUtils.h"
/*****************************************************************************/
#define HOSTNAMED_SERVICE_NAME "org.freedesktop.hostname1"
#define HOSTNAMED_SERVICE_PATH "/org/freedesktop/hostname1"
#define HOSTNAMED_SERVICE_INTERFACE "org.freedesktop.hostname1"
#define HOSTNAME_FILE_DEFAULT "/etc/hostname"
#define HOSTNAME_FILE_UCASE_HOSTNAME "/etc/HOSTNAME"
#define HOSTNAME_FILE_GENTOO "/etc/conf.d/hostname"
hostname: drop define IFCFG_DIR which is only used once Also, "src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-common.h" already has a define IFCFG_DIR, but with a different value. We shouldn't name different things the same.
2018-07-12 10:56:35 +02:00
#define CONF_DHCP SYSCONFDIR "/sysconfig/network/dhcp"
Move CONF_DHCP definition to nm-hostname-manager.c It is only referenced from there. Fixes the build if HOSTNAME_PERSIST_SUSE is defined. Fixes: 5bfb7c3c89afe4da5b1ac2395391e9a986c722f0 https://bugzilla.gnome.org/show_bug.cgi?id=784225
2017-06-26 17:19:54 -05:00
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
#if (defined(HOSTNAME_PERSIST_SUSE) + defined(HOSTNAME_PERSIST_SLACKWARE) \
+ defined(HOSTNAME_PERSIST_GENTOO)) \
> 1
clang-format: use "IndentPPDirectives:None" instead of "BeforeHash" Subjectively, I think this looks better.
2021-07-09 08:48:48 +02:00
#error "Can only define one of HOSTNAME_PERSIST_*"
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
#endif
#if defined(HOSTNAME_PERSIST_SUSE)
clang-format: use "IndentPPDirectives:None" instead of "BeforeHash" Subjectively, I think this looks better.
2021-07-09 08:48:48 +02:00
#define HOSTNAME_FILE HOSTNAME_FILE_UCASE_HOSTNAME
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
#elif defined(HOSTNAME_PERSIST_SLACKWARE)
clang-format: use "IndentPPDirectives:None" instead of "BeforeHash" Subjectively, I think this looks better.
2021-07-09 08:48:48 +02:00
#define HOSTNAME_FILE HOSTNAME_FILE_UCASE_HOSTNAME
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
#elif defined(HOSTNAME_PERSIST_GENTOO)
clang-format: use "IndentPPDirectives:None" instead of "BeforeHash" Subjectively, I think this looks better.
2021-07-09 08:48:48 +02:00
#define HOSTNAME_FILE HOSTNAME_FILE_GENTOO
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
#else
clang-format: use "IndentPPDirectives:None" instead of "BeforeHash" Subjectively, I think this looks better.
2021-07-09 08:48:48 +02:00
#define HOSTNAME_FILE HOSTNAME_FILE_DEFAULT
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
#endif
/*****************************************************************************/
core: rename related things explicitly to "static-hostname" We have at least static and transient hostnames. Let's be clear which one we are talking about. Note that also NM_SETTINGS_HOSTNAME gets renamed to NM_SETTINGS_STATIC_HOSTNAME, because it seems clearer. The only purpose of NM_SETTINGS_STATIC_HOSTNAME is to be the backing property for the "Hostname" D-Bus property for the NMDBusObject glue. So, while the new name makes more sense to me, it's now also inconsistent with it's primary use (the D-Bus property). Still...
2022-01-04 18:28:46 +01:00
NM_GOBJECT_PROPERTIES_DEFINE(NMHostnameManager, PROP_STATIC_HOSTNAME, );
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
typedef struct {
core: rename related things explicitly to "static-hostname" We have at least static and transient hostnames. Let's be clear which one we are talking about. Note that also NM_SETTINGS_HOSTNAME gets renamed to NM_SETTINGS_STATIC_HOSTNAME, because it seems clearer. The only purpose of NM_SETTINGS_STATIC_HOSTNAME is to be the backing property for the "Hostname" D-Bus property for the NMDBusObject glue. So, while the new name makes more sense to me, it's now also inconsistent with it's primary use (the D-Bus property). Still...
2022-01-04 18:28:46 +01:00
char *static_hostname;
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
GFileMonitor *monitor;
GFileMonitor *dhcp_monitor;
gulong monitor_id;
gulong dhcp_monitor_id;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GDBusProxy *hostnamed_proxy;
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
} NMHostnameManagerPrivate;
struct _NMHostnameManager {
GObject parent;
NMHostnameManagerPrivate _priv;
};
struct _NMHostnameManagerClass {
GObjectClass parent;
};
G_DEFINE_TYPE(NMHostnameManager, nm_hostname_manager, G_TYPE_OBJECT);
#define NM_HOSTNAME_MANAGER_GET_PRIVATE(self) \
_NM_GET_PRIVATE(self, NMHostnameManager, NM_IS_HOSTNAME_MANAGER)
NM_DEFINE_SINGLETON_GETTER(NMHostnameManager, nm_hostname_manager_get, NM_TYPE_HOSTNAME_MANAGER);
/*****************************************************************************/
#define _NMLOG_DOMAIN LOGD_CORE
#define _NMLOG(level, ...) __NMLOG_DEFAULT(level, _NMLOG_DOMAIN, "hostname", __VA_ARGS__)
/*****************************************************************************/
hostname: cleanup file monitors in NMHostnameManager
2021-06-24 15:27:05 +02:00
static inline GFileMonitor *
_file_monitor_new(const char *path)
{
gs_unref_object GFile *file = NULL;
nm_assert(path);
file = g_file_new_for_path(path);
return g_file_monitor_file(file, G_FILE_MONITOR_NONE, NULL, NULL);
}
/*****************************************************************************/
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
#if defined(HOSTNAME_PERSIST_GENTOO)
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
static char *
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
read_hostname_gentoo(const char *path)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
gs_free char *contents = NULL;
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
gs_strfreev char **all_lines = NULL;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const char *tmp;
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
guint i;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
if (!g_file_get_contents(path, &contents, NULL, NULL))
return NULL;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
all_lines = g_strsplit(contents, "\n", 0);
for (i = 0; all_lines[i]; i++) {
g_strstrip(all_lines[i]);
if (all_lines[i][0] == '#' || all_lines[i][0] == '\0')
continue;
if (g_str_has_prefix(all_lines[i], "hostname=")) {
tmp = &all_lines[i][NM_STRLEN("hostname=")];
return g_shell_unquote(tmp, NULL);
}
}
return NULL;
}
#endif
#if defined(HOSTNAME_PERSIST_SLACKWARE)
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
static char *
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
read_hostname_slackware(const char *path)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
gs_free char *contents = NULL;
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
gs_strfreev char **all_lines = NULL;
hostname-manager: use fqdn for persistent hostname on Slackware This will be the default for Slackware 15.0 and on. This should be safe for both master and 1.12.x stable branch, as no existing Slackware releases are expected to run NM-1.12.x or later. Signed-off-by: Robby Workman <rworkman@slackware.com> https://mail.gnome.org/archives/networkmanager-list/2019-May/msg00011.html
2017-11-13 00:17:38 -06:00
guint i = 0;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
if (!g_file_get_contents(path, &contents, NULL, NULL))
return NULL;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
all_lines = g_strsplit(contents, "\n", 0);
for (i = 0; all_lines[i]; i++) {
g_strstrip(all_lines[i]);
if (all_lines[i][0] == '#' || all_lines[i][0] == '\0')
continue;
hostname-manager: use fqdn for persistent hostname on Slackware This will be the default for Slackware 15.0 and on. This should be safe for both master and 1.12.x stable branch, as no existing Slackware releases are expected to run NM-1.12.x or later. Signed-off-by: Robby Workman <rworkman@slackware.com> https://mail.gnome.org/archives/networkmanager-list/2019-May/msg00011.html
2017-11-13 00:17:38 -06:00
return g_shell_unquote(&all_lines[i][0], NULL);
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
}
return NULL;
}
#endif
#if defined(HOSTNAME_PERSIST_SUSE)
static gboolean
hostname_is_dynamic(void)
{
GIOChannel *channel;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
char *str = NULL;
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
gboolean dynamic = FALSE;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
channel = g_io_channel_new_file(CONF_DHCP, "r", NULL);
if (!channel)
return dynamic;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
while (g_io_channel_read_line(channel, &str, NULL, NULL, NULL) != G_IO_STATUS_EOF) {
if (str) {
g_strstrip(str);
if (g_str_has_prefix(str, "DHCLIENT_SET_HOSTNAME="))
dynamic = strcmp(&str[NM_STRLEN("DHCLIENT_SET_HOSTNAME=")], "\"yes\"") == 0;
g_free(str);
}
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
g_io_channel_shutdown(channel, FALSE, NULL);
g_io_channel_unref(channel);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
return dynamic;
}
#endif
/*****************************************************************************/
hostname: cache hostname-manager's hostname property A property preferably only emits a notify-changed signal when the value actually changes and it caches the value (so that between property-changed signals the value is guaranteed not to change). NMSettings and NMManager both already cache the hostname, because NMHostnameManager didn't guarantee this basic concept. Implement it and rely on it from NMSettings and NMPolicy. And remove the copy of the property from NMManager. Move the call for nm_dispatcher_call_hostname() from NMHostnameManager to NMManager. Note that NMPolicy also has a call to the dispatcher when set-transient-hostname returns. This should be cleaned up later.
2017-04-23 14:20:37 +02:00
const char *
core: rename related things explicitly to "static-hostname" We have at least static and transient hostnames. Let's be clear which one we are talking about. Note that also NM_SETTINGS_HOSTNAME gets renamed to NM_SETTINGS_STATIC_HOSTNAME, because it seems clearer. The only purpose of NM_SETTINGS_STATIC_HOSTNAME is to be the backing property for the "Hostname" D-Bus property for the NMDBusObject glue. So, while the new name makes more sense to me, it's now also inconsistent with it's primary use (the D-Bus property). Still...
2022-01-04 18:28:46 +01:00
nm_hostname_manager_get_static_hostname(NMHostnameManager *self)
hostname: cache hostname-manager's hostname property A property preferably only emits a notify-changed signal when the value actually changes and it caches the value (so that between property-changed signals the value is guaranteed not to change). NMSettings and NMManager both already cache the hostname, because NMHostnameManager didn't guarantee this basic concept. Implement it and rely on it from NMSettings and NMPolicy. And remove the copy of the property from NMManager. Move the call for nm_dispatcher_call_hostname() from NMHostnameManager to NMManager. Note that NMPolicy also has a call to the dispatcher when set-transient-hostname returns. This should be cleaned up later.
2017-04-23 14:20:37 +02:00
{
g_return_val_if_fail(NM_IS_HOSTNAME_MANAGER(self), NULL);
core: rename related things explicitly to "static-hostname" We have at least static and transient hostnames. Let's be clear which one we are talking about. Note that also NM_SETTINGS_HOSTNAME gets renamed to NM_SETTINGS_STATIC_HOSTNAME, because it seems clearer. The only purpose of NM_SETTINGS_STATIC_HOSTNAME is to be the backing property for the "Hostname" D-Bus property for the NMDBusObject glue. So, while the new name makes more sense to me, it's now also inconsistent with it's primary use (the D-Bus property). Still...
2022-01-04 18:28:46 +01:00
return NM_HOSTNAME_MANAGER_GET_PRIVATE(self)->static_hostname;
hostname: cache hostname-manager's hostname property A property preferably only emits a notify-changed signal when the value actually changes and it caches the value (so that between property-changed signals the value is guaranteed not to change). NMSettings and NMManager both already cache the hostname, because NMHostnameManager didn't guarantee this basic concept. Implement it and rely on it from NMSettings and NMPolicy. And remove the copy of the property from NMManager. Move the call for nm_dispatcher_call_hostname() from NMHostnameManager to NMManager. Note that NMPolicy also has a call to the dispatcher when set-transient-hostname returns. This should be cleaned up later.
2017-04-23 14:20:37 +02:00
}
static void
hostname: simplify _set_hostname() code - drop nm_hostname_manager_read_hostname() from header file. It's only used internally. - inline some code and drop helper functions.
2021-06-24 15:02:56 +02:00
_set_hostname(NMHostnameManager *self, const char *hostname)
hostname: cache hostname-manager's hostname property A property preferably only emits a notify-changed signal when the value actually changes and it caches the value (so that between property-changed signals the value is guaranteed not to change). NMSettings and NMManager both already cache the hostname, because NMHostnameManager didn't guarantee this basic concept. Implement it and rely on it from NMSettings and NMPolicy. And remove the copy of the property from NMManager. Move the call for nm_dispatcher_call_hostname() from NMHostnameManager to NMManager. Note that NMPolicy also has a call to the dispatcher when set-transient-hostname returns. This should be cleaned up later.
2017-04-23 14:20:37 +02:00
{
core: ensure static-hostname is valid UTF-8 We get the hostname via D-Bus (from hostnamed) or read it from file. In the latter case, it is not ensured that it's valid UTF-8. Non-UTF-8 "strings" are bad, because we might try to expose them on D-Bus, log them or other bad things. Sanitize the string by using backslash escaping. Maybe we should outright reject such binary nonsense, but it's not done here, for no strong reasons.
2022-01-04 19:00:34 +01:00
NMHostnameManagerPrivate *priv = NM_HOSTNAME_MANAGER_GET_PRIVATE(self);
gs_free char *hostname_free = NULL;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
char *old_hostname;
hostname: simplify _set_hostname() code - drop nm_hostname_manager_read_hostname() from header file. It's only used internally. - inline some code and drop helper functions.
2021-06-24 15:02:56 +02:00
hostname = nm_str_not_empty(hostname);
core: ensure static-hostname is valid UTF-8 We get the hostname via D-Bus (from hostnamed) or read it from file. In the latter case, it is not ensured that it's valid UTF-8. Non-UTF-8 "strings" are bad, because we might try to expose them on D-Bus, log them or other bad things. Sanitize the string by using backslash escaping. Maybe we should outright reject such binary nonsense, but it's not done here, for no strong reasons.
2022-01-04 19:00:34 +01:00
if (hostname) {
/* as we also read the file from disk, it might not be in UTF-8 encoding.
*
* A hostname in non-UTF-8 encoding would be odd and cause issues when we
* try to expose them on D-Bus via the NM_SETTINGS_STATIC_HOSTNAME property.
*
* Sanitize somewhat. It's wrong anyway. */
hostname = nm_utils_str_utf8safe_escape(hostname,
NM_UTILS_STR_UTF8_SAFE_FLAG_ESCAPE_CTRL,
&hostname_free);
}
core: rename related things explicitly to "static-hostname" We have at least static and transient hostnames. Let's be clear which one we are talking about. Note that also NM_SETTINGS_HOSTNAME gets renamed to NM_SETTINGS_STATIC_HOSTNAME, because it seems clearer. The only purpose of NM_SETTINGS_STATIC_HOSTNAME is to be the backing property for the "Hostname" D-Bus property for the NMDBusObject glue. So, while the new name makes more sense to me, it's now also inconsistent with it's primary use (the D-Bus property). Still...
2022-01-04 18:28:46 +01:00
if (nm_streq0(hostname, priv->static_hostname))
hostname: simplify _set_hostname() code - drop nm_hostname_manager_read_hostname() from header file. It's only used internally. - inline some code and drop helper functions.
2021-06-24 15:02:56 +02:00
return;
hostname: cache hostname-manager's hostname property A property preferably only emits a notify-changed signal when the value actually changes and it caches the value (so that between property-changed signals the value is guaranteed not to change). NMSettings and NMManager both already cache the hostname, because NMHostnameManager didn't guarantee this basic concept. Implement it and rely on it from NMSettings and NMPolicy. And remove the copy of the property from NMManager. Move the call for nm_dispatcher_call_hostname() from NMHostnameManager to NMManager. Note that NMPolicy also has a call to the dispatcher when set-transient-hostname returns. This should be cleaned up later.
2017-04-23 14:20:37 +02:00
core: rename related things explicitly to "static-hostname" We have at least static and transient hostnames. Let's be clear which one we are talking about. Note that also NM_SETTINGS_HOSTNAME gets renamed to NM_SETTINGS_STATIC_HOSTNAME, because it seems clearer. The only purpose of NM_SETTINGS_STATIC_HOSTNAME is to be the backing property for the "Hostname" D-Bus property for the NMDBusObject glue. So, while the new name makes more sense to me, it's now also inconsistent with it's primary use (the D-Bus property). Still...
2022-01-04 18:28:46 +01:00
_LOGI("static hostname changed from %s%s%s to %s%s%s",
NM_PRINT_FMT_QUOTED(priv->static_hostname, "\"", priv->static_hostname, "\"", "(none)"),
hostname: cache hostname-manager's hostname property A property preferably only emits a notify-changed signal when the value actually changes and it caches the value (so that between property-changed signals the value is guaranteed not to change). NMSettings and NMManager both already cache the hostname, because NMHostnameManager didn't guarantee this basic concept. Implement it and rely on it from NMSettings and NMPolicy. And remove the copy of the property from NMManager. Move the call for nm_dispatcher_call_hostname() from NMHostnameManager to NMManager. Note that NMPolicy also has a call to the dispatcher when set-transient-hostname returns. This should be cleaned up later.
2017-04-23 14:20:37 +02:00
NM_PRINT_FMT_QUOTED(hostname, "\"", hostname, "\"", "(none)"));
core: rename related things explicitly to "static-hostname" We have at least static and transient hostnames. Let's be clear which one we are talking about. Note that also NM_SETTINGS_HOSTNAME gets renamed to NM_SETTINGS_STATIC_HOSTNAME, because it seems clearer. The only purpose of NM_SETTINGS_STATIC_HOSTNAME is to be the backing property for the "Hostname" D-Bus property for the NMDBusObject glue. So, while the new name makes more sense to me, it's now also inconsistent with it's primary use (the D-Bus property). Still...
2022-01-04 18:28:46 +01:00
old_hostname = priv->static_hostname;
priv->static_hostname = g_strdup(hostname);
hostname: simplify _set_hostname() code - drop nm_hostname_manager_read_hostname() from header file. It's only used internally. - inline some code and drop helper functions.
2021-06-24 15:02:56 +02:00
g_free(old_hostname);
hostname: cache hostname-manager's hostname property A property preferably only emits a notify-changed signal when the value actually changes and it caches the value (so that between property-changed signals the value is guaranteed not to change). NMSettings and NMManager both already cache the hostname, because NMHostnameManager didn't guarantee this basic concept. Implement it and rely on it from NMSettings and NMPolicy. And remove the copy of the property from NMManager. Move the call for nm_dispatcher_call_hostname() from NMHostnameManager to NMManager. Note that NMPolicy also has a call to the dispatcher when set-transient-hostname returns. This should be cleaned up later.
2017-04-23 14:20:37 +02:00
core: rename related things explicitly to "static-hostname" We have at least static and transient hostnames. Let's be clear which one we are talking about. Note that also NM_SETTINGS_HOSTNAME gets renamed to NM_SETTINGS_STATIC_HOSTNAME, because it seems clearer. The only purpose of NM_SETTINGS_STATIC_HOSTNAME is to be the backing property for the "Hostname" D-Bus property for the NMDBusObject glue. So, while the new name makes more sense to me, it's now also inconsistent with it's primary use (the D-Bus property). Still...
2022-01-04 18:28:46 +01:00
_notify(self, PROP_STATIC_HOSTNAME);
hostname: cache hostname-manager's hostname property A property preferably only emits a notify-changed signal when the value actually changes and it caches the value (so that between property-changed signals the value is guaranteed not to change). NMSettings and NMManager both already cache the hostname, because NMHostnameManager didn't guarantee this basic concept. Implement it and rely on it from NMSettings and NMPolicy. And remove the copy of the property from NMManager. Move the call for nm_dispatcher_call_hostname() from NMHostnameManager to NMManager. Note that NMPolicy also has a call to the dispatcher when set-transient-hostname returns. This should be cleaned up later.
2017-04-23 14:20:37 +02:00
}
static void
hostname: simplify _set_hostname() code - drop nm_hostname_manager_read_hostname() from header file. It's only used internally. - inline some code and drop helper functions.
2021-06-24 15:02:56 +02:00
_set_hostname_read_file(NMHostnameManager *self)
hostname: cache hostname-manager's hostname property A property preferably only emits a notify-changed signal when the value actually changes and it caches the value (so that between property-changed signals the value is guaranteed not to change). NMSettings and NMManager both already cache the hostname, because NMHostnameManager didn't guarantee this basic concept. Implement it and rely on it from NMSettings and NMPolicy. And remove the copy of the property from NMManager. Move the call for nm_dispatcher_call_hostname() from NMHostnameManager to NMManager. Note that NMPolicy also has a call to the dispatcher when set-transient-hostname returns. This should be cleaned up later.
2017-04-23 14:20:37 +02:00
{
hostname: simplify _set_hostname() code - drop nm_hostname_manager_read_hostname() from header file. It's only used internally. - inline some code and drop helper functions.
2021-06-24 15:02:56 +02:00
NMHostnameManagerPrivate *priv = NM_HOSTNAME_MANAGER_GET_PRIVATE(self);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
gs_free char *hostname = NULL;
hostname: cache hostname-manager's hostname property A property preferably only emits a notify-changed signal when the value actually changes and it caches the value (so that between property-changed signals the value is guaranteed not to change). NMSettings and NMManager both already cache the hostname, because NMHostnameManager didn't guarantee this basic concept. Implement it and rely on it from NMSettings and NMPolicy. And remove the copy of the property from NMManager. Move the call for nm_dispatcher_call_hostname() from NMHostnameManager to NMManager. Note that NMPolicy also has a call to the dispatcher when set-transient-hostname returns. This should be cleaned up later.
2017-04-23 14:20:37 +02:00
if (priv->hostnamed_proxy) {
/* read-hostname returns the current hostname with hostnamed. */
return;
}
hostname: simplify _set_hostname() code - drop nm_hostname_manager_read_hostname() from header file. It's only used internally. - inline some code and drop helper functions.
2021-06-24 15:02:56 +02:00
#if defined(HOSTNAME_PERSIST_SUSE)
if (priv->dhcp_monitor_id && hostname_is_dynamic())
hostname: cache hostname-manager's hostname property A property preferably only emits a notify-changed signal when the value actually changes and it caches the value (so that between property-changed signals the value is guaranteed not to change). NMSettings and NMManager both already cache the hostname, because NMHostnameManager didn't guarantee this basic concept. Implement it and rely on it from NMSettings and NMPolicy. And remove the copy of the property from NMManager. Move the call for nm_dispatcher_call_hostname() from NMHostnameManager to NMManager. Note that NMPolicy also has a call to the dispatcher when set-transient-hostname returns. This should be cleaned up later.
2017-04-23 14:20:37 +02:00
return;
hostname: simplify _set_hostname() code - drop nm_hostname_manager_read_hostname() from header file. It's only used internally. - inline some code and drop helper functions.
2021-06-24 15:02:56 +02:00
#endif
#if defined(HOSTNAME_PERSIST_GENTOO)
hostname = read_hostname_gentoo(HOSTNAME_FILE);
#elif defined(HOSTNAME_PERSIST_SLACKWARE)
core: fix unsetting static hostname via empty argument This was broken for a very long time, since 6a60dc2fe9a1 ('settings: validate hostnames from D-Bus (bgo #711179)') from October 2013. But there is really no reason to use this API, as we have systemd-hostnamed. https://bugzilla.redhat.com/show_bug.cgi?id=2090946
2022-05-27 11:05:11 +02:00
hostname = read_hostname_slackware(HOSTNAME_FILE);
hostname: simplify _set_hostname() code - drop nm_hostname_manager_read_hostname() from header file. It's only used internally. - inline some code and drop helper functions.
2021-06-24 15:02:56 +02:00
#else
if (g_file_get_contents(HOSTNAME_FILE, &hostname, NULL, NULL))
g_strchomp(hostname);
#endif
hostname: cache hostname-manager's hostname property A property preferably only emits a notify-changed signal when the value actually changes and it caches the value (so that between property-changed signals the value is guaranteed not to change). NMSettings and NMManager both already cache the hostname, because NMHostnameManager didn't guarantee this basic concept. Implement it and rely on it from NMSettings and NMPolicy. And remove the copy of the property from NMManager. Move the call for nm_dispatcher_call_hostname() from NMHostnameManager to NMManager. Note that NMPolicy also has a call to the dispatcher when set-transient-hostname returns. This should be cleaned up later.
2017-04-23 14:20:37 +02:00
hostname: simplify _set_hostname() code - drop nm_hostname_manager_read_hostname() from header file. It's only used internally. - inline some code and drop helper functions.
2021-06-24 15:02:56 +02:00
_set_hostname(self, hostname);
hostname: cache hostname-manager's hostname property A property preferably only emits a notify-changed signal when the value actually changes and it caches the value (so that between property-changed signals the value is guaranteed not to change). NMSettings and NMManager both already cache the hostname, because NMHostnameManager didn't guarantee this basic concept. Implement it and rely on it from NMSettings and NMPolicy. And remove the copy of the property from NMManager. Move the call for nm_dispatcher_call_hostname() from NMHostnameManager to NMManager. Note that NMPolicy also has a call to the dispatcher when set-transient-hostname returns. This should be cleaned up later.
2017-04-23 14:20:37 +02:00
}
/*****************************************************************************/
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
static void
set_transient_hostname_done(GObject *object, GAsyncResult *res, gpointer user_data)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GDBusProxy *proxy = G_DBUS_PROXY(object);
gs_unref_variant GVariant *result = NULL;
gs_free_error GError *error = NULL;
gs_free char *hostname = NULL;
hostname: use nm_utils_user_data_pack() instead of SetHostnameInfo struct
2021-06-24 15:10:08 +02:00
NMHostnameManagerSetHostnameCb cb;
gpointer cb_user_data;
nm_utils_user_data_unpack(user_data, &hostname, &cb, &cb_user_data);
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
result = g_dbus_proxy_call_finish(proxy, res, &error);
if (error) {
_LOGW("couldn't set the system hostname to '%s' using hostnamed: %s",
hostname: use nm_utils_user_data_pack() instead of SetHostnameInfo struct
2021-06-24 15:10:08 +02:00
hostname,
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
error->message);
}
hostname: use nm_utils_user_data_pack() instead of SetHostnameInfo struct
2021-06-24 15:10:08 +02:00
cb(hostname, !error, cb_user_data);
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
}
void
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
nm_hostname_manager_set_transient_hostname(NMHostnameManager *self,
const char *hostname,
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
NMHostnameManagerSetHostnameCb cb,
gpointer user_data)
{
NMHostnameManagerPrivate *priv;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
g_return_if_fail(NM_IS_HOSTNAME_MANAGER(self));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
priv = NM_HOSTNAME_MANAGER_GET_PRIVATE(self);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
if (!priv->hostnamed_proxy) {
cb(hostname, FALSE, user_data);
return;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
g_dbus_proxy_call(priv->hostnamed_proxy,
"SetHostname",
g_variant_new("(sb)", hostname, FALSE),
G_DBUS_CALL_FLAGS_NONE,
-1,
NULL,
set_transient_hostname_done,
hostname: use nm_utils_user_data_pack() instead of SetHostnameInfo struct
2021-06-24 15:10:08 +02:00
nm_utils_user_data_pack(g_strdup(hostname), cb, user_data));
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
}
gboolean
nm_hostname_manager_get_transient_hostname(NMHostnameManager *self, char **hostname)
{
NMHostnameManagerPrivate *priv = NM_HOSTNAME_MANAGER_GET_PRIVATE(self);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GVariant *v_hostname;
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
if (!priv->hostnamed_proxy)
return FALSE;
v_hostname = g_dbus_proxy_get_cached_property(priv->hostnamed_proxy, "Hostname");
if (!v_hostname) {
_LOGT("transient hostname retrieval failed");
return FALSE;
}
*hostname = g_variant_dup_string(v_hostname, NULL);
g_variant_unref(v_hostname);
return TRUE;
}
core/hostname: avoid blocking calls in NMHostnameManager setting static hostname Of course, blocking and synchronous code is much simpler. But it's also fundamentally wrong to block while we talk to systemd-hostnamed. Refactor to use async operations.
2022-05-27 11:45:50 +02:00
/*****************************************************************************/
static void
_write_hostname_dbus_cb(GObject *source, GAsyncResult *result, gpointer user_data)
{
gs_unref_object GTask *task = G_TASK(user_data);
gs_unref_variant GVariant *res = NULL;
GError *error = NULL;
res = g_dbus_proxy_call_finish(G_DBUS_PROXY(source), result, &error);
if (!res) {
g_task_return_error(task, error);
return;
}
g_task_return_boolean(task, TRUE);
}
static void
_write_hostname_on_idle_cb(gpointer user_data, GCancellable *cancellable)
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
{
core: fix unused variable in _write_hostname_on_idle_cb() Fixes: 4dc3f3da171a ('core/hostname: avoid blocking calls in NMHostnameManager setting static hostname')
2022-05-30 18:46:27 +02:00
gs_unref_object GTask *task = G_TASK(user_data);
NMHostnameManager *self;
NMHostnameManagerPrivate *priv;
const char *hostname;
gs_free char *hostname_eol = NULL;
gboolean ret;
gs_free_error GError *error = NULL;
const char *file = HOSTNAME_FILE;
gs_free char *link_path = NULL;
struct stat file_stat;
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
#if HAVE_SELINUX
core: avoid deprecated matchfilecon SELinux API instead of selabel The matchfilecon API is deprecated for a very long time. Since selinux 3.1 the functions are also marked as deprecated in the header, which causes compiler warnings and build failures. Update the code to use selabel API instead.
2020-08-12 13:31:31 +02:00
gboolean fcon_was_set = FALSE;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
char *fcon_prev = NULL;
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
#endif
core/hostname: avoid blocking calls in NMHostnameManager setting static hostname Of course, blocking and synchronous code is much simpler. But it's also fundamentally wrong to block while we talk to systemd-hostnamed. Refactor to use async operations.
2022-05-27 11:45:50 +02:00
if (g_task_return_error_if_cancelled(task))
return;
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
core/hostname: avoid blocking calls in NMHostnameManager setting static hostname Of course, blocking and synchronous code is much simpler. But it's also fundamentally wrong to block while we talk to systemd-hostnamed. Refactor to use async operations.
2022-05-27 11:45:50 +02:00
self = g_task_get_source_object(task);
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
priv = NM_HOSTNAME_MANAGER_GET_PRIVATE(self);
core/hostname: avoid blocking calls in NMHostnameManager setting static hostname Of course, blocking and synchronous code is much simpler. But it's also fundamentally wrong to block while we talk to systemd-hostnamed. Refactor to use async operations.
2022-05-27 11:45:50 +02:00
nm_assert(!priv->hostnamed_proxy);
hostname = g_task_get_task_data(task);
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
/* If the hostname file is a symbolic link, follow it to find where the
* real file is located, otherwise g_file_set_contents will attempt to
* replace the link with a plain file.
*/
if (lstat(file, &file_stat) == 0 && S_ISLNK(file_stat.st_mode)
&& (link_path = nm_utils_read_link_absolute(file, NULL)))
file = link_path;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: fix unsetting static hostname via empty argument This was broken for a very long time, since 6a60dc2fe9a1 ('settings: validate hostnames from D-Bus (bgo #711179)') from October 2013. But there is really no reason to use this API, as we have systemd-hostnamed. https://bugzilla.redhat.com/show_bug.cgi?id=2090946
2022-05-27 11:05:11 +02:00
if (hostname) {
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
#if defined(HOSTNAME_PERSIST_GENTOO)
core: fix unsetting static hostname via empty argument This was broken for a very long time, since 6a60dc2fe9a1 ('settings: validate hostnames from D-Bus (bgo #711179)') from October 2013. But there is really no reason to use this API, as we have systemd-hostnamed. https://bugzilla.redhat.com/show_bug.cgi?id=2090946
2022-05-27 11:05:11 +02:00
hostname_eol = g_strdup_printf("#Generated by NetworkManager\n"
"hostname=\"%s\"\n",
hostname);
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
#else
core: fix unsetting static hostname via empty argument This was broken for a very long time, since 6a60dc2fe9a1 ('settings: validate hostnames from D-Bus (bgo #711179)') from October 2013. But there is really no reason to use this API, as we have systemd-hostnamed. https://bugzilla.redhat.com/show_bug.cgi?id=2090946
2022-05-27 11:05:11 +02:00
hostname_eol = g_strdup_printf("%s\n", hostname);
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
#endif
core: fix unsetting static hostname via empty argument This was broken for a very long time, since 6a60dc2fe9a1 ('settings: validate hostnames from D-Bus (bgo #711179)') from October 2013. But there is really no reason to use this API, as we have systemd-hostnamed. https://bugzilla.redhat.com/show_bug.cgi?id=2090946
2022-05-27 11:05:11 +02:00
}
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
core: avoid deprecated matchfilecon SELinux API instead of selabel The matchfilecon API is deprecated for a very long time. Since selinux 3.1 the functions are also marked as deprecated in the header, which causes compiler warnings and build failures. Update the code to use selabel API instead.
2020-08-12 13:31:31 +02:00
#if HAVE_SELINUX
/* Get default context for hostname file and set it for fscreate */
{
struct selabel_handle *handle;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: avoid deprecated matchfilecon SELinux API instead of selabel The matchfilecon API is deprecated for a very long time. Since selinux 3.1 the functions are also marked as deprecated in the header, which causes compiler warnings and build failures. Update the code to use selabel API instead.
2020-08-12 13:31:31 +02:00
handle = selabel_open(SELABEL_CTX_FILE, NULL, 0);
if (handle) {
mode_t st_mode = 0;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
char *fcon = NULL;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: avoid deprecated matchfilecon SELinux API instead of selabel The matchfilecon API is deprecated for a very long time. Since selinux 3.1 the functions are also marked as deprecated in the header, which causes compiler warnings and build failures. Update the code to use selabel API instead.
2020-08-12 13:31:31 +02:00
if (stat(file, &file_stat) == 0)
st_mode = file_stat.st_mode;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: avoid deprecated matchfilecon SELinux API instead of selabel The matchfilecon API is deprecated for a very long time. Since selinux 3.1 the functions are also marked as deprecated in the header, which causes compiler warnings and build failures. Update the code to use selabel API instead.
2020-08-12 13:31:31 +02:00
if ((selabel_lookup(handle, &fcon, file, st_mode) == 0)
&& (getfscreatecon(&fcon_prev) == 0)) {
setfscreatecon(fcon);
fcon_was_set = TRUE;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: avoid deprecated matchfilecon SELinux API instead of selabel The matchfilecon API is deprecated for a very long time. Since selinux 3.1 the functions are also marked as deprecated in the header, which causes compiler warnings and build failures. Update the code to use selabel API instead.
2020-08-12 13:31:31 +02:00
selabel_close(handle);
freecon(fcon);
}
}
#endif
core: fix unsetting static hostname via empty argument This was broken for a very long time, since 6a60dc2fe9a1 ('settings: validate hostnames from D-Bus (bgo #711179)') from October 2013. But there is really no reason to use this API, as we have systemd-hostnamed. https://bugzilla.redhat.com/show_bug.cgi?id=2090946
2022-05-27 11:05:11 +02:00
ret = g_file_set_contents(file, hostname_eol ?: "", -1, &error);
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
#if HAVE_SELINUX
/* Restore previous context and cleanup */
core: avoid deprecated matchfilecon SELinux API instead of selabel The matchfilecon API is deprecated for a very long time. Since selinux 3.1 the functions are also marked as deprecated in the header, which causes compiler warnings and build failures. Update the code to use selabel API instead.
2020-08-12 13:31:31 +02:00
if (fcon_was_set)
setfscreatecon(fcon_prev);
if (fcon_prev)
freecon(fcon_prev);
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
#endif
if (!ret) {
core/hostname: avoid blocking calls in NMHostnameManager setting static hostname Of course, blocking and synchronous code is much simpler. But it's also fundamentally wrong to block while we talk to systemd-hostnamed. Refactor to use async operations.
2022-05-27 11:45:50 +02:00
g_task_return_new_error(task,
NM_UTILS_ERROR,
NM_UTILS_ERROR_UNKNOWN,
"could not save hostname to %s: %s",
file,
error->message);
return;
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
}
core/hostname: avoid blocking calls in NMHostnameManager setting static hostname Of course, blocking and synchronous code is much simpler. But it's also fundamentally wrong to block while we talk to systemd-hostnamed. Refactor to use async operations.
2022-05-27 11:45:50 +02:00
g_task_return_boolean(task, TRUE);
}
void
nm_hostname_manager_write_hostname(NMHostnameManager *self,
const char *hostname,
GCancellable *cancellable,
GAsyncReadyCallback callback,
gpointer user_data)
{
NMHostnameManagerPrivate *priv;
GTask *task;
g_return_if_fail(NM_IS_HOSTNAME_MANAGER(self));
priv = NM_HOSTNAME_MANAGER_GET_PRIVATE(self);
task =
nm_g_task_new(self, cancellable, nm_hostname_manager_write_hostname, callback, user_data);
g_task_set_task_data(task, g_strdup(hostname), g_free);
if (priv->hostnamed_proxy) {
g_dbus_proxy_call(priv->hostnamed_proxy,
"SetStaticHostname",
g_variant_new("(sb)", hostname ?: "", FALSE),
G_DBUS_CALL_FLAGS_NONE,
15000,
cancellable,
_write_hostname_dbus_cb,
task);
return;
}
nm_utils_invoke_on_idle(cancellable, _write_hostname_on_idle_cb, task);
}
gboolean
nm_hostname_manager_write_hostname_finish(NMHostnameManager *self,
GAsyncResult *result,
GError **error)
{
g_return_val_if_fail(NM_IS_HOSTNAME_MANAGER(self), FALSE);
g_return_val_if_fail(nm_g_task_is_valid(result, self, nm_hostname_manager_write_hostname),
FALSE);
return g_task_propagate_boolean(G_TASK(result), error);
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
}
/*****************************************************************************/
static void
hostnamed_properties_changed(GDBusProxy *proxy,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GVariant *changed_properties,
char **invalidated_properties,
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
gpointer user_data)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMHostnameManager *self = user_data;
NMHostnameManagerPrivate *priv = NM_HOSTNAME_MANAGER_GET_PRIVATE(self);
hostname: simplify _set_hostname() code - drop nm_hostname_manager_read_hostname() from header file. It's only used internally. - inline some code and drop helper functions.
2021-06-24 15:02:56 +02:00
gs_unref_variant GVariant *variant = NULL;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
hostname: simplify _set_hostname() code - drop nm_hostname_manager_read_hostname() from header file. It's only used internally. - inline some code and drop helper functions.
2021-06-24 15:02:56 +02:00
variant = g_dbus_proxy_get_cached_property(priv->hostnamed_proxy, "StaticHostname");
if (variant && g_variant_is_of_type(variant, G_VARIANT_TYPE_STRING))
_set_hostname(self, g_variant_get_string(variant, NULL));
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
}
hostname: cleanup file monitors in NMHostnameManager
2021-06-24 15:27:05 +02:00
/*****************************************************************************/
static void
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
_file_monitors_file_changed_cb(GFileMonitor *monitor,
GFile *file,
GFile *other_file,
hostname: cleanup file monitors in NMHostnameManager
2021-06-24 15:27:05 +02:00
GFileMonitorEvent event_type,
gpointer user_data)
{
_set_hostname_read_file(user_data);
}
static void
_file_monitors_clear(NMHostnameManager *self)
{
NMHostnameManagerPrivate *priv = NM_HOSTNAME_MANAGER_GET_PRIVATE(self);
if (priv->monitor) {
nm_clear_g_signal_handler(priv->monitor, &priv->monitor_id);
g_file_monitor_cancel(priv->monitor);
g_clear_object(&priv->monitor);
}
if (priv->dhcp_monitor) {
nm_clear_g_signal_handler(priv->dhcp_monitor, &priv->dhcp_monitor_id);
g_file_monitor_cancel(priv->dhcp_monitor);
g_clear_object(&priv->dhcp_monitor);
}
}
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
static void
hostname: cleanup file monitors in NMHostnameManager
2021-06-24 15:27:05 +02:00
_file_monitors_setup(NMHostnameManager *self)
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
{
NMHostnameManagerPrivate *priv = NM_HOSTNAME_MANAGER_GET_PRIVATE(self);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GFileMonitor *monitor;
const char *path = HOSTNAME_FILE;
gs_free char *link_path = NULL;
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
struct stat file_stat;
hostname: cleanup file monitors in NMHostnameManager
2021-06-24 15:27:05 +02:00
_file_monitors_clear(self);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
/* resolve the path to the hostname file if it is a symbolic link */
if (lstat(path, &file_stat) == 0 && S_ISLNK(file_stat.st_mode)
&& (link_path = nm_utils_read_link_absolute(path, NULL))) {
path = link_path;
if (lstat(link_path, &file_stat) == 0 && S_ISLNK(file_stat.st_mode)) {
_LOGW("only one level of symbolic link indirection is allowed when "
"monitoring " HOSTNAME_FILE);
}
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
/* monitor changes to hostname file */
hostname: cleanup file monitors in NMHostnameManager
2021-06-24 15:27:05 +02:00
monitor = _file_monitor_new(path);
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
if (monitor) {
priv->monitor_id =
hostname: cleanup file monitors in NMHostnameManager
2021-06-24 15:27:05 +02:00
g_signal_connect(monitor, "changed", G_CALLBACK(_file_monitors_file_changed_cb), self);
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
priv->monitor = monitor;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
#if defined(HOSTNAME_PERSIST_SUSE)
/* monitor changes to dhcp file to know whether the hostname is valid */
hostname: cleanup file monitors in NMHostnameManager
2021-06-24 15:27:05 +02:00
monitor = _file_monitor_new(CONF_DHCP);
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
if (monitor) {
priv->dhcp_monitor_id =
hostname: cleanup file monitors in NMHostnameManager
2021-06-24 15:27:05 +02:00
g_signal_connect(monitor, "changed", G_CALLBACK(_file_monitors_file_changed_cb), self);
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
priv->dhcp_monitor = monitor;
}
#endif
hostname: simplify _set_hostname() code - drop nm_hostname_manager_read_hostname() from header file. It's only used internally. - inline some code and drop helper functions.
2021-06-24 15:02:56 +02:00
_set_hostname_read_file(self);
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
}
/*****************************************************************************/
static void
get_property(GObject *object, guint prop_id, GValue *value, GParamSpec *pspec)
{
NMHostnameManager *self = NM_HOSTNAME_MANAGER(object);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
switch (prop_id) {
core: rename related things explicitly to "static-hostname" We have at least static and transient hostnames. Let's be clear which one we are talking about. Note that also NM_SETTINGS_HOSTNAME gets renamed to NM_SETTINGS_STATIC_HOSTNAME, because it seems clearer. The only purpose of NM_SETTINGS_STATIC_HOSTNAME is to be the backing property for the "Hostname" D-Bus property for the NMDBusObject glue. So, while the new name makes more sense to me, it's now also inconsistent with it's primary use (the D-Bus property). Still...
2022-01-04 18:28:46 +01:00
case PROP_STATIC_HOSTNAME:
g_value_set_string(value, nm_hostname_manager_get_static_hostname(self));
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
break;
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID(object, prop_id, pspec);
break;
}
}
/*****************************************************************************/
static void
nm_hostname_manager_init(NMHostnameManager *self)
{}
static void
constructed(GObject *object)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMHostnameManager *self = NM_HOSTNAME_MANAGER(object);
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
NMHostnameManagerPrivate *priv = NM_HOSTNAME_MANAGER_GET_PRIVATE(self);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GDBusProxy *proxy;
GVariant *variant;
gs_free_error GError *error = NULL;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
proxy = g_dbus_proxy_new_for_bus_sync(G_BUS_TYPE_SYSTEM,
0,
NULL,
HOSTNAMED_SERVICE_NAME,
HOSTNAMED_SERVICE_PATH,
HOSTNAMED_SERVICE_INTERFACE,
NULL,
&error);
if (proxy) {
variant = g_dbus_proxy_get_cached_property(proxy, "StaticHostname");
if (variant) {
_LOGI("hostname: using hostnamed");
priv->hostnamed_proxy = proxy;
g_signal_connect(proxy,
"g-properties-changed",
G_CALLBACK(hostnamed_properties_changed),
self);
hostnamed_properties_changed(proxy, NULL, NULL, self);
g_variant_unref(variant);
} else {
_LOGI("hostname: couldn't get property from hostnamed");
g_object_unref(proxy);
}
} else {
_LOGI("hostname: hostnamed not used as proxy creation failed with: %s", error->message);
g_clear_error(&error);
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
if (!priv->hostnamed_proxy)
hostname: cleanup file monitors in NMHostnameManager
2021-06-24 15:27:05 +02:00
_file_monitors_setup(self);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
G_OBJECT_CLASS(nm_hostname_manager_parent_class)->constructed(object);
}
static void
dispose(GObject *object)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMHostnameManager *self = NM_HOSTNAME_MANAGER(object);
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
NMHostnameManagerPrivate *priv = NM_HOSTNAME_MANAGER_GET_PRIVATE(self);
if (priv->hostnamed_proxy) {
g_signal_handlers_disconnect_by_func(priv->hostnamed_proxy,
G_CALLBACK(hostnamed_properties_changed),
self);
g_clear_object(&priv->hostnamed_proxy);
}
hostname: cleanup file monitors in NMHostnameManager
2021-06-24 15:27:05 +02:00
_file_monitors_clear(self);
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
core: rename related things explicitly to "static-hostname" We have at least static and transient hostnames. Let's be clear which one we are talking about. Note that also NM_SETTINGS_HOSTNAME gets renamed to NM_SETTINGS_STATIC_HOSTNAME, because it seems clearer. The only purpose of NM_SETTINGS_STATIC_HOSTNAME is to be the backing property for the "Hostname" D-Bus property for the NMDBusObject glue. So, while the new name makes more sense to me, it's now also inconsistent with it's primary use (the D-Bus property). Still...
2022-01-04 18:28:46 +01:00
nm_clear_g_free(&priv->static_hostname);
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
G_OBJECT_CLASS(nm_hostname_manager_parent_class)->dispose(object);
}
static void
nm_hostname_manager_class_init(NMHostnameManagerClass *class)
{
GObjectClass *object_class = G_OBJECT_CLASS(class);
object_class->constructed = constructed;
object_class->get_property = get_property;
object_class->dispose = dispose;
core: rename related things explicitly to "static-hostname" We have at least static and transient hostnames. Let's be clear which one we are talking about. Note that also NM_SETTINGS_HOSTNAME gets renamed to NM_SETTINGS_STATIC_HOSTNAME, because it seems clearer. The only purpose of NM_SETTINGS_STATIC_HOSTNAME is to be the backing property for the "Hostname" D-Bus property for the NMDBusObject glue. So, while the new name makes more sense to me, it's now also inconsistent with it's primary use (the D-Bus property). Still...
2022-01-04 18:28:46 +01:00
obj_properties[PROP_STATIC_HOSTNAME] =
g_param_spec_string(NM_HOSTNAME_MANAGER_STATIC_HOSTNAME,
"",
"",
NULL,
G_PARAM_READABLE | G_PARAM_STATIC_STRINGS);
hostname: split out hostname management from NMSettings Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
2017-04-23 00:40:46 +02:00
g_object_class_install_properties(object_class, _PROPERTY_ENUMS_LAST, obj_properties);
}
Reference in a new issue Copy permalink