| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Custom IP ranges for shared connection were implemeted in bgo #6759732
(commit 32a001f526c182fa70ede92ffc360112eb7fe9c6). 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
|
|
|
|
|
|
|
| |
Set the MTU if 802-3-ethernet.mtu is present and non-zero. The ifcfg-rh writer
sets it if there's a MTU key.
https://bugzilla.redhat.com/show_bug.cgi?id=1177582
|
|\
| |
| |
| | |
https://bugzilla.redhat.com/show_bug.cgi?id=1171751
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
monitoring is not enabled
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
|
| |
| |
| |
| |
| |
| | |
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().
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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().
|
| |
| |
| |
| |
| | |
Log lines with a "keyfile:" prefix and show more information about
the loaded connection. Especially printing the UUID is interesting.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| | |
nm_settings_connection_replace_settings()
nm_settings_connection_replace_settings() does nothing, if there are no changes.
|
| |
| |
| |
| | |
nm_settings_connection_replace_settings()
|
| | |
|
|/
|
|
|
| |
Avoids for example:
notify(): ignoring notification for prop visible on type NMKeyfileConnection
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
conn_name can be NULL now as the connections are tracked by UUID
(see commit 689dadaffbe0ba6f078a0bf3b8d5106788c289eb)
Sep 29 21:20:34 Jdeapad NetworkManager[1339]: <info> getting unmanaged specs...
Sep 29 21:20:34 Jdeapad NetworkManager[1339]: <info> Checking unmanaged: (null)
Sep 29 21:20:38 Jdeapad kernel: NetworkManager[1339]: segfault at 0 ip
00007f1bfffbedd0 sp 00007fff98daa628 error 4 in
libglib-2.0.so.0.4002.0[7f1bfff86000+130000]
https://bugzilla.gnome.org/show_bug.cgi?id=737645
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
Bonding mode can be provided either as descriptive name of a numeric value
(on D-Bus and ifcfg-rh too).
https://bugzilla.gnome.org/show_bug.cgi?id=704666
https://bugzilla.redhat.com/show_bug.cgi?id=1133544
https://bugzilla.redhat.com/show_bug.cgi?id=1171009
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Use descriptive string value as preferred bond mode representation.
Numeric modes still verify but with NM_SETTING_VERIFY_NORMALIZABLE,
suggesting a normalization action.
https://bugzilla.redhat.com/show_bug.cgi?id=1171009
|
| |
| |
| |
| |
| | |
https://bugzilla.gnome.org/show_bug.cgi?id=704666
https://bugzilla.redhat.com/show_bug.cgi?id=1133544
|
|/ |
|
|\
| |
| |
| | |
https://bugzilla.gnome.org/show_bug.cgi?id=741871
|
| |
| |
| |
| |
| |
| |
| | |
refresh_object() raised a spurious change event for the route we
are about to delete. Suppress that by adding an internal reason flag.
Fixes: 41e6c4fac1890e4302e4bfd1aa21be362cce51f2
|
| | |
|
| | |
|
| | |
|
|/ |
|
|
|
|
|
|
| |
It fails doesn't propagate EAGAIN properly. Fixed in 3.2.22's 375a629.
https://bugzilla.redhat.com/show_bug.cgi?id=1180773
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
enabled (rh #1162636) (bgo #742675)
On resume configured interfaces are unmanaged to clear their pre-resume
state and then re-managed. Eventually the interface should end up moving
to the DISCONNECTED state, which should trigger an auto-activate check in
the Policy. If connectivity checking was enabled, that auto-activate check
would fail because the Manager's state was still NM_STATE_ASLEEP.
This caused bridge slaves not to auto-activate on resume, which left bridges
without connectivity.
The manager never left NM_STATE_ASLEEP when connectivity checking was
enabled due to nm_manager_update_state() returning early when kicking
off a connectivity check. Instead, the manager's state should always
be updated to accurately reflect the current state.
https://bugzilla.redhat.com/show_bug.cgi?id=1162636
https://bugzilla.gnome.org/show_bug.cgi?id=742675
|
|
|
|
| |
Fixes: 24a464a7da9d5c66a14e503d7f753f0e249e358b
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| | |
If a connection has an associated "rule-NAME" or "rule6-NAME" file,
don't try to read in the routes, since NetworkManager won't be able to
parse them correctly. Instead, log a warning that they will need to be
applied via a dispatcher script, and provide a script that would do
that in examples/dispatcher/.
|
| | |
|
| | |
|
|/
|
|
|
|
|
| |
Add a "filename" property to NMSettingsConnection, and set it from
keyfile and ifcfg-rh (replacing the existing priv->path variables in
those connection types). (The other plugins either don't use files, or
don't use per-connection files.)
|
|
|
|
|
|
|
| |
Try harder to find a suitable filename by appending a counter
to the name.
https://bugzilla.gnome.org/show_bug.cgi?id=740738
|
|\
| |
| |
| | |
https://bugzilla.gnome.org/show_bug.cgi?id=742450
|
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Also move the initilization of the instance into the constructed()
method.
NMAgentManager now owns a reference to the DBUS manager and Auth
manager and the dispose() function properly unregisters itself from
both.
|
| | |
|