Make the type return GBytes since most in-tree users want that.
Allow the function to accept many more formats as valid hex, including
bytes delimited by ':' and a leading '0x'.
Create NMIPConfig as the parent of NMIP4Config and NMIP6Config, and
remove the two subclasses from the public API; while it's convenient
to still have both internally, they are now identical to the outside
world.
The gateway is a global property of the IPv4/IPv6 configuration, not
an attribute of any particular address. So represent it as such in the
API; remove the gateway from NMIPAddress, and add it to
NMSettingIPConfig.
Behind the scenes, the gateway is still serialized along with the
first address in NMSettingIPConfig:addresses, and is deserialized from
that if the settings dictionary doesn't contain a 'gateway' key.
Adjust nmcli's interactive mode to prompt for IP addresses and gateway
separately. (Patch partly from Jirka Klimeš.)
Now that NMSettingIP6Config inherits the dhcp-send-hostname property
from NMSettingIPConfig, fix things up so that it actually gets used.
(Note that this changes behavior: previously if ip6.dhcp-hostname was
unset, no hostname would be sent. Now, the system hostname will be
set. Also, ifcfg-rh does not currently support this property, so there
is no way to disable this...)
Split a base NMSettingIPConfig class out of NMSettingIP4Config and
NMSettingIP6Config, and update things accordingly.
Further simplifications of now-redundant IPv4-vs-IPv6 code are
possible, and should happen in the future.
Merge NMIP4Address and NMIP6Address into NMIPAddress, and NMIP4Route
and NMIP6Route into NMIPRoute. The new types represent IP addresses as
strings, rather than in binary, and so are address-family agnostic.
Synopsis:
nmcli agent { secret | polkit | all }
The command runs separate NetworkManager secret agent or session polkit agent, or both.
It is useful when
- no other secret agent is available (such as GUI nm-applet, gnome-shell, KDE applet)
- no other polkit agent is available (such as polkit-gnome-authentication-agent-1,
polkit-kde-authentication-agent-1 or lxpolkit)
https://bugzilla.gnome.org/show_bug.cgi?id=739568
It is useful for running nmcli without --ask option, i.e. non-interactively.
Example contents of the file:
wifi.psk: s e c r e t 12345
802-1x.password:kili manjaro
802-1x.pin:987654321
Test case:
nmcli> goto ipv4.addresses
nmcli ipv4.addresses> set 1.1.1.1
Do you also want to set 'ipv4.method' to 'manual'? [yes]: no
nmcli ipv4.addresses> set 3.3.3.3/99
Error: failed to set 'addresses' property: invalid prefix '99'; <1-32> allowed
Do you also want to set 'ipv4.method' to 'manual'? [yes]:
The second question (after failed 'set') should not be asked.
while editing an existing commention.
It was broken by commit 45590f809a that called
nm_connection_replace_settings_from_connection() which replaces settings with
connected signal handlers.
It can be used to display connection secrets (passwords). When used, it will
get secrets for the connection profile and merge it into the connection's
settings before displaying it.
Example:
nmcli con show -s hotel-wifi
libnm mostly used GPtrArrays in its APIs, except that arrays of
connections were usually GSLists. Fix this and make them GPtrArrays
too (and rename nm_client_list_connections() to
nm_client_get_connections() to match everything else).
Only default (infrastructure) mode connections can be created and as it's not
possible to write mode=ap connections with ifcfg-rh plugins, they can't be
switched to mode=ap.
Consolidate NMClientError and NMObjectError (such that there is now
only one libnm-API-specific error domain). In particular, merge
NM_CONNECTION_ERROR_CONNECTION_REMOVED with
NM_OBJECT_ERROR_OBJECT_CREATION_FAILURE as the new
NM_CONNECTION_ERROR_OBJECT_CREATION_FAILED.
Also make object_creation_failed() be a plain method rather than a
signal, since there's no reason for anyone to be connecting to it on
another object. And remove its GError argument because the subclass
can just create its own more-specific error.
Move the definition of NMSecretAgentError to nm-errors, register it
with D-Bus, and verify in the tests that it maps correctly.
NM_SECRET_AGENT_ERROR_INTERNAL_ERROR is renamed to
NM_SECRET_AGENT_ERROR_FAILED, and NM_SECRET_AGENT_ERROR_NOT_AUTHORIZED
to NM_SECRET_AGENT_ERROR_PERMISSION_DENIED, for consistency with other
error domains. While NMSecretAgentError, unlike most other error
domains, has always been correctly mapped across D-Bus, the renaming
is not an ABI break, because the daemon never checks for either of
those values, so all versions of the daemon will treat
"org.freedesktop.NetworkManager.SecretAgent.InternalError" and
"org.freedesktop.NetworkManager.SecretAgent.Failed" the same (by just
ignoring the error name and keeping only the error message).
Move the definition of NMManagerError to nm-errors, register it with
D-Bus, and verify in the tests that it maps correctly.
NM_MANAGER_ERROR_INTERNAL gets renamed to NM_MANAGER_ERROR_FAILED for
consistency. NM_MANAGER_ERROR_UNMANAGED_DEVICE is dropped since that
name doesn't really describe the one place it was previously used in.
NM_MANAGER_ERROR_SYSTEM_CONNECTION is dropped because it was't being
used. NM_MANAGER_ERROR_UNSUPPORTED_CONNECTION_TYPE is dropped because
it can be replaced with an NM_CONNECTION_ERROR.
NM_MANAGER_ERROR_AUTOCONNECT_NOT_ALLOWED is turned into the more
generic NM_MANAGER_ERROR_CONNECTION_NOT_AVAILABLE.
Also, remove the <tp:possible-errors> sections from nm-manager.xml,
since they were completely out of date.
Later _nmcli_compl_ARGS() wants to check $OPTIONS_TYPE to behave differently
depending on the type. As we accept abbreviations of $OPTIONS_TYPE, let's normalize
the value, so that we don't have to consider abbrevations later on.
Signed-off-by: Thomas Haller <thaller@redhat.com>
* two users are logged in: user_a and user_b
* user_b creates a connection visible only to him 'user_b_private'
(permissions: user:user_b)
* user_b activates the connection user_b_private
* user_a does not see the connection profile, but he does see the active
connection
* user_a calls
nmcli con
nmcli con show user_b_private
PPPoE connections involve two different network connections, making it
ambiguous what the "Device" field refers to. Clarify that it refers to
the Ethernet device, not the PPP device.
