Plugins may have problems with preserving some properties on write/read cycle,
may add ipv{4,6} settings when they are not present in the connection, etc.
That makes local and remote connection differ.
So we copy remote connection into the local to get rid of such problems.
Note:
68f12b4e9c and
f03635e5ac
commits ensure that all connection (except slaves) have IPv{4,6} settings.
https://bugzilla.redhat.com/show_bug.cgi?id=997958
When freeing one of the collections such as GArray, GPtrArray, GSList,
etc. it is common that the items inside the connections must be
freed/unrefed too.
The previous code often iterated over the collection first with
e.g. g_ptr_array_foreach and passing e.g. g_free as GFunc argument.
For one, this has the problem, that g_free has a different signature
GDestroyNotify then the expected GFunc. Moreover, this can be
simplified either by setting a clear function
(g_ptr_array_set_clear_func) or by passing the destroy function to the
free function (g_slist_free_full).
Signed-off-by: Thomas Haller <thaller@redhat.com>
- completion now works for command shortcuts too
nmcli> g ethe<TAB>
- completion now allows leading spaces
nmcli> desc wifi.ss<TAB>
- fix completion of settings when property is already there
nmcli> set con<TAB>.id
- fix completion of properties in setting.property
nmcli> des con.inter<TAB> bla
The session now looks like this:
There are optional arguments for 'bond' connection type.
Do you want to provide them? (yes/no) [yes]
Bonding mode [balance-rr]:
Bonding monitoring mode (miimon or arp) [miimon]: miimon
Bonding miimon [100]:
Bonding downdelay [0]:
Bonding updelay [0]:
...when answered arp...
Bonding arp-interval [0]:
Bonding arp-ip-target [none]:
https://bugzilla.redhat.com/show_bug.cgi?id=1007355
Bonding options are related and some combinations don't make sense. Basically,
MIIMON and ARP monitoring mode (and related options) are mutually exclusive.
When nmcli set arp_interval of "0" (the default value),
nm_setting_bond_add_option() cleared the MIIMON options (miimon, updelay and
downdelay).
This commit works around libnm-util's nm_setting_bond_add_option() that clears
miimon options when arp_interval is being set and vice versa, but doesn't
take into account the value of "0" that should be regarded as 'disable'.
https://bugzilla.redhat.com/show_bug.cgi?id=1007355
The commands performing actions without an output only printed a successfull
message for --pretty mode. Some users don't like this silent operation.
This commit makes nmcli print operation success unconditionally. I think that
doesn't hurt; scripts/users can ignore the message if not interested.
https://bugzilla.redhat.com/show_bug.cgi?id=1006444
Also allow leading/trailing white spaces, and more white spaces between IP and
gateway. (Spaces in values and around / are not allowed).
All of these are accepted:
' 1.2.3.4/11 1.2.3.254 '
' 1.2.3.4 '
' fe80::215:ff:fe93:ffff/128 ::1 '
...
https://bugzilla.redhat.com/show_bug.cgi?id=1007368
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
readline() makes changes to terminal and when it doesn't receive unix signals,
it has no chance to perform cleanups on exit. So we have to call its cleanup
functions manually on exit.
https://bugzilla.gnome.org/show_bug.cgi?id=706118
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.
remove <setting>[.property] | <property>
It entirely removes given setting from edited connection. If a property is given,
the command instead resets the property to its default value.
https://bugzilla.gnome.org/show_bug.cgi?id=707576
Synopsis: nmcli --ask connection add
When '--ask' is used, nmcli will ask not only for mandatory arguments but also
for the optional ones, with a series of questions.
Before, when specifying a setting.property with missing property name,
the following happened:
nmcli> set connection.
Error: invalid property: '' not among [...
Reword this special error case of a missing property to make it more
clear.
Signed-off-by: Thomas Haller <thaller@redhat.com>
readline_x returns NULL for empty input, so it is wrong
to call g_strstrip without checking for NULL first.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Setting the logging level fails for normal users due to missing dbus
permissions as configured in src/org.freedesktop.NetworkManager.conf.
In that case, nmcli simply fails showing the dbus error. This error
is however not very clear, so this commit shows a different error
text for the particular case of ACCESS_DENIED.
Signed-off-by: Thomas Haller <thaller@redhat.com>
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.
Before the change if an alias for a setting name existed, it was used instead of
the real name and TAB-completion for the real name didn't work.
before:
nmcli> goto 802<TAB>
no output
now:
nmcli> goto 802<TAB>
nmcli> goto 802-11-wireless
802-11-wireless 802-11-wireless-security
nmcli> goto <TAB>
802-11-wireless-security (wifi-sec) connection ipv6
802-11-wireless (wifi) ipv4
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).
