Ifcfg reader now properly handles escaping and quoting. We don't
need to stip whitespace, if somebody explicitly configures
prop=" value"
it is a configuration error.
ifnet has two extra instances @p12_type/@phase2_p12_type, that only
differed from @pk_type/@phase2_pk_type by their suffix.
But as the suffix field as unused, we can drop that entirely.
If one property has multiple ways to be handled, we should not create
two ObjectType instances, instead let the ObjectType have enough
information to act accordingly.
The PKCS#11 URIs start with the "pkcs11:" scheme. There's a slight
possiblity of a clash with file names relative to the ifcfg file, but
that's probably is unlikely enough the leave us not worried.
The alteratives are probably more horrible (using a different key, or
using a separate key for the scheme alone) and it's already simple
enough to avoid a clash by using an absolute file name.
When the main ifcfg file contains no IP addresses, the method
will be "disabled". Later, when reading IP addresses for the
aliases, we must ensure that the method is manual.
Otherwise, validation fails with
ip.addresses: this property is not allowed for method=disabled
With commit 4f6c91d696, we aimed to
enable mac-address-randomization by default for Wi-Fi. That however
is not possible by default because it breaks various scenarios.
Also, later wifi.mac-address-randomization was deprecated in favor
of wifi.cloned-mac-address setting.
Both wifi.mac-address-randomization and wifi.cloned-mac-address support
global default values, so it is wrong to read a missing
MAC_ADDRESS_RANDOMIZATION setting as "NEVER" -- which due to
normalization also results in cloned-mac-address=permanent.
See also commit 46d53e1101 which does
something similar for keyfile.
This bug also prevents a user from clearing the cloned-mac-address:
$ nmcli connection show "$CONN"
...
802-11-wireless.cloned-mac-address: permanent
802-11-wireless.mac-address-randomization: never
...
$ nmcli connection modify "$CONN: wifi.cloned-mac-address ''
# ^ takes no effect
As workaround, you also need to clear mac-address-randomization:
$ nmcli connection modify "$CONN: wifi.cloned-mac-address '' \
wifi.mac-address-randomization default
https://mail.gnome.org/archives/networkmanager-list/2017-January/msg00060.html
When a ifcfg-rh connection becomes unamanaged it is removed from the
connection list in NMSettings and marked as removed; it is however
kept alive in the plugin and can become managed again later. To avoid
failed assertions, the @removed flag of the NMSettingsConnection must
be cleared if the connection is not being disposed.
All implementations of link_changed() chain up to NMDevice's
base implementation. Thus, everybody wants to set the carrier.
Refactor the code to set the carrier outside of link_changed().
Use nm_utils_fd_get_contents() which has precisely all the steps implemented
to read data from a file descriptor.
There is a downside to this: previously you could compile shvar.c without
nm-core-utils.c. Now, the ifcfg implementation gained a dependency
on NM core utils. That would matter if we one day would like to build
shvar.c without core NetworkManager utils (but that is not planned).
Pre-process each line and parse the key and value.
Thus, keep the key already prepared.
The point is to do the parsing early and keep the
data in a more suitable format in shvarLine.
The shlist_delete*() are now named wrong, as they don't delete
the list entry. Anyway, they have only one caller, it's clearer
to inline them.
This way, during svSetValue() we need to iterate the entire
list only once.
We used MASTER, BRIDGE and TEAM_MASTER keys for a differnet purpose than the
network.service did, confusing the legacy tooling. Let's do our best to write
compatible configuration files:
* Add *_UUID properties that won't clash with initscripts
* Ignore non-*_UUID keys on read if *_UUID is present
* If the connection.master is an UUID of a connection with a
connection.interface-name, write the uuid into the *_UUID key while setting
the non-*_UUID key to the interface name for compatibility
https://bugzilla.redhat.com/show_bug.cgi?id=1369091
Currently ipv4 and ipv6 settings share the ifcfg plugin vars for the
dhcp-hostname and dhcp-send-hostname options (DHCP_HOSTNAME and
DHCP_SEND_HOSTNAME). Add brand new vars DHCPV6_HOSTNAME and
DHCPV6_SEND_HOSTNAME to have var-property one to one mappings.
When those values are missing they are already considered as TRUE.
As they are written also when DHCP is not enabled, write them only
if they have a value different from the default.
Also, ifnet plugin would read the configuration value, which is just wrong
because:
- the configuration might not be set and ifnet would fail to fallback
to the compile time default.
- the configuration only is in effect if the plugin is also available.
Otherwise, we fallback to the next plugin.
Only the dhcp-manager knows which DHCP plugin is in use.
NOTE: changed the default value for auto-negotiate from TRUE to FALSE.
Normalization enforces that no values for speed and duplex are there
when autonegotiation is on. This is required as autoneg on with specific
speed and duplex set means to ethtool to use autonegotiation but
advertise that specific speed and duplex only.
autoneg off, speed 0 and duplex NULL means to ignore link negotiation.
