Remove all support for user settings services from nmcli. Update its
manpage to reflect this.
Manpage edits also anticipate changes to be made in regards to how
secrets are managed.
Remove all references to connection scope and user-settings services
from the various internal APIs of the daemon. The external DBus API
remains unchanged, albeit in stub form for scope stuff.
It turns out that user settings services are strange and complicated
beasts. We will remove support for them, and we will later implement
security mechanisms on the system settings service that will do what
user settings services were intended to do.
This commit is a bulk removal of nm-manager's internal support code for
user settings services. The external API is largely unchanged, but
errors are returned if anyone ties to do something with user settings.
Work remaining includes some possible flattening of nm-manager's
internal code, along with code removal and API changes in other modules.
If the client was disabled with --with-dhclient=no or
--with-dhcpcd=no, then it's corresponding _PATH will be an empty
string. In that case we want to ignore that client completely
since it was disabled at build time.
Kind of a hack for now, would be better to push down a flag about
whether the update request came in from D-Bus, internally, or from
inotify, but that's a lot more invasive.
Treat them as unmanaged for now so that they dont' need NM_CONTROLLEd=no
which would require further configuration when NM does start to support
these configs.
NMIfupdownConnection really is a subclass of NMSysconfigConnection (as
declared via the G_DEFINE_TYPE macro in nm-ifconfig-connection.c), but
the header incorrectly used NMExportedConnection* in the class and
instance structs. We got away with it because NMSysconfigConnection*
didn't contain anything other than the stuff inherited from
NMExportedConnection*, but it would have caused much trouble if we did
add something.
For exported connections, nm_settings_connection_interface_update() is
supposed to cause the emission of a
NM_SETTINGS_CONNECTION_INTERFACE_UPDATED signal. This is usually done
by chaining up to the NMExportedConnection implementation of this
method, which actually emits the signal. However, the
NMKeyfileConnection implementation usually forgot to do this. Rewrite
so that we always chain up after successfully saving settings.
The wifi device is considered to be 'scanning' if the supplicant emits
the scanning signal or if it's in the scanning state; but the code
didn't correctly handle notifications when the supplicant was in the
scanning state.
This reverts commit b172519045.
When something like NTP updates the system clock, that can cause
dhclient to expire the lease, and at that point we just want NM
to let dhclient re-aquire the lease instead of failing the
whole connection.
Even though we prefer NetworkManager.conf, we need to check the
old nm-system-settings.conf first to preserve compat with older
setups. In package managed systems dropping a NetworkManager.conf
onto the system would make NM use it instead of nm-system-settings.conf,
changing behavior during an upgrade. We don't want that.
The PPP setting will usually be all defaults anyway, so lets just
created it when needed if it doesn't yet exist. Fixes an error
where the connection editor couldn't edit system DSL connections
because it tried to request secrets for the PPP setting that didn't
actually exist in the connection because the 'keyfile' plugin
wouldn't save all-default settings, thus that setting wouldn't
exist when read back in.
Some proprietary drivers (wl.o) report tuned frequency (like when
scanning) instead of the associated AP's frequency. This is a great
example of how WEXT is underspecified. We use frequency to find the
active AP in the scan list because some configurations use the same
SSID/BSSID on the 2GHz and 5GHz bands simultaneously, and we need to
make sure we get the right AP in the right band. This configuration
is uncommon though, and the frequency check penalizes closed drivers we
can't fix. Because we're not total dicks, ignore the frequency condition
if the associated BSSID/SSID exists only in one band since that's most
likely the AP we want.
