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
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.
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>
Rather than explicitly passing around a UID and a flag saying whether
or not it's relevant.
(This also fixes a bug where the wrong UID was being recorded in
nm-settings-connection.c::auth_start(), which caused problems such as
agent-owned secrets not getting saved because of a perceived UID
mismatch.)
If the connection describes a bridge/bond/team/etc slave, where the
slave setting (like NMSettingBridgePort or NMSettingTeamPort) has all
default values, the setting does not get written out because the
plugin does not write default values. But then when reading the
connection back in, we need to add that all-default slave type setting
since it's required for a valid connection.
Zero values are actually valid values for various bridge options
and should be written out. Otherwise, when reading the property
back in, it gets assigned the default value which is often not
zero, causing the wrong value to be set in the connection.
Only properties with default values should not be written out.
These are (most likely) only warnings and not severe bugs.
Some of these changes are mostly made to get a clean run of
Coverity without any warnings.
Error found by running Coverity scan
https://bugzilla.redhat.com/show_bug.cgi?id=1025894
Co-Authored-By: Jiří Klimeš <jklimes@redhat.com>
Signed-off-by: Thomas Haller <thaller@redhat.com>
If the connection has never been saved to disk, it won't have a path yet,
but that doesn't mean we should crash. Next, when reloading connections,
only try to do connection matching on connections that have paths, otherwise
all in-memory-only connections would be removed at the end of
read_connections().
Doing so may cause NetworkManager to run into an very intensive loop in
svUnescape() in shvar.c.
This is 'top' output for very long (invalid team config) - 9309865 bytes long:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
26855 root 20 0 305m 35m 6092 R 99.8 0.9 8:08.11 NetworkManager
and still not finished.
If the connection has never been saved to disk, it won't have a path yet,
but that doesn't mean we should crash. Next, when reloading connections,
only try to do connection matching on connections that have paths, otherwise
all in-memory-only connections would be removed at the end of
read_connections().
In Fedora, OVS ports are now identified in ifcfg files as
"TYPE=OVSPort", which NM doesn't recognize, and so it would ignore
those ifcfg files. Unfortunately, this meant that if auto-default
wasn't disabled, and there was no other configuration defined for the
device, then NM would create an NMDefaultWiredConnection for it and
screw things up.
So, add an "unrecognized-specs" settings plugin property, which allows
a plugin to indicate to NetworkManager that it knows of some
non-NetworkManager-supported connection defined for a device. This
will suppress default-wired connection creation for that device,
similar to the "no-auto-default" config file option, but determined by
the plugin instead of by manual configuration. Devices listed in
unrecognized-specs may still be managed by NetworkManager, unless they
are also listed in unmanaged-specs.
https://bugzilla.redhat.com/show_bug.cgi?id=1022256
Rather than having each connection-parsing function do its own
unmanaged-spec handling, just do it all directly from
connection_from_file(), and don't bother trying to fully parse the
file if it is unmanaged, since it won't ever be seen outside of the
plugin in that case anyway.
This also makes it possible to have an ifcfg file of an unrecognized
type be unmanaged.
We were accidentally removing the connection from priv->connections
(and thus from unmanaged-specs) when NM_CONTROLLED changed to no when
rereading a changed connection file.
If an ifcfg file changed from one non-NULL unmanaged-spec to another
(eg, if it previously had an interface-name: unmanaged-spec, and then
you add a HWADDR line, switching it to a mac: unmanaged-spec), we were
not updating the connection's unmanaged property, or emitting
unmanaged-specs-changed.
Also, remove the notify::unmanaged handler, since only plugin.c ever
changes an existing NMIfcfgConnection's unmanaged property, and it
always emits the signal itself afterward (and it needs to manually
emit the signal in other cases anyway, like when a connection is
removed).
Testcase:
* add 'NM_CONTROLLED=no' to /etc/sysconfig/network-scripts/ifcfg-ABC
* sudo nmcli con reload
* ... NM asserts ...
We need to ref() 'existing' connection before nm_settings_connection_signal_remove(),
because the function unref()s ithe connection via connection_removed_cb().
Backtrace:
...
#4 0x00007fbcf0ea0cba in g_assertion_message_expr (domain=domain@entry=0x0,
file=file@entry=0x7fbcf4e5805d "nm-dbus-manager.c", line=line@entry=848,
func=func@entry=0x7fbcf4e585e0 <__FUNCTION__.15088> "nm_dbus_manager_unregister_object", expr=expr@entry=0x7fbcf4e5820b "G_IS_OBJECT (object)")
at gtestutils.c:2293
#5 0x00007fbcf4de69d9 in nm_dbus_manager_unregister_object (
self=0x7fbcf6fdc9c0, object=0x7fbcf70235c0) at nm-dbus-manager.c:848
#6 0x00007fbcf4dd6a23 in nm_settings_connection_signal_remove (
self=<optimized out>) at settings/nm-settings-connection.c:1541
#7 0x00007fbce6fee884 in connection_new_or_changed (
self=self@entry=0x7fbcf7006f80,
path=path@entry=0x7fbcf70c3f80 "/etc/sysconfig/network-scripts/ifcfg-ABC",
existing=existing@entry=0x7fbcf70235c0,
out_old_path=out_old_path@entry=0x7fff2b7b8988) at plugin.c:327
#8 0x00007fbce6feeca2 in read_connections (plugin=0x7fbcf7006f80)
at plugin.c:453
#9 0x00007fbcf4dd8e98 in impl_settings_reload_connections (
self=0x7fbcf6fd98c0, context=0x7fbcf70bcb30) at settings/nm-settings.c:1262
...
Support new bonding options and set them carefully. The options cannot
be set arbitrarily because they interfere with each other.
This commit is forward-ported from rhel-6.5, see patch
rh901662-bond-more-options.patch, originally written by Dan Williams.
https://bugzilla.redhat.com/show_bug.cgi?id=901662https://bugzilla.redhat.com/show_bug.cgi?id=905532
Co-Authored-By: Dan Williams <dcbw@redhat.com>
Signed-off-by: Thomas Haller <thaller@redhat.com>
Static IP addresses were only read from ifcfg-* file when IP method was
'manual' (BOOTPROTO=none|static). This was to match the legacy initscripts
behaviour. However, NetworkManager supports using additional static IPs in
addition to automatically obtained (DHCP, etc.) addresses. So we now read
static IPs even for automatic methods to be able to use this feature.
https://bugzilla.redhat.com/show_bug.cgi?id=998135
When freeing one of the collections such as GArray, GPtrArray, GSList,
etc. it is common that the items inside the connections must be
freed/unrefed too.
The previous code often iterated over the collection first with
e.g. g_ptr_array_foreach and passing e.g. g_free as GFunc argument.
For one, this has the problem, that g_free has a different signature
GDestroyNotify then the expected GFunc. Moreover, this can be
simplified either by setting a clear function
(g_ptr_array_set_clear_func) or by passing the destroy function to the
free function (g_slist_free_full).
Signed-off-by: Thomas Haller <thaller@redhat.com>
ifcfg-rh had the rule that if an ifcfg file had no BOOTPROTO and no
IPv4 addresses, then it should be treated as method=auto for
compatibility. But in fact, current ifup treats it as method=disabled,
so we should too.
https://bugzilla.gnome.org/show_bug.cgi?id=708875
Make sure that all connections returned from NMSettings or created via
AddAndActivateConnection have an NMSettingIP4Config and an
NMSettingIP6Config, with non-NULL methods, and get rid of
now-unnecessary checks for those.
Also move the slaves-can't-have-IP-config checks into the
platform-independent code as well. This also gets rid of spurious
"ignoring IP4/IP6 configuration" warnings in ifcfg-rh when reading a
slave ifcfg file.
Partly based on a patch from Pavel.
https://bugzilla.gnome.org/show_bug.cgi?id=708875
connection_from_file() requires the 'error' parameter. Not passing a
valid 'error' parameter causes the function to fail and return NULL,
which mean that commit_changes() would always re-write the connection
instead of ignoring commits where nothing has actually changed.
connection_from_file() no longer requires the unmanaged, keyfile,
or routefile parameters, so remove them.
The problem is that there is only a single variable in ifcfg file holding dns
domains - DOMAIN. Thus NetworkManager writes both IPv4 and IPv6 dns-search into
it. While reading there is no way to distinguish between IPv4 and IPv6 values,
so the DOMAIN value is read and only put into IPv4 dns-search.
But, when IPv4 is disabled or invalid, the domains got lost. So in such case
we put DOMAIN variable into IPv6 instead.
https://bugzilla.redhat.com/show_bug.cgi?id=1004866
