NMSysconfigSettings has the authoritative list of connections, no reason
to duplicate all that tracking code in NMManager. Add the missing bits
that the manager had to NMSysconfigSettings, and point NMPolicy at the
settings object instead of NMManager for that.
Add support for Fedora's dhclient's built-in RFC3442 classless static
routes format.
Since the Fedora format uses the same name as the dhcpcd format, we
need to refactor a bunch of the code to ensure we can distinguish
between the types. Do this at runtime now by consolidating the
classless static routes parsing code into the DHCP Client base class
and rework the unit tests so that we can test all variations of the
classless static route parsing code at the same time.
This also fixes a bug with the dhcpcd classless static route
gateway handling that would return the wrong gateway address.
Many thanks to Jiri Popelka from Red Hat for the initial patch
and explanations.
Everyone uses pm-utils still for sleep/wake support, and that's
traditionally how NM was put to sleep and woken up. But pm-utils
uses dbus-send without --print-reply so dbus-send quits immediately
after sending the message. That doesn't give NM enough time to
get the senders UID and thus validate the request, so the request
gets denied, and sometimes NM stays asleep after the machine is
woken up.
Instead, don't get the sender's UID and try to authorize it, but
just let the request go through. Rely on D-Bus permissions to
make sure that only root can call sleep/wake methods.
Groups may come later, but they are also quite a bit more complicated
because getting the groups a user is in may require network access
if that user is backed by LDAP. And it gets worse because you have
no idea that the glibc calls like getgrouplist(3) are backed by
the network and may take an arbitrary amount of time to complete.
Punt that.
If the supplicant dies a number of times within a short period of
time, make it go sit in the corner for a bit instead of continuously
trying to start it and have it die again.
Instead of just exposing a "running" value, instead make a meta
"available" value that's a combination of whether the supplicant
is actually running plus whether we want to talk to it right now
or not.
interface_add() could get called from two places: by the wifi/eth
device class when activating (which if the supplicant isn't yet
running will D-Bus activate it) and from the NameOwnerChanged
handler for the wpa_supplicant dbus service smgr_running_cb().
So if the supplicant wasn't running, nm_supplicant_interface_new()
would call interface_add() to bring the supplicant to life via
activation, then go on and create priv->iface_proxy. When the
supplicant appeared and D-Bus sent the NameOwnerChanged,
smgr_running_cb() would also call interface_add(), creating a
second priv->iface_proxy. The first one got lost and lived after
its parent NMSupplicantInterface was killed, and could still
respond to signals over the bus.
Prevent that by adding another state, STARTING, that indicates
that we've already started talking to the supplicant. Also be
extra paranoid about disconnecting signal handlers on the proxy.
config.h defines _GNU_SOURCE, which in turn defines the bits necessary
for kill, isblank, and isascii. So wherever we use those, we need
to make sure config.h is included.
Try to preserve custom hostnames (ie, anything not a localhost* variant,
the current hostname, or the previous hostname) when rewriting the
127.0.0.1/::1 localhost mapping lines.
