DHCPv6 doesn't really use broadcast; instead clients use reserved
multicast addresses to talk to the server. ff02::1:2 (link scope)
and ff05::1:3 (site scope) are used. This means the routing table
has to have a route that can handle outgoing traffic to these
addresses, which is ff00::/8. The kernel sometimes adds one for us,
so we need to (a) make sure we don't tear that route down, and
(b) that if it's not there before we start DHCPv6, that we add it.
Otherwise dhclient complains about not being able to send outgoing
traffic from it's send_packet6() function with "no route to host".
It will then use an expired lease, which causes NM to assign that
leases IP address to the interface, whcih causes the kernel to
assign the required ff00::/8 route, and then dhclient performs a
renew (since the expired lease has expired of course) and then
everything works out in the end. But the latency sucks.
So make DHCPv6 faster by ensuring that dhclient has the routes
it needs before we start the DHCP session.
If it's not running or we can't spawn it (it's not supposed to be
autospawned anyway) we should just ignore the error and poke clients
that we've tried and failed to get user settings instead of warning
with an annoying message.
Many clients using libnm-glib (often command-line ones like nm-tool
or nmcli) aren't long-lived enough for NM to get their UID from
the bus daemon and validate their permissions via PolicyKit. So
when the NMClient object is created, get the permissions synchronously
(with a very low timeout to prevent unecessary blocking) to ensure
that the client is still on the bus when NM asks for it's credentials.
Avoids a ton of messages like:
NetworkManager[10274]: <warn> error requesting auth for org.freedesktop.NetworkManager.enable-disable-wwan: (6) Remote Exception invoking org.freedesktop.PolicyKit1.Authority.CheckAuthorization() on /org/freedesktop/PolicyKit1/Authority at name org.freedesktop.PolicyKit1: org.freedesktop.DBus.Error.NameHasNoOwner: Remote Exception invoking org.freedesktop.DBus.GetConnectionUnixUser() on / at name org.freedesktop.DBus: org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of name ':1.95': no such name
The autoactivation code wasn't excluding subchannel-locked connections
when matching for devices that don't have subchannels. This only
produced a warning message though as the connection activation would
be failed by the check_connection_compatible hook.
If your hostname is 'foo.bar.baz' and your DNS server doesn't
actually reply to queries for 'foo.bar.baz' you can't just 'ping foo'
currently. While that may be somewhat of a misconfigured setup,
since we're already adding the domain part of the hostname to
/etc/resolv.conf we might as well add the short hostname to /etc/hosts
too so that ping works.
They aren't ignored if they have HWADDR due to commit
46696c22ca32999ec09d1ac395e8f043522fdf2d
(ifcfg-rh: correct handling of BRIDGE and VLAN unmanaged connections (rh #619863))
For those ifcfg files that do have HWADDR and thus can have their
device be unmanaged, we want to read in a much of the connection as
possible since unmanaged devices are tracked via internal NMIfcfgConnection
objects. For BRIDGE/VLAN ifcfg files that don't have HWADDR, we do
want to ignore them completely, but also return a useful error
message.
Previously the code would assume that if the ifcfg file had no backing
connection that we should try to read it in regardless of what the
inotify event was. But if the event was DELETED, there's no point in
trying to read a deleted file in; it's gone. Don't print bogus
warnings about failure to read the long-gone ifcfg file.
Just for consistency, make settings related stuff live under the
org.freedesktop.NetworkManager namespace, rather than its own
org.freedesktop.NetworkManagerSettings namespace. Renames are done for
DBus interface names, DBus object paths, and polkit actions.
Remove the org.freedesktop.NetworkManagerSystemSettings bus name and
have everybody talk to org.freedesktop.NetworkManager. Now that we have
a single settings service that's embedded in the main daemon, we don't
need separate names anymore.
NMSysconfigSettings inherited the "bus" property from NMSettingsService.
The property was originally created to allow us to specify what DBus
connection to use, which was important in the days of user settings
services. Now, however, the daemon is the only thing that has a settings
service, and so we can trim a bit of clutter by removing this property
and using NMDBusManager directly.
NMSettingsConnectionInterface was created to allow the daemon and NM
clients to have common code that handled both system and user
connections. It's no longer needed now that user settings services are
gone.
This concludes the flattening of libnm-glib.
The various "update" functions implemented by NMSysconfigConnection have
become confusing. Depending on how you count, we've wound up with about
4 functions that all share the name "update" but nonetheless do
different things. These functions used to be distributed over several
interfaces implemented by NMSysconfigConnection, but now that we've
removed NMExportedConnection and are about to remove
NMSettingsConnectionInterface, they will be all crammed into a single
interface and will be even more confusing than before. It's time to
give better names to these guys.
The renames planned are:
- nm_settings_connection_interface_update() -->
nm_sysconfig_connection_commit_changes()
- nm_sysconfig_connection_update() with signal_update==FALSE -->
nm_sysconfig_connection_replace_settings()
- nm_sysconfig_connection_update() with signal_update==TRUE -->
nm_sysconfig_connection_replace_and_commit()
This commit performs the last two renames. The first will be performed
when removing NMSettingsConnectionInterface.
We also have nm_sysconfig_connection_replace_and_commit() have an
async-ish API that accepts a callback. This fits nicely with the
async-ish API of nm_settings_connection_interface_update(), and it lets
us clean up pk_update_cb() a bit.
NMExportedConnection originally implemented its DBus method call
handlers as virtual functions, primarily so that system and user
settings services could implement them differently.
NMIfupdownConnection also depended on GetSecrets being virtual, so this
was retained when NMExportedConnection was flattened into
NMSysconfigConnection.
However, it turns out that NMIfupdownConnection doesn't really need
these functions to be virtual; it's more appropriate to override the
methods of NMSettingsConnectionInterface (which are used by the DBus
handlers). Indeed, we really don't want settings plugins to override
the DBus handlers, as we must authorize the caller before doing anything
else. So we can save a bunch of code and devirtualize these handlers.
ifupdown only supports secrets for wireless connections, so attempts to
get non-wireless secrets need to fail. Previously, this was accomplished
by overriding NMSysconfigSettingsClass->get_secrets, the handler for
DBus GetSecrets() method calls. This had some problems:
- It created an information leak. The first thing the
NMSysconfigConnection implementation does is verify that the caller is
authorized to get secrets information, but nm-ifupdown-connection ends
up performing its additional check before authorization happens. Thus,
unauthorized users are able to determine that some connections don't
have secrets. This will become more significant when secrets handling
is revamped.
- We'd really like to devirtualize these DBus method call handlers.
They were inherited from from NMRemoteConnection, where we needed
these functions to be virtual so that user and system settings
services could implement them differently. That is no longer needed.
ifupdown was the last place were we actually "needed" these functions
to be virtual.
With this commit, we fix these problems by overriding
nm_settings_connection_interface_get_secrets instead.
NMSettingsInterface was created to allow code to operate on a settings
service without caring about what kind of settings service it was. Now
that we have just one settings service, this is no longer needed.
More work needs to be done in order to handle errors and permission
settings in an appropriate manner.
In continuation of the theme, the removal of user settings services
means that the distinction between NMSysconfigConnection and
NMExportedConnection is no longer needed. Merge NMExportedConnection
into NMSysconfigConnection.
Much as with nm-remote-settings and nm-remote-settings-system, the
removal of user settings services means there is no more need for
separate interfaces for user and system settings services.
In libnm-glib, this commit merges everything in
nm-settings-system-interface into nm-settings-interface. Alongside with
that, we merge everything in the
org.freedesktop.NetworkManagerSettings.System DBus interface into
org.freedesktop.NetworkManagerSettings.
Originally, nm-remote-settings was used by the daemon to monitor the
user settings service, and its subclass nm-remote-settings-system was
used by NM clients to monitor the system settings service. With user
settings services gone, this distinction is no longer needed. Simplify
things a bit and merge the classes.
Now that we have only one settings service, there is no more need to
have common settings service code in libnm-glib. So we can simplify
things somewhat my moving everything from nm-settings-service into
nm-sysconfig-settings.
Remove code related to "connection scope" and such. Later, we will also
do lots of code flattening and simplification that's possible now that
user settings are gone.
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.
