Add an improved way of tracking meta data about settings.
E.g. it is wrong to generate for each property a nmc_property_*_get_*()
function. Instead, there should be a meta data about the property
itself, and a mechanism to retrieve the property.
For now, only do this for NMSettingConnection and keep all the existing
infrastructure in place. Later on all settings shall be moved.
Especially to accomodate NmcOutputField mangles the concept of
setting-meta data, formatting options, and collecting output results.
It's a total hack, that will be need fixing later.
This will be solved differently by th/setting-user-data-bgo776276
branch. Revert the change for now, the same functionality will be
restored later.
This reverts commit 623d888801.
Don't print value output in the "PRETTY" format when the --terse option
has been specified.
This should allow to feed back the output from "nmcli show" to "nmcli
modify" without changes.
We can't pass the password obtained from
nm_setting_802_1x_get_*private_key_password() to
nm_setting_802_1x_set_*private_key() as the latter also frees the old
password.
Fixes: afd2811028
* all getter/setter/describe, ... functions grouped according to properties
* sort the settings groups alphabetically
(cherry picked from commit 418733f2c1)
It results in a rather confusing behavior:
# nmcli c modify wifi \
802-1x.private-key /etc/pki/themostsecret.key \
802-1x.private-key-password verystrong
Error: failed to modify 802-1x.private-key: private key
password not provided.
Moreover, the user might have a good reason for not specifying it on a command
liue and it's not strictly required anyway -- we'll do fine if we don't verify
a private key at addition time.
We now require settings-docs.c to be present. Either, configure
with --enable-gtk-doc to have it build, or use the pre-generated file
from the source tarball.
The numeric value of NM_SETTING_PROXY_METHOD_NONE should be zero,
as that is the more natural default.
Also, cast all uses of the enum values in g_object_set() to
(int).
libnm-core: pac-script property in NMSettingProxy now represents the
script itself not the location. It ensures that the connection is
self contained.
nmcli: Supports loading of PAC Script via file path or written explicitly.
Unnecessary APIs have been removed from nm-setting-proxy, client like
nm-connection-editor are expected to create a PAC script snippet the load
the location of file in NM.
For the per-connection settings "ethernet.cloned-mac-address"
and "wifi.cloned-mac-address", and for the per-device setting
"wifi.scan-rand-mac-address", we may generate MAC addresses using
either the "random" or "stable" algorithm.
Add new properties "generate-mac-address-mask" that allow to configure
which bits of the MAC address will be scrambled.
By default, the "random" and "stable" algorithms scamble all bits
of the MAC address, including the OUI part and generate a locally-
administered, unicast address.
By specifying a MAC address mask, we can now configure to perserve
parts of the current MAC address of the device. For example, setting
"FF:FF:FF:00:00:00" will preserve the first 3 octects of the current
MAC address.
One can also explicitly specify a MAC address to use instead of the
current MAC address. For example, "FF:FF:FF:00:00:00 68:F7:28:00:00:00"
sets the OUI part of the MAC address to "68:F7:28" while scrambling
the last 3 octects.
Similarly, "02:00:00:00:00:00 00:00:00:00:00:00" will scamble
all bits of the MAC address, except clearing the second-least
significant bit. Thus, creating a burned-in address, globally
administered.
One can also supply a list of MAC addresses like
"FF:FF:FF:00:00:00 68:F7:28:00:00:00 00:0C:29:00:00:00 ..." in which
case a MAC address is choosen randomly.
To fully scamble the MAC address one can configure
"02:00:00:00:00:00 00:00:00:00:00:00 02:00:00:00:00:00".
which also randomly creates either a locally or globally administered
address.
With this, the following macchanger options can be implemented:
`macchanger --random`
This is the default if no mask is configured.
-> ""
while is the same as:
-> "00:00:00:00:00:00"
-> "02:00:00:00:00:00 02:00:00:00:00:00"
`macchanger --random --bia`
-> "02:00:00:00:00:00 00:00:00:00:00:00"
`macchanger --ending`
This option cannot be fully implemented, because macchanger
uses the current MAC address but also implies --bia.
-> "FF:FF:FF:00:00:00"
This would yields the same result only if the current MAC address
is already a burned-in address too. Otherwise, it has not the same
effect as --ending.
-> "FF:FF:FF:00:00:00 <MAC_ADDR>"
Alternatively, instead of using the current MAC address,
spell the OUI part out. But again, that is not really the
same as macchanger does because you explictly have to name
the OUI part to use.
`machanger --another`
`machanger --another_any`
-> "FF:FF:FF:00:00:00 <MAC_ADDR> <MAC_ADDR> ..."
"$(printf "FF:FF:FF:00:00:00 %s\n" "$(sed -n 's/^\([0-9a-fA-F][0-9a-fA-F]\) \([0-9a-fA-F][0-9a-fA-F]\) \([0-9a-fA-F][0-9a-fA-F]\) .*/\1:\2:\3:00:00:00/p' /usr/share/macchanger/wireless.list | xargs)")"
Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address"
settings. Instead of specifying an explicit MAC address, the additional
special values "permanent", "preserve", "random", "random-bia", "stable" and
"stable-bia" are supported.
"permanent" means to use the permanent hardware address. Previously that
was the default if no explict cloned-mac-address was set. The default is
thus still "permanent", but it can be overwritten by global
configuration.
"preserve" means not to configure the MAC address when activating the
device. That was actually the default behavior before introducing MAC
address handling with commit 1b49f941a6.
"random" and "random-bia" use a randomized MAC address for each
connection. "stable" and "stable-bia" use a generated, stable
address based on some token. The "bia" suffix says to generate a
burned-in address. The stable method by default uses as token the
connection UUID, but the token can be explicitly choosen via
"stable:<TOKEN>" and "stable-bia:<TOKEN>".
On a D-Bus level, the "cloned-mac-address" is a bytestring and thus
cannot express the new forms. It is replaced by the new
"assigned-mac-address" field. For the GObject property, libnm's API,
nmcli, keyfile, etc. the old name "cloned-mac-address" is still used.
Deprecating the old field seems more complicated then just extending
the use of the existing "cloned-mac-address" field, although the name
doesn't match well with the extended meaning.
There is some overlap with the "wifi.mac-address-randomization" setting.
https://bugzilla.gnome.org/show_bug.cgi?id=705545https://bugzilla.gnome.org/show_bug.cgi?id=708820https://bugzilla.gnome.org/show_bug.cgi?id=758301
This new property be used as token to generate stable-ids instead
of the connection's UUID.
Later, this will be used by ipv6.addr-gen-mode=stable-privacy,
ethernet.cloned-mac-address=stable, and wifi.cloned-mac-address=stable
setting. Those generate stable addresses based on the connection's
UUID, but allow to use the stable-id instead.
This allows multiple connections to generate the same addresses
-- on the same machine, because in the above cases a machine
dependant key is also hashed.
When NM looks for vpn plugins, it would expect the full service name
otherwise it will not be able to retrieve the correct plugin.
Fixes VPN configurations generated with "nmcli connection add".
This is a huge refactoring in attempt to 1.) reduce the horrible redundancy in
the connection addition path and 2.) reduce confusion between various sources
of property value (command line, properties, interactive mode).
* The conversions from the strings was done all over the place:
settings.c already does for all sensible properties.
The rest is removed.
* The validations are done randomly and redundantly:
server does some validation, and per-property client validations
useful for interactive mode are done in settings.c
The rest is removed.
* The information about defaults and required options was redundantly
scattered in per-type completion functions and interactive mode
questionnaries. This is now driven by the option_info[] table.
In general, we do our best to just map the command line options to
properties and allow mixing them. For the rest there's the
check_and_set() callbacks (basically to keep compatibility with previous
nmcli versions). This this is now all possible:
$ nmcli c add type ethernet ifname '*'
This always worked
$ nmcli c add type bond-slave save no -- connection.autoconnect no
The "save" and "--" still work
$ nmcli c add connection.type ethernet ifname eth0
Properties can now be used
$ nmcli c add type ethernet ip4 1.2.3.4 mac 80:86:66:77:88:99 con-name whatever
There's no implementation mandated order of the properties (the type
still must be known to determine which properties make sense)
$ nmcli --ask c add type ethernet ip4 1.2.3.4 mac 80:86:66:77:88:99 con-name whatever
The interactive mode asks only for properties that weren't specified
on command line
