| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
|\
| |
| |
| | |
https://bugzilla.gnome.org/show_bug.cgi?id=759116
|
| |
| |
| |
| |
| |
| | |
- it controls echoing passwords input on terminal
- it replaces --show-secrets in 'nmcli connection show', which is deprecated now
- it replaces --show-password in 'nmcli device wifi hotspot', which is deprecated now
|
| | |
|
| | |
|
| | |
|
|/
|
|
| |
adds nmc_readline_echo() function that can disable displaying characters.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These initscripts weren't modified for a long time. Are they just
unused or flawless? It seems they are no longer best-practice
(e.g. NetworkManager supports reloading configuration via SIGHUP,
which none of these scripts implement).
Nowadays some distributions moved to systemd and quite possible
nobody uses these scripts. Also, any potential downstream user
probably has an adjusted copy of them in their repositories.
Just remove them.
https://mail.gnome.org/archives/networkmanager-list/2015-December/msg00003.html
|
|
|
|
| |
for 'nmcli connection clone'
|
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=753578
https://git.gnome.org/browse/network-manager-openvpn/commit/?id=4eb5f3ad43cdc62c6d4d254731e24c90b87ba91a
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before the device is setup, we call nm_platform_tun_get_properties() without
a valid ifindex. That triggered an assertion [1].
Thereby, change nm_platform_tun_get_properties() to effectively clear
the tun properties when we are unable to fetch them. Also, never modify
the tun-mode of NMDeviceTun.
[1]
#0 0x00007f0a4173e81b in g_logv (breakpoint=1) at gmessages.c:324
#1 0x00007f0a4173e81b in g_logv (log_domain=0x561e9264ccf6 "NetworkManager", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7ffd71a0d4d0) at gmessages.c:1081
#2 0x00007f0a4173e98f in g_log (log_domain=<optimized out>, log_level=<optimized out>, format=<optimized out>) at gmessages.c:1119
#3 0x0000561e9241ecec in nm_platform_tun_get_properties (self=0x561e9354ba70 [NMLinuxPlatform], ifindex=0, props=0x7ffd71a0d650) at platform/nm-platform.c:2081
#4 0x0000561e923aad9c in reload_tun_properties (self=0x561e937fb080 [NMDeviceTun]) at devices/nm-device-tun.c:68
#5 0x0000561e923aa795 in realize (device=0x561e937fb080 [NMDeviceTun], plink=0x7ffd71a0d818, error=0x7ffd71a0d798) at devices/nm-device-tun.c:225
#6 0x0000561e923bdc06 in nm_device_realize (self=0x561e937fb080 [NMDeviceTun], plink=0x7ffd71a0d818, out_compatible=0x7ffd71a0d77c, error=0x7ffd71a0d798) at devices/nm-device.c:1713
#7 0x0000561e924ad995 in platform_link_added (self=0x561e9356e230 [NMManager], ifindex=33, plink=0x7ffd71a0d818) at nm-manager.c:1947
#8 0x0000561e924ad717 in _platform_link_cb_idle (data=0x561e937eb940) at nm-manager.c:2029
#9 0x00007f0a41737e3a in g_main_context_dispatch (context=0x561e93547530) at gmain.c:3154
#10 0x00007f0a41737e3a in g_main_context_dispatch (context=context@entry=0x561e93547530) at gmain.c:3769
#11 0x00007f0a417381d0 in g_main_context_iterate (context=0x561e93547530, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3840
#12 0x00007f0a417384f2 in g_main_loop_run (loop=0x561e935475f0) at gmain.c:4034
#13 0x0000561e923ba3f3 in main (argc=1, argv=0x7ffd71a0dc68) at main.c:488
Fixes: 4dbaac4ba24ebc8b257fffe5197cc8e362804a58
|
| |
|
| |
|
|
|
|
| |
Fixes: 3892b839af4597c29ebff6d77666566dc4f94fb1
|
| |
|
|
|
|
| |
Fixes: b8d6bd1a9852b74cc1137c32600f6d6934ed6808
|
|\
| |
| |
| | |
https://bugzilla.redhat.com/show_bug.cgi?id=1034105
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Synopsis:
nmcli connection export [ id | uuid | path] <ID> [<output file>]
for exporting VPN connections.
https://bugzilla.redhat.com/show_bug.cgi?id=1034105
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Synopsis:
nmcli connection import [--temporary] type <type> file <file to import>
Only VPN configurations can be imported at the moment.
https://bugzilla.redhat.com/show_bug.cgi?id=1034105
|
| |
| |
| |
| | |
in nm_vpn_get_plugin_by_service()
|
|/ |
|
|
|
|
|
|
|
|
|
| |
Change the name of the file where to store the results
of the valgrind run.
Previously the file had a prefix "valgrind-", which is inconvinient.
Instead, have the file using the same name as the test executable,
with a ".valgrind-log" suffix.
|
|\
| |
| |
| | |
https://bugzilla.gnome.org/show_bug.cgi?id=759027
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I found the handling of the master-device very confusing because it was
unclear who sets priv->master, and when it should be set.
Now:
- Setting priv->master (in a slave) always goes together with adding
the master to priv->slaves (in the master). Previously, this was
done at separate places, so it was not clear if master and slave
always agree on their relationship -- in fact, they did not.
- There are now three basic functions which do the enslaving/releasing:
(1) nm_device_master_add_slave()
(2) nm_device_master_enslave_slave()
(3) nm_device_master_release_one_slave()
Step 3/release basically undoes the 1/add and 2/enslave steps.
- completing the enslaving/releasing is now done by
(1) nm_device_slave_notify_enslave()
(2) nm_device_slave_notify_release()
These functions also emit signals like NM_DEVICE_MASTER.
- Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead
the notification is emited together with NM_DEVICE_MASTER, whenever a
slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes
slaves that are actually @is_enslaved.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Instead of reimplementing the slave property in bond, bridge
and team, just add the property to the parent class. It's not
that the parent class would be agnostic to the master/slave
implementation, all the slaves are known to the every device
type implementation.
Also, the derived class doesn't know the correct time when
to invoke the notify-changed for the slaves property.
E.g. it should be only invoked after nm_device_slave_notify_enslave()
when other components also consider the slave as enslaved.
Later this will be fixed so that the SLAVES property correspond
to what other master/slave related properties say.
|
|/
|
|
|
|
|
|
|
|
|
|
|
| |
(gdb) bt
#0 0x00007fc1c920681b in g_logv () at /lib64/libglib-2.0.so.0
#1 0x00007fc1c920698f in g_log () at /lib64/libglib-2.0.so.0
#2 0x00007fc1c9523237 in g_type_check_instance_cast () at /lib64/libgobject-2.0.so.0
#3 0x00007fc1bdef10ed in supplicant_connection_timeout_cb (user_data=0x561a52451600) at nm-device-wifi.c:2207
#4 0x00007fc1c9200893 in g_timeout_dispatch () at /lib64/libglib-2.0.so.0
#5 0x00007fc1c91ffe3a in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#6 0x00007fc1c92001d0 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#7 0x00007fc1c92004f2 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#8 0x0000561a511583f3 in main (argc=1, argv=0x7ffc033f1e28) at main.c:488
|
|\
| |
| |
| | |
https://bugzilla.redhat.com/show_bug.cgi?id=1034158
|
| |
| |
| |
| | |
https://bugzilla.redhat.com/show_bug.cgi?id=1034158
|
| | |
|
| | |
|
| |
| |
| |
| | |
This is duplicated already and the monitor will use it.
|
| |
| |
| |
| | |
We'll use this for device status monitor too.
|
| |
| |
| |
| |
| | |
Count the exit blockers. We'll want to terminate the device monitor in case all
monitored devices vanish.
|
| |
| |
| |
| |
| |
| |
| | |
from udev
I have no idea what was the purpose, however this causes an infinite loop if
udev has not product & vendor and the notify handler gets the property.
|
| |
| |
| |
| | |
changed
|
|/
|
|
|
| |
This allows us to use a conditionally colorized output outside
print_required_fields().
|
|
|
|
|
|
|
|
|
|
|
|
| |
dhclient adds a trailing dot to domain search list entries received
from the server, while the same domains received by other means
(dhcpcd on RA) don't have the final dot. The result is that
resolv.conf can be populated with duplicated entries.
Fix this by stripping the trailing dot when a new search domain is
added to a IP configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=758777
|
|\
| |
| |
| |
| |
| |
| | |
Merge an early part of 'th/device-master-slave-bgo759027' with some
trivial and uncontroversial changes.
https://bugzilla.gnome.org/show_bug.cgi?id=759027
|
| |
| |
| |
| |
| |
| |
| | |
release_slave() should do the right thing and handle errors as
good as it can. There is no value in propagating the error and
it's not clear what the caller should do in face of a failure
during release.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We have the master/slave related functions
- for master device:
- nm_device_master_add_slave()
- nm_device_master_release_slaves()
- nm_device_release_one_slave()
- nm_device_enslave_slave()
- for slave device:
- nm_device_slave_notify_enslave()
- nm_device_slave_notify_release()
Rename the two that didn't match the pattern to
- nm_device_master_release_one_slave()
- nm_device_master_enslave_slave()
|
| | |
|
|/ |
|
|
|
|
|
|
|
|
|
|
| |
We don't want to admin CAP_SYS_ADMIN to our capability set in our .service
file: If we're running with systemd then hostnamed should be used to manage the
hostname, otherwise we likely have all capabilities anyway.
Let the user know.
Really, use systemd-hostnamed. Use it.
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's clearer to (always) subscribe early to the NM_DEVICE_RECHECK_ASSUME signal
instead of during realize. Also, because a device can be realized several times.
Just make sure that recheck_assume_connection() doesn't do anything if it shouldn't
handle the event.
Only downside is some unnecessary work when there is nothing to do.
Also fix the signature of the NM_DEVICE_RECHECK_ASSUME handler recheck_assume_connection().
NM_DEVICE_RECHECK_ASSUME signal returns void. We should not subscribe recheck_assume_connection()
which returns gboolean.
|
| |
|
| |
|
| |
|
|
|
|
| |
Make it neater to implement a nm_utils_flags2str() function.
|
|\
| |
| |
| | |
Merge some trivial changes early to prepare for later changes.
|
| | |
|