Move call to nm_main_utils_early_setup() to a separate function.
Also move the @options array away from the main function, saving
a few bytes on the stack.
Now only do_early_setup() modifies the @global_opt structure.
(cherry picked from commit 5775df9a6d)
(cherry picked from commit 8e58fc7425)
Conflicts:
src/main.c
src/nm-iface-helper.c
Move the variables to a static struct so that we can factor
out some of the initialization code.
Also it's nice to have all options placed together in one struct so
that is is obvious which static variables are part of the command line
options, and which have other use.
(cherry picked from commit 1fc5aba42a)
Conflicts:
src/nm-iface-helper.c
Configuration commit is an unsafe thing to do for assumed connections,
it can remove an externally added address we don't know about yet.
The device already has a link-local address; for an assumed connection
it's the reason we assumed the method=link-local in the first place.
(cherry picked from commit 396dc2b3b4)
Paths to sysctls don't use ifindex and device names can be reused. If someone
removes a device and quickly creates a device with the same name, chances are
we're cleaning up the device that was just added.
Sadly, it seems there's no better API than sysctl-- neither netlink nor procfs
symlinks with ifindex or anything like that.
(cherry picked from commit f85513b8e4)
There won't be any further requests, so there's no point in keeping
the connection alive. Even if the HTTP server doesn't care, proxy
servers in-between might keep the connection open for a couple seconds
for keepalive, and we might as well be nice to them and tell them we
don't need to keep it alive.
(cherry picked from commit 90692e3eff)
We don't need the bus for the tests and the manager may warn when it
is not available.
$ (cd src/tests/config/; env -i DBUS_SYSTEM_BUS_ADDRESS=meow ./test-config)
/config/parse-error: OK
/config/no-auto-default: NetworkManager-Message: <info> Could not connect to the system bus; only the private D-Bus socket will be available.
/bin/sh: line 5: 29997 Trace/breakpoint trap ${dir}$tst
FAIL: test-config
This reverts commit 6994454461 for the
most part. It's not sufficient to disable logging warnings. Creating
a DBus Manager might affect the system in undesired ways.
(cherry picked from commit 5040a8a851)
The class itself is not thread-safe, so no need for guarding
the creation with g_once_init_*().
Also, assert against multiple creation and log a line when
creating the singleton. The getter is now more similar to what
is created by NM_DEFINE_SINGLETON_GETTER().
(cherry picked from commit 99465a34ca)
Don't have the singleton instance of NMDBusManager owned by
the main function. Instead use NM_DEFINE_SINGLETON_DESTRUCTOR()
which also logs what's happening.
(cherry picked from commit 1208c0dd13)
Conflicts:
src/main.c
Otherwise the compiler complains that they could be left uninitialized in case
the function returns too early.
Fixes: 76745817c3
(cherry picked from commit 2981839bde)
NMTestDevice does not invoke dispose(), hence it leaks memory which causes
false warnings in testing.
Some minor refactring to let dispose() clear the fields, but free it
later in finalize(). This avoids memleaks in the NMTestDevice stub.
(cherry picked from commit a82d94a64e)
==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==
(cherry picked from commit fcfd8f487a)
These functions will sometimes get called on updates to the device's IP
config due to external changes, or when addresses get flushed from the
device when activating it. If the device is a slave device, then at
this point its NMConnection won't have an IP settings. Suppress the
warning that gets printed when s_ip == NULL, because it's expected.
(cherry picked from commit d2de83e0f7)
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.
(cherry picked from commit 236226a590)
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
(cherry picked from commit 0c6349c627)
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.
(cherry picked from commit 0cf00ff3aa)
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.
(cherry picked from commit a609dd12d3)
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
(cherry picked from commit 7b807b11cc)
When writing a file (for example with `sed -i`) a temporary file
might be created and removed quickly. This causes spurious events
in dir_changed().
(cherry picked from commit 8ba8a55cfa)
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().
(cherry picked from commit db5c4ce64f)
Log lines with a "keyfile:" prefix and show more information about
the loaded connection. Especially printing the UUID is interesting.
(cherry picked from commit 5c2fa92099)
