If we find a "iface ..." line, add the interface to
well_known_interfaces no matter if there is a connection for it or not.
Otherwise we fail to mark devices as unmageded in cases like
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
as NM does not know how to parse such a interface configuration.
Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=569215
Don't emit "unmanaged-specs-changed" signal in read_one_connection(),
because it causes that next connections are not listed (get_connections() is
called prematurely and only connections read so far are available).
Steps to reproduce the bug:
1) create ifcfg-fake
DEVICE=loremipsum
HWADDR=01:02:03:04:05:06
NM_CONTROLLED=no
2) restart NetworkManager
3) only connections read *before* ifcfg-fake are available
Thanks to Robert Vogelgesang <vogel@users.sourceforge.net> for updating
the patch and analysis!
GATEWAY0=0.0.0.0 was erroneously denied. Also, missing GATEWAY0 entry caused
ifcfg-rh plugin to regard the connection as invalid. The commit fixes that and
makes it behave in accordance with initscripts.
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.
Keep compat with old format if the SSID includes unprintable
characters. But having to type an int list for an SSID is just silly
and it's about damn time we fix that.
The IO library was in io/ because I was too lazy to find autotools'
SUBDIRS rules at the time and that you could use '.' for the current
directory. Fix that and use its own error defines instead of
the system settings service. Clean up a for more things for good
measure too (like KEYFILE_DIR, etc).
This should help people debug issues with keyfile not recognizing
files since it'll actually print out something when it fails to
parse stuff. Also logs changes, new connections, and deletions.
The previous implementation of the parser for /etc/network/interfaces had
quite a few drawbacks:
- it expected the lines to be terminated with "\n", even the last line
- it ignored line wraps with "\\" followed by "\n"
- it expected over-long lines to be shorter than 510 characters
- it ignored line wraps on over-long lines
- it treated spaces and tabs differently
- it did not make sure to really tokenize on word boundaries
- it treated the equivalent stanzas "auto" and "allow-auto" differently
- it ignored the fact that the "allow-*" stanzas can take multiple arguments
that need to be separated to be recognized NetworkManager's processing later
- it allowed "non-block" stanzas to appear before a block
This patch is a rewrite of the parser to fix the issues mentioned:
- it accepts the last line even if it is not terminated by "\n"
- it skips over-long lines, emits a warning and even takes into account
that over-long lines may be wrapped to next lines
- it un-wraps wrapped lines
- it uses spaces and tabs equivalently to tokenize the input
- it treats "allow-auto" as a synonym to "auto"
- it splits multi-argument "auto"/"allow-*" into multiple
single-argument stanzas of the same type
- it warns on data stanzas before the first block stanza
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.
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.
There are so many... so handle them as a table of key/value pairs
instead of having separate functions for each one. At the moment
nothing but subchannels is used internally, but this allows plugins
to preserve options that NM doesn't care about when reading/writing
system configuration.
