There are three configuration options that contain device specs:
'main.ignore-carrier', 'main.no-auto-default', and
'keyfile.unmanaged-devices'.
Unify the parsing of them by splitting the device spec with
nm_match_spec_split(). This changes behavior for parsing of these
properties.
Also get rid of logging warnings when parsing 'keyfile.unmanaged-devices'.
We have nm_keyfile_plugin_utils_should_ignore_file() to ignore certain
files based on patterns. We also need a matching escape function to
avoid saving connections with a name we would ignore later.
https://bugzilla.gnome.org/show_bug.cgi?id=735824
After refactoring libnm-core to use GBytes instead of
GByteArray/DBUS_TYPE_G_UCHAR_ARRAY, it was forgotten to update
keyfile writer.
This causes keyfile writer to skip the NMSetting8021x:password-raw setting
and raise a g_critical() warning.
Fixes: c43f88907b
==29353== 620 (+620) (32 (+32) direct, 588 (+588) indirect) bytes in 1 (+1) blocks are definitely lost in loss record 6,905 of 7,076
==29353== at 0x7CDBAC8: g_type_create_instance (gtype.c:1844)
==29353== by 0x7CBF356: g_object_new_internal (gobject.c:1774)
==29353== by 0x7CC0D4C: g_object_newv (gobject.c:1922)
==29353== by 0x7CC14E3: g_object_new (gobject.c:1614)
==29353== by 0x50B58A: nm_secret_agent_new (nm-secret-agent.c:489)
==29353== by 0x50915F: impl_agent_manager_register_with_capabilities (nm-agent-manager.c:309)
==29353== by 0x62649BE: invoke_object_method (dbus-gobject.c:1899)
==29353== by 0x62649BE: object_registration_message (dbus-gobject.c:2161)
==29353== by 0x649D5CE: _dbus_object_tree_dispatch_and_unlock (dbus-object-tree.c:1018)
==29353== by 0x648F193: dbus_connection_dispatch (dbus-connection.c:4718)
==29353== by 0x6261DB4: message_queue_dispatch (dbus-gmain.c:90)
==29353== by 0x7F44AEA: g_main_dispatch (gmain.c:3111)
==29353== by 0x7F44AEA: g_main_context_dispatch (gmain.c:3710)
==29353== by 0x7F44E87: g_main_context_iterate.isra.29 (gmain.c:3781)
==4203== 97 (+97) bytes in 2 (+2) blocks are definitely lost in loss record 4,586 of 5,632
==4203== at 0x4C29BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==4203== by 0x7F4A6F5: g_malloc (gmem.c:97)
==4203== by 0x7F6301E: g_strdup (gstrfuncs.c:356)
==4203== by 0x47E4C8: nm_settings_connection_set_filename (nm-settings-connection.c:2228)
==4203== by 0x7CBF6EC: object_set_property (gobject.c:1415)
==4203== by 0x7CBF6EC: g_object_new_internal (gobject.c:1828)
==4203== by 0x7CC1194: g_object_new_valist (gobject.c:2034)
==4203== by 0x7CC14D0: g_object_new (gobject.c:1617)
==4203== by 0x12A08193: nm_ifcfg_connection_new (nm-ifcfg-connection.c:229)
==4203== by 0x12A0542B: update_connection (plugin.c:225)
==4203== by 0x12A0696A: add_connection (plugin.c:715)
==4203== by 0x4814BB: nm_settings_add_connection (nm-settings.c:1030)
==4203== by 0x4817DE: pk_add_cb (nm-settings.c:1136)
Agent registration should not be blocked by absence of a user session
tracked using logind or consolekit. Access control based on UID is
sufficient.
This patch ensures that the user can always register a secret agent,
even if he doesn't have a session tracked by logind or consolekit and
even when NetworkManager is not built with logind or consolekit support.
Please note checking for presence or absence of a user session tracked
by logind has no value in this context.
Acked-By: Thomas Haller <thaller@redhat.com>
Acked-By: Dan Williams <dcbw@redhat.com>
==10501== 353 (32 direct, 321 indirect) bytes in 1 blocks are definitely lost in loss record 1,579 of 1,641
==10501== at 0x7EE3728: g_type_create_instance (gtype.c:1847)
==10501== by 0x7EC75B4: g_object_new_internal (gobject.c:1746)
==10501== by 0x7EC945C: g_object_newv (gobject.c:1890)
==10501== by 0x7EC9C23: g_object_new (gobject.c:1556)
==10501== by 0x1CD87C: nm_setting_wireless_security_new (nm-setting-wireless-security.c:122)
==10501== by 0x16F70B: make_wpa_setting (reader.c:3010)
==10501== by 0x16F33F: make_wireless_security_setting (reader.c:3188)
==10501== by 0x161F4C: wireless_connection_from_ifcfg (reader.c:3464)
==10501== by 0x16109A: connection_from_file_full (reader.c:4763)
==10501== by 0x1614EE: connection_from_file_test (reader.c:4862)
==10501== by 0x13D1D6: test_read_wifi_wpa_psk_unquoted2 (test-ifcfg-rh.c:4316)
==10501== by 0x1281FD: main (test-ifcfg-rh.c:12513)
==10501==
With this change, NMConfig is really immutable and all
modifyable parts migrated to NMConfigData.
Another advantage is that components can now subscribe to
NMConfig changes to pickup changes to no-auto-default.
In case of error, ibft prints an error message to stderr
with two trailing newlines. This causes multiple lines
in our logfile. Replace newlines in the error message
by whitespaces.
There's no point in calling setpgid() on short-lived processes, so
remove the setpgid() calls when spawning dispatcher scripts, iptables,
iscsiadmin, and netconf.
Replace the pthread_sigwait()-based signal handling with
g_unix_signal_add()-based handling, and get rid of all the
now-unnecessary calls to nm_unblock_posix_signals() when spawning
subprocesses.
As a bonus, this also fixes the "^C in gdb kills NM too" bug.
Custom IP ranges for shared connection were implemeted in bgo #6759732
(commit 32a001f526). The first IP address
is used and a range is calculated.
However, the commit missed to update ifcfg-rh plugin to read the address.
Test case:
* use ifcfg-rh plugin for NetworkManager
$ nmcli con add type eth con-name shared-ip ifname eth0
$ nmcli con mod shared-ip ipv4.addresses 9.8.7.6/24 ipv4.method shared
$ nmcli con show shared-ip
$ nmcli con show shared-ip <--- ip address 9.8.7.6 was missing
https://bugzilla.redhat.com/show_bug.cgi?id=1174632
This was not really an error, because NMIfcfgConnection would not
watch the files if monitoring is not enabled. Still do it, because
it feels more correct.
Make update_connection() analogous to keyfiles implementation.
Effectively merge _internal_new_connection() and update_connection()
-- previously connection_new_or_changed().
https://bugzilla.redhat.com/show_bug.cgi?id=1171751
Presort the files in read_connections() as we do it
for keyfile.
This alone has not much consequences. Do this patch first, to
keep the next patches more self-contained.
The ifcfg-rh implementation should be similar to the one from keyfile.
Rename the variables and function that have the same meaning.
Do this trivial commit first, before starting refactoring.
When adding a connection to NMSettings we did not check for
duplicate connection UUIDs (which could for example happen
if two different plugins report a conflicting UUID).
Also, we would not check that an already added connection
changes it's UUID.
Both could lead to have duplicate connections (by UUID).
Avoid that two ways:
- when adding a connection to NMSettings, ensure that we don't add
a conflicting UUID. Otherwise just bail out and do nothing.
- when modifying a connection that is already added to NMSettings,
enforce that the UUID cannot change. Otherwise fail with error.
For ifcfg-rh plugin this situation still can happen during reload.
In this case error out and refuse to update the connection. After
all, the user configured invalid UUIDs.
https://bugzilla.redhat.com/show_bug.cgi?id=1171751
Also during add_connection() we must take special care of not "adding" a
connection with a conflicting UUID. In that case we want to fallback to
"update".
update_connection() already does all the checks, so call
update_connection() from add_connection().
If there are keyfiles with duplicate UUIDs, read_connections()
would iterate over the files, loading them as they appear and
overwriting duplicate connections that were just loaded.
For example, have keyfiles 'A' and 'B' with the same UUID.
On start, NM might first load 'A', then 'B'. 'B' would replace the
content of 'A' which was just loaded.
On reload, NM would first overwrite 'B' with 'A', and then again
overwriting 'A' with 'B'.
Fix that by accept the first found connection and don't overwrite
it during the same read_connections() run.
Also sort the files by file modification timestamp so that we
get a reproducible and sensible behavior.
new_connection() and update_connection() are very similar as both
must anticipate collisions of UUIDs.
When reloading a connection (update_connection(), previously), the loaded
connection for a certain path might actually replace another existing
connection. In this case, the old connection must be removed, and
the existing one updated instead.
If reloading a connection changes the UUID to a new value, the old
connection must be removed likewise and a new connection added.
Merge both functions into update_connection().
Only log connection diffs when we update a connection that we actually
care about.
Note that most plugin specific connections use
nm_settings_connection_replace_settings() in their constructor
to initialize themselves. These occurrences are not interesting
and spam the logfile.
