AUTOCONNECT_SLAVES is an NetworkManager extension. initscripts always activate
slaves with the master connection for bond and team, and doesn't activate
automatically slaves for bridge.
NetworkManager behaviour is controlled by this variable. If the variable is
missing the default value from configuration file is used.
Previously, it would silently accept a value set to "empty".
This is however not a valid number and we should raise a
warning just like for any other invalid number.
Alias files have a ':' to separate the base name from their
alias. But we didn't always ensure not to write-out files without
colon, and also initscripts doesn't have that restriction.
We should detect alias files and handle them properly (e.g. by
reloading the base file).
This fixes an error that a `nmcli con load` would have tried to
load the alias file. Also extend load_connection() to support
passing filenames other then the base file.
We only have to handle this in plugin.c. Inside reader.c we always
have the normalized base filename.
Or detection of alias files only looks whether the filename has a ':'
and whether a corresponding base file exists.
Previously, if the main ifcfg file doesn't define any
static ip addresses, any alias files would be ignored.
We should also allow alias files with (pure) 'dhcp' connections,
just like initscripts do.
Reported-by: Marek Hulan <mhulan@redhat.com>
connection_from_file() used to log a warning about failure,
but only when an @error argument was given.
update_connection() didn't ensure that in several cases,
so we would not log any failure reason when an ifcfg file
failed to read.
This behavior of controlling logging by passing @error (or not)
is unexpected. Instead, refactor the code so that the caller
can do appropriate logging.
Another reason for this refactoring is that PARSE_WARNING() does
not mention the file for which the failure is and uses some extra
indention that looks wrong. IOW, connection_from_file() doesn't
have the context to give the logging line a proper formatting.
We already have "nm-utils*.h" and "NetworkManagerUtils.h" headers. Rename
"include/nm-utils-internal.h" to "nm-macros-internal.h". I think that
name is better, because this file is header-only, internal, and
repository-wide.
Also, it will never contain non-header-only declarations because
there is no backing object file under "include/".
It will only contain macros and inline functions.
"nm-utils-private.h" should not be used outside of libnm-core/.
core/ should only use public API or "nm-core-internal.h".
Also, "nm-setting-ip-config.h" is a public header and should
not contain internal defines. Move them to "nm-core-internal.h"
too.
Fixes: 019943bb5d
Most nm_platform_*() functions operate on the platform
singleton nm_platform_get(). That made sense because the
NMPlatform instance was mainly to hook fake platform for
testing.
While the implicit argument saved some typing, I think explicit is
better. Especially, because NMPlatform could become a more usable
object then just a hook for testing.
With this change, NMPlatform instances can be used individually, not
only as a singleton instance.
Before this change, the constructor of NMLinuxPlatform could not
call any nm_platform_*() functions because the singleton was not
yet initialized. We could only instantiate an incomplete instance,
register it via nm_platform_setup(), and then complete initialization
via singleton->setup().
With this change, we can create and fully initialize NMPlatform instances
before/without setting them up them as singleton.
Also, currently there is no clear distinction between functions
that operate on the NMPlatform instance, and functions that can
be used stand-alone (e.g. nm_platform_ip4_address_to_string()).
The latter can not be mocked for testing. With this change, the
distinction becomes obvious. That is also useful because it becomes
clearer which functions make use of the platform cache and which not.
Inside nm-linux-platform.c, continue the pattern that the
self instance is named @platform. That makes sense because
its type is NMPlatform, and not NMLinuxPlatform what we
would expect from a paramter named @self.
This is a major diff that causes some pain when rebasing. Try
to rebase to the parent commit of this commit as a first step.
Then rebase on top of this commit using merge-strategy "ours".
Before, when having a test with nmtst_init_assert_logging(),
the caller was expected to setup logging separately according
to the log level that the test asserts against.
Since 5e74891b58, the logging
level can be reset via NMTST_DEBUG also for tests that
assert logging. In this case, it would be useful, if the test
would not overwrite the logging level that is set externally
via NMTST_DEBUG.
Instead, let the test pass the logging configuration to
nmtst_init_assert_logging(), and nmtst will setup logging
-- either according to NMTST_DEBUG or as passed in.
This way, setting the log level works also for no-expect-message
tests:
NMTST_DEBUG="debug,no-expect-message,log-level=TRACE" $TEST
libnm-core treated the UNKNOWN WEP key type as KEY. Relax that
and try to guess the correct type based on the key.
This is for example important if you have a valid connection with
wep-key-type=0 (unknown)
If you request passwords for such a connection, the user cannot
enter them in password format -- but there is no UI indication
that the password must be KEY.
==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==
Replace the pthread_sigwait()-based signal handling with
g_unix_signal_add()-based handling, and get rid of all the
now-unnecessary calls to nm_unblock_posix_signals() when spawning
subprocesses.
As a bonus, this also fixes the "^C in gdb kills NM too" bug.
Custom IP ranges for shared connection were implemeted in bgo #6759732
(commit 32a001f526). 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
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.
