See http://git.gnome.org/browse/libgsystem/tree/README
for a description of libgsystem.
What we specifically are using it for here is the local allocation
macros; this patch just modifies main.c as a demo.
Note this patch fixes a double-free in an error condition in
check_pidfile(); those sort of mistakes are basically impossible
to make when using these macros.
We don't need to use distribution-specific network scripts to just bring
up the loopback interface.
I'm not aware of any init dependency problems but even if there are some,
it is more practical to solve them in the respective configuration files.
This function also tried to add 127.0.0.1 to the list of addresses but
not ::1. We don't need to set the interfaces up as this is done by the
kernel.
If we mask signals before daemonizing, the daemon process will not be
able to handle them, and thus would be unkillable with anything other
than SIGKILL.
Commit 217c5bf6ac fixed processing of unix
signals: signals are blocked in all threads and a dedicated thread handles the
signals using sigwait().
However, the commit forgot that child processes inherit signal mask as well.
That is why we have to unblock signals for child processes we spawn from NM, so
that they can receive signals.
Now that we've encountered this twice with distros disabling WEXT
but apparently not realizing it kills staging and out-of-kernel
drivers like wl.o, make it a log message so we don't have to go
hunting for build-time logfiles.
* use libsoup to compare a http response from a given
uri with a given response (use g_str_has_prefix () to compare)
* do periodically check the connectivity. Check interval is configurable
* check connectivity when device state change
from/to NM_DEVICE_STATE_ACTIVATED
src/firewall-manager tracks whether firewall is on the bus or not.
In nm-device.c at stage5 (ip-config-commit) before we actually
apply the IP configuration to the interface, we send the
IP interface name and zone to firewall and asynchronously wait
for a D-Bus reply. Then after we get the reply
(or if the firewall isn't running) we proceed with
applying the IP configuration to the interface.
OLPC Mesh code now doesn't have to be updated every time we change
the manager's creation arguments. We could make all these arguments
GObject properties of the manager too, but that's more code and
we'd eventually like to figure out a better solution for letting
non-NMManager code listen for device addition/removal.
Besides not being technically reliable (although it mostly works)
we could get into situations where systemd would kill the cgroup
which resulted in NM getting a SIGCHLD for dhclient children before
the SIGTERM quit the mainloop. This caused NM to think that the
dhclient process died unexpectedly, and to tear down the connection
even though what NM really wanted to do was just leave everything
running so that the connection could be taken over on restart.
Handling of /etc/hosts is highly site- and admin- specific in
many more complex cases, and it's exceedingly hard and error-
prone for NetworkManager to handle all those cases. So remove
this functionality entirely. That's not a big loss, as it
turns out there's a much more elegant solution.
The only requirement is that the machine's hostname map back
to an IP address owned by the machine. That requirement can
be satisifed by nss-myhostname or even possibly the distro's
installer. If the user does not want nss-myhostname then it
can be uninstalled. Distros should use a "recommends" feature
in their packaging system so that the NetworkManager package
does *not* have a hard requirement on nss-myhostname. Thus
everyone is happy; things Just Work when nss-myhostname is
installed, but more advanced users can uninstall it and
customize /etc/hosts as they wish.
Another alternative is a dispatcher script that listents for
the 'hostname' event, and updates /etc/hosts according to the
administrator's preference.
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.
More info:
https://bugzilla.redhat.com/show_bug.cgi?id=585394http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1172
dbus-glib was not properly enforcing the 'access' permissions on
object properties exported using its API. There were 2 specific bugs:
1) dbus-glib did not enforce the introspection read/write property
permissions, so if the GObject property definition allowed write
access (which is sometimes desirable), D-Bus clients could modify
that value even if the introspection said it was read-only
2) dbus-glib was not filtering out GObject properties that were
not listed in the introspection XML. Thus, if the GObject defined
more properties than were listed in the introspection XML (which is
also often useful, and NM uses this quite a bit) those properties
would also be exposed to D-Bus clients.
To fix this completely, you need to:
1) get dbus-glib master when the patch is commited, OR grab the
patch from https://bugzilla.redhat.com/show_bug.cgi?id=585394 and
build a new dbus-glib
2) rebuild NetworkManager against the new dbus-glib
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.
GIO will apparently normally try to use the remote VFS implemenation
on the session bus. But NM (as a root service) shouldn't ever be
trying to talk to anything on the session bus. Squash that.
