Create a new clients/ subdirectory at the top level, and move cli/ and
tui/ into it, as well as nm-online.c (which was previously in test/,
which made no sense).
cli/ was split into two subdirectories, src/ and completion/. While
this does simplify things (given that the completion file and the
binary both need to be named "nmcli"), it bloats the source tree, and
we can work around it by just renaming the completion file at install
time. Then we can combine the two directories into one and just have
it all under clients/cli/.
Certain build configurations (like --enable-gtk-doc
--disable-introspection) were broken with respect to nm-setting-docs.
Fix this. Also, we don't require just gobject-introspection, we need
pygobject specifically as well.
nmcli used the GParamSpec doc strings to get property descriptions,
but they will be going away. Generate a .c file from the new XML
setting docs file, and link that into nmcli.
Use nm_utils_hwaddr_ntoa_len() instead of nm_utils_hwaddr_ntoa().
This makes it no longer necessary to determine the type of the MAC
address based on the address length.
This makes the GETTER more accepting towards other lengths.
Signed-off-by: Thomas Haller <thaller@redhat.com>
- check if the values being set are existing connections
- also allow specifying connections by names, translating them transparently
to UUIDs.
- nmcli-specific section for 'describe' command added
(We use a global nm_cli variable in nmc_property_connection_set_secondaries())
nmcli con modify my-profile ipv4.addr " "
nmcli con modify my-profile ipv6.addr " "
Note:
Empty string should be used to remove IPs, and 'method' might be needed to set
to 'auto' simultaneously, as well.
$ nmcli con modify profile1 ipv4.addr "" ipv4.method auto
https://bugzilla.redhat.com/show_bug.cgi?id=1071394
It works both in 'nmcli con modify' and 'nmcli con edit'.
The following properties are supported (all container-type properties except
properties with option names):
ipv4.dns
ipv4.dns-searches
ipv4.addresses
ipv4.routes
ipv6.dns
ipv6.dns-searches
ipv6.addresses
ipv6.routes
802-1x.eap
802-1x.altsubject-matches
802-1x.phase2-altsubject-matches
connection.permissions
connection.secondary
802-3-ethernet.mac-address-blacklist
802-11-wireless.mac-address-blacklist
802-11-wireless-security.proto
802-11-wireless-security.pairwise
802-11-wireless-security.group
vlan.ingress-priority-map
vlan.egress-priority-map
Without this patch, the following two commands fail:
nmcli connection modify em1 connection.master
nmcli connection modify em1 connection.master ""
Signed-off-by: Thomas Haller <thaller@redhat.com>
The band/channel property is not considered when connecting to an
access point. Print a warning, when setting one of these values in edit
mode.
For now, don't forbid the user to make such setting. Also, because in
the future, wpa_supplicant might support this.
https://bugzilla.redhat.com/show_bug.cgi?id=999997https://bugzilla.redhat.com/show_bug.cgi?id=1000096
Signed-off-by: Thomas Haller <thaller@redhat.com>
That means you can display single property.
Example:
$ nmcli -f connection.id,802-3-ethernet.mtu s c my-eth-profile
connection.id: my-eth-profile
802-3-ethernet.mtu: auto
and use it for 'nmcli device show'.
This allows filtering output not only for whole groups, but also for individual
fields in commands that print data in groups (sections).
Example:
$ nmcli -f general.device,general.driver,ipv4,ipv6.address device show eth0
GENERAL.DEVICE: eth0
GENERAL.DRIVER: e1000e
IP4.ADDRESS[1]: ip = 10.0.5.228/23, gw = 10.0.5.254
IP4.ADDRESS[2]: ip = 5.5.5.5/32, gw = 5.5.5.1
IP4.DNS[1]: 192.168.122.1
IP4.DNS[2]: 8.8.8.8
IP4.DOMAIN[1]: mycompany.com
nmcli con add type team config /home/cimrman/team-config.json
libteam (and in turn NetworkManager) configures team devices via plain config
data in JSON format. However, it is useful and more user-friendly for nmcli to
accept also a file name that contains the config data, and read it. Thus the
user is not forced to type whole (possibly long) config on the command line.
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>
The format of property values that nmcli prints is not the same (for some
properties) as the format nmcli editor accepts as input from user. The reasons
are that (a) output format is more descriptive and not much suitable to be
typed, (b) it comes in most cases from libnm-util.
'change' command displays current property value and allows users to edit it.
So we convert the output into input format, before presenting it to the user.
https://bugzilla.redhat.com/show_bug.cgi?id=998929
nmc_setting_reset_property() function checks whether we allow changing the property
(set_func != NULL) and if so, the property value is reset to default.
The handlers detecting changes of IP addresses/method in nmcli interactive
editor were connected only for newly created connection. That's why the
automagic feature of setting 'method' when 'addresses' are changed and vice
versa worked just for new connections, but not while editing existing
connections.
The properties are not implemented in NM core, nor in ifcfg-rh plugin. Thus
they are not preserved over re-reading from ifcfg-* file. Moreover they are
highly dependent on drivers.
When we allowed editing them, the connection changed after re-reading and
was marked as dirty (and users were puzzled).
This bug caused the edit mode to refuse most of the valid wifi channels.
The bug was present since the beginning, so all versions before this
commit will have this issue.
https://bugzilla.redhat.com/show_bug.cgi?id=999999
Signed-off-by: Thomas Haller <thaller@redhat.com>
nmcli connection edit [type <type>] [con-name <name>]
Examples:
nmcli c e
nmcli c e type ethernet
nmcli c e type wifi con-name "My home Wi-Fi"
nmcli c e type bond
...
