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.
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.
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.
