When assuming the connections on restart we want to prefer more-recently-used
connections. That's why we have to sort connections according to timestamps in
descending order. That means connections used more recently (higher timestamp)
go before connections with lower timestamp.
https://bugzilla.redhat.com/show_bug.cgi?id=1067712
Rebasing the shvar changes to master added some new instances of
svNewFile() and svWriteFile() (in the aliases code) that needed to be
updated for the API changes.
shvar.c was assuming it could do a single read() to read in the ifcfg
file, without taking partial reads or EINTR into account. Fix that.
Also, it was keeping the raw contents of the ifcfg file in the
shvarFile even though it never looked at it after svOpenFile().
(Presumably lineList originally consisted of pointers into arena, but
that had to be changed to support readwrite.) Fix that.
It would simplify things further to use g_file_get_contents() and
g_file_set_contents(), but the current code is perhaps more resilient
to symlink attacks because it keeps the fd open?
Fix a bug when reading an invalid alias file, where the code meant to
skip the rest of the loop iteration, but failed.
Also fix a memory leak and remove an unused variable.
Bugs noticed by coverity.
Notes and changes by jklimes:
- fix reading TeamPort without TYPE=Ethernet
- fix tests
Ideally this should be solved on initscripts side. But teamd doesn't want to do
any changes to initscripts, so we make a workaround here.
https://bugzilla.redhat.com/show_bug.cgi?id=1074160
connection_parser.c: In function 'make_ip4_setting':
connection_parser.c:660:33: error: 'method' may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (!is_static_block && strstr (method, "dhcp")) {
connections.c: In function ‘load_cmd_line_edit_lib’:
connections.c:5744:17: error: ‘module’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
g_module_close (module);
Signed-off-by: Thomas Haller <thaller@redhat.com>
reader.c: In function 'parse_infiniband_p_key':
reader.c:3947:5: error: 'id' may be used uninitialized in this function [-Werror=maybe-uninitialized]
id = (id | 0x8000);
^
Signed-off-by: Thomas Haller <thaller@redhat.com>
When config is NULL libteam will use its own default configuration.
Commit 76c3bd9898 changed that and refused to
create 'team' setting making connection invalid. It didn't set an error as
well, which resulted in
ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-team ...
ifcfg-rh: error: (unknown)
GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
Add versioned NM_DEPRECATED_IN_* and NM_AVAILABLE_IN_* macros, and tag
new/deprecated functions accordingly. (All currently-deprecated
functions are assumed to have been deprecated in 0.9.10.)
Add NM_VERSION_MIN_REQUIRED and NM_VERSION_MAX_ALLOWED macros which
can be set to determine which versions will cause warnings.
With the current settings, external consumers of the
libnm-util/libnm-glib APIs will have MIN_REQUIRED and MAX_ALLOWED both
set to NM_VERSION_0_9_8 by default, meaning they will get warnings
about functions added in 0.9.10. NM internally sets
NM_VERSION_MAX_ALLOWED to NM_VERSION_NEXT_STABLE to ensure that it is
always allowed to use all APIs.
4f3a9cca6f stopped unescaping Team
configuration when reading ifcfg files due to inefficient algorithms
in svUnescape(). Unfortunately, since Team configuration is escaped
when written out, reading it in creates invalid configuration that
teamd rejects.
The pathological case was a 9MB invalid Team configuration. Since a
Team configuration will never, ever be that large, fix the issue by
warning the user or rejecting the configuration if it is over 20000
bytes in size (an arbitrary number). Thus svUnescape() will never
be called with huge strings, but the configuration is still unescaped.
https://bugzilla.redhat.com/show_bug.cgi?id=1051517
While this function only returns the path of the requested connection
(the actual settings are always protected), callers that aren't in
the connection's ACL still probably shouldn't get that, if only to
be pedantic.
Virtual devices may be created and destroyed, but we need to keep
their autoconnect state across that. Previously this was handled by
NMManager, but it really belongs with the other autoconnect tracking
in NMPolicy and NMSettingsConnection.
This also fixes a bug where NMPolicy would sometimes decide to
autoactivate a virtual device connection which NMManager would then
have to cancel.
NMSettings (and NMConnectionProvider) had a signal to indicate when it
had loaded the connections, but in reality this always happened before
nm_settings_new() returned (as a side effect of calling
unmanaged_specs_changed()) and so no one else would ever actually see
the signal. So just kill it.
Now UPDATED_BY_USER signal gets emitted immediately after the connection
is updated, rather then only after it is successfully saved.
This means, that the signal will be emitted earlier then before (right
after changing the connection, but before it gets commited).
Furthermore, the signal will also be emitted for connections that
get changed but are not to be saved.
Currently, the only subscriber to this signal is NMSettings
(default_wired_connection_updated_by_user_cb), which should be fine with
this change of semantics (even better).
https://bugzilla.redhat.com/show_bug.cgi?id=1040528
Signed-off-by: Thomas Haller <thaller@redhat.com>
Move DHCP_SEND_HOSTNAME parsing out of the check for DHCP_HOSTNAME so that
users can disable NM sending the system hostname to the DHCP server when
DHCP_HOSTNAME is not defined.
NMAgentManager was supposed to be trying multiple secret agents on any
error except UserCanceled, but due to a botched last-minute rewrite,
it was actually doing the reverse.
It is an extension compared to initscripts (not in sysconfig.txt). But it is
necessary for preserving dhcp-send-hostname. Missing DHCP_SEND_HOSTNAME is
treated as "yes", which matches dhcp-send-hostname default value being TRUE.
https://bugzilla.redhat.com/show_bug.cgi?id=1001529
Keyfile plugin writer had a bug, when writing IP6 routes with gateway
"::". Instead of writing "net/plen,,metric" it wrote "net/plen,metric".
- fix this bug and add test cases. Also, add a workaround to reader, to
accept such wrongly written IP6 routes as valid.
- change the writer for IP4 addresses, IP4 routes and IP6 routes to
omit the gateway and the metric, if it is 0.0.0.0/::/0, respectively.
Also change the reader, to accept such empty gateway as valid.
It only omits the gateway, if the metric is not 0, this means it would
write:
route1=1.2.3.4/24,0.0.0.0,1
instead of
route1=1.2.3.4/24,,1
Both representations are now supported by the reader, but older plugin
versions could only read the former (thus, we keep writing that
version).
With a metric of zero, it would instead write:
route1=1.2.3.4/24
- some refactoring and code cleanup. Fix a memory leak.
https://bugzilla.gnome.org/show_bug.cgi?id=719851
Signed-off-by: Thomas Haller <thaller@redhat.com>
When generating a connection, if the device has no non-link-local IPv6
address, then it's unclear whether (a) the connection was link-local
originally, or (b) the connection was 'auto' but IPv6 failed or timed
out.
In this case, if there is a persistent connection that is 'auto' but
the generated connection is 'link-local', the persistent connection
should be used.
Add a more-testable framework for doing the connection matching to
handle this.
