When jansson lib version is < 2.8 the order of the keys of json objects
is not preserved automatically. In particular, when loading the json
string, parsing it and dumping it back to a string the key order will be
lost if the now deprecated JSON_PRESERVE_ORDER flag is not set.
Add the flag: will do nothing on recent jansson versions but will fix
behavior for legacy ones.
(cherry picked from commit 5e6f7de4be)
Add functions and structure to simplify json config and team property
enforcement. These will be used in both NMSettingTeam and
NMSettingTeamPort.
(cherry picked from commit b4c9bcd49f)
DNS searches from the ipv4 and ipv6 settings were joined and written
to the same ifcfg-rh "DOMAIN" variable and so the connection read back
from disk was different from the one written.
Instead, introduce a separate variable for ipv6 searches; to preserve
backwards compatibility, still read the "DOMAIN" variable for ipv6
when ipv4 is disabled so that we don't lose DNS searches on upgrade.
https://bugzilla.redhat.com/show_bug.cgi?id=1517794
(cherry picked from commit a9b5079324)
This is now required as we instance inotify-helper only on need:
we have to init them to the unset value, otherwise...
Thread 1 "NetworkManager" received signal SIGSEGV, Segmentation fault.
nm_inotify_helper_remove_watch (self=0x0, wd=0) at src/settings/plugins/ifcfg-rh/nm-inotify-helper.c:100
100 if (priv->ifd < 0)
(gdb) backtrace
#0 0x00007fffe35da6c0 in nm_inotify_helper_remove_watch (self=0x0, wd=0) at src/settings/plugins/ifcfg-rh/nm-inotify-helper.c:100
#1 0x00007fffe35d45b1 in nm_inotify_helper_clear_watch (wd=0x7fffdc008628, helper=<optimized out>) at src/settings/plugins/ifcfg-rh/nm-inotify-helper.h:53
#2 0x00007fffe35d45b1 in path_watch_stop (self=0x7fffdc0085f0) at src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-connection.c:223
#3 0x00007fffe35d467c in filename_changed (object=0x7fffdc0085f0, pspec=<optimized out>, user_data=<optimized out>) at src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-connection.c:242
#4 0x00007ffff61b230d in g_closure_invoke () at /lib64/libgobject-2.0.so.0
#5 0x00007ffff61c498e in signal_emit_unlocked_R () at /lib64/libgobject-2.0.so.0
#6 0x00007ffff61cd1a5 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#7 0x00007ffff61cdb0f in g_signal_emit () at /lib64/libgobject-2.0.so.0
#8 0x00007ffff61b6594 in g_object_dispatch_properties_changed () at /lib64/libgobject-2.0.so.0
#9 0x00007ffff61b5f3e in g_object_notify_queue_thaw () at /lib64/libgobject-2.0.so.0
#10 0x00007ffff61b7776 in g_object_new_internal () at /lib64/libgobject-2.0.so.0
#11 0x00007ffff61b924d in g_object_new_valist () at /lib64/libgobject-2.0.so.0
#12 0x00007ffff61b9691 in g_object_new () at /lib64/libgobject-2.0.so.0
#13 0x00007fffe35d5018 in nm_ifcfg_connection_new (source=source@entry=0x0, full_path=full_path@entry=0x555555a9a590 "/etc/sysconfig/network-scripts/ifcfg-team3", error=error@entry=0x7fffffffdc30, out_ignore_error=out_ignore_error@entry=0x7fffffffdc2c) at src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-connection.c:429
#14 0x00007fffe35d5e96 in update_connection (self=self@entry=0x555555a59ea0, source=source@entry=0x0, full_path=0x555555a9a590 "/etc/sysconfig/network-scripts/ifcfg-team3", connection=connection@entry=0x0, protect_existing_connection=protect_existing_connection@entry=0, protected_connections=protected_connections@entry=Python Exception <class 'gdb.error'> There is no member named keys.:
0x555555a9fc00, error=0x0) at src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-plugin.c:218
#15 0x00007fffe35d7073 in read_connections (plugin=plugin@entry=0x555555a59ea0) at src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-plugin.c:545
#16 0x00007fffe35d72f1 in get_connections (config=0x555555a59ea0) at src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-plugin.c:581
#17 0x00005555556bb513 in load_connections (self=0x555555a1a920) at src/settings/nm-settings.c:239
#18 0x00005555556bb513 in nm_settings_start (self=0x555555a1a920, error=<optimized out>) at src/settings/nm-settings.c:1800
#19 0x00005555555ada1f in nm_manager_start (self=0x555555a490c0, error=<optimized out>) at src/nm-manager.c:5262
#20 0x00005555555851ae in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:417
Fixes: 31f2a46639
(cherry picked from commit 993a726c4a)
When building with assertions, they nm_assert() for the
type. Otherwise, they are identical to a C cast.
Also, where possible, don't cast at all, but adjust
the type instead.
Also, there were a few missing casts.
(cherry picked from commit 7661ad64ba)
Extend the Update2 flags to allow marking a connection as volatile.
Making a connection as volatile means that the connection stays alive
as long as an active connection references it.
It is correct that Update2() returns before the connection is actually
deleted. It might take an arbitrary long time until the volatile
mechanism cleans up the connection.
Also add two more IN_MEMORY flags: "detached" and "only".
The existing NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY would not detach nor
delete the possible file on disk. That is, the mode only changes what NM
thinks is the current content of the connection profile. It would not delete
the file on disk nor would it detach the profile in-memory from the file.
As such, later persisting the connection again to disk would overwrite
the file, and deleting the profile, would delete the file.
Now add two new IN_MEMORY modes.
NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_DETACH is like making the connection
in-memory only, but forgetting that there might be any profile on disk.
That means, a later Delete() would not delete the file. Similarly, a
later Update2() that persists the connection again, would not overwrite
the existing file on disk, instead it would choose a new file name.
On the other hand, NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_ONLY would delete
a potential file from disk right away.
It's clear that "volatile" only makes sense with either "in-memory-detached"
or "in-memory-only". That is, the file on disk should be deleted right away
(before the in-memory part is garbage collected) or the file on disk should
be forgotten.
(cherry picked from commit 35dc6421de)
Previously, we would only set a connection as volatile before
adding it to manager. As we never would set it volatile last on,
there was no need to handle deletion.
Now support that. Watch the volatile flag, and if the connection
has currently not active connection that keeps it alive, delete
it in an idle handler.
(cherry picked from commit cfced599ca)
First, define structs. Then forward declare functions. Reorder code
to have a certain order that is also used by other files (or should
be).
(cherry picked from commit 4c84f74326)
Previously, NMPolicy would explicitly check whether the connection is not visible,
to skip autoconnect.
We have nm_settings_connection_autoconnect_is_blocked() function, that can do that.
The advantage is, that at various places we call nm_settings_connection_autoconnect_is_blocked()
to determine whether autoconnect is blocked. By declaring invisible connections
as blocked from autoconnect as well, we short-cut various autoconnection attempts,
that previoulsy only failed later during auto_activate_device().
(cherry picked from commit ccc93639a0)
The accessor functions just look whether a certain flag is set. As these
functions have a different name then the flags, this is more confusing
then helpful. For example, if you want to know where the NM_GENERATED
flag matters, you had to know to grep for nm_settings_connection_get_nm_generated()
in addition to NM_SETTINGS_CONNECTION_FLAGS_NM_GENERATED.
The accessor function hid that the property was implemented as
a connection flag. For example, it was not immediately obvious
that nm_settings_connection_get_nm_generated() is the same
as having the NM_SETTINGS_CONNECTION_FLAGS_NM_GENERATED flag
set.
Drop them.
(cherry picked from commit 545e3111c8)
It seems more idiomatic to have a mask+value argument, instead
of setting all flags at once. At least, other setters work this
way, so change it for consistency.
(cherry picked from commit 4549bd07a1)
We already need to re-emit the notify::flags signal.
It's cumbersome to do this for boolean properties, so
re-use the flags to also track the visibility state.
(cherry picked from commit 0e1abe5ef3)
It doesn't really matter, because in the next step we
are about to remove the connection.
However, once the connection is deleted from file, it's
clear that it has no more file-name.
(cherry picked from commit 1fd5c52eaf)
Commonly, we don't monitor files and hence don't need the inotify-helper
instance. We already access and construct the instance lazy, by
accessing the singleton getter only when needed.
However, path_watch_stop() would always access the singleton, hence
always create such an instance. In most cases there is nothing to clean,
and no such instance shall be created.
(cherry picked from commit 31f2a46639)
ifnet shall use the new_connection argument, not NM_CONNECTION(self).
Also, let the caller of the virtual function provide the right new_connection,
not having the virtual function figure that out.
(cherry picked from commit 8a675f3d13)
The example script touches the stable-id of a connection.
It does so blocking autoconnect, and was originally written
to test that functionality.
(cherry picked from commit 8388f4ea1d)
- only add an async version. I think sync requests are fundamentally flawed
because they mess up the order of D-Bus messages. Hence, also don't
call the function *_async(), like we do for other functions. As there
is only the async form, it doesn't have a suffix.
- Don't accept a NMConnection as @settings argument, but a GVariant.
In general, keep the libnm API closer to the D-Bus API and don't hide
the underlying function with a less powerful form. The user still can
conveniently call the function with
nm_remote_connection_update2 (connection,
nm_connection_to_dbus (NM_CONNECTION (connection),
NM_CONNECTION_SERIALIZE_ALL),
save_to_disk
? NM_SETTINGS_UPDATE2_FLAG_TO_DISK
: NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY,
NULL,
cancellable,
callback,
user_data);
I believe the parts of libnm that invoke D-Bus methods, should be
close to the D-Bus API. Not like nm_remote_connection_commit_changes()
which has no corresponding D-Bus method.
(cherry picked from commit d00eb95c55)
We already have Update(), UpdateUnsaved() and Save(), which serve
similar purposes. We will need a form of update with another argument.
Most notably, to block autoconnect while doing the update.
Other use cases could be to prevent reapplying connection.zone and
connection.metered, to to reapply all changes.
Instead of adding a specific update function that only serves that
new use-case, add a extensible Update2() function. It can be extended
to cope with future variants of update.
(cherry picked from commit 98ee18d888)
commit involves more then just replacing the setting and writing them
out. What? Dunno. It's complex.
But let's not bypass the commit-changes function. That one is supposed
to get it right.
(cherry picked from commit d26c749ea6)
It's complicated what happens during a commit/replace/update (whatever
you call it).
It doesn't get simpler by spreading it out to various functions.
Let's have one large function (_commit_changes_full()) which does
all the steps necessary. There should be no alternative ways
how to update a connection.
(cherry picked from commit ad9deb6968)
All callers of _replace_settings_full() now use _commit_changes_full().
commit-changes should contain all the logic what to do when updating
a connection. Now, the connection might optionally be written to disk.
(cherry picked from commit 7a0900be7c)
