Re: Relicense NetworkManager under LGPL-2.1+
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I, Colin Walters, agree to relicense my contributions to NetworkManager as LGPL-2.1+ as proposed by Thomas Haller. Some of my work may be held under copyright by Red Hat, Inc. I do not speak for that entity. -BEGIN PGP SIGNATURE- iQEzBAEBCgAdFiEEq5KKnPjdBikJw3u93EX9WSHBPwsFAl6+1CoACgkQ3EX9WSHB PwtpAwf9G7GQ7+ueMTo05vw122+mdfY+7+DUOGyZieO+kbyraTf5U9rDPQMAxqwg ns4fT09t3/T46PQAihkfGt6VWWA3g3mK0Ok+UxpeUnOIyAB/VXcsB5378soctxBi hcZLYZu74uE9Ch0hUOGsqMxbep0Z7zNXy6qq5Ryxgd0uXY86fn4YeYbWChISUznj yGHp9nERIX92veOT/LpzpcK1OQUARuHhek/tnK8+IMUyv8ffseKdWU4Ycj3PN4BS dU6N8rmkEHbHQQcvTufnxhUC5vwlUiAURkA345q7DP/75+NJ3fnq5Ya3rKXToF31 K82o4sjebNvy1DQoZqyhfSJPIwX0OQ== =xmwD -END PGP SIGNATURE- ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM in the initrd for Fedora CoreOS
On Sat, Jan 4, 2020, at 10:00 AM, Thomas Haller wrote: > Hi, > > > On Fri, 2020-01-03 at 14:21 -0500, Colin Walters wrote: > > I was trying out the current F31 dracut network-manager module, and > > couldn't get it to do anything useful. > > See: https://github.com/coreos/fedora-coreos-config/pull/259 > > > I don't understand what exactly didn't work (or what you tried). https://github.com/coreos/fedora-coreos-config/pull/259#issuecomment-570671191 > Is the "network-manager" dracut module loaded? That should be done by > modules.d/40network/module-setup.sh Yes. > I understand this is Fedora 31 CoreOS. But I am not familiar with that, > which versions of dracut and NetworkManager is that using exactly? Is > there something special compared to a "regular" Fedora installation? Part of the idea of all of this is we're not making a separate operating system. There are details here but broadly speaking, same packages from the Fedora repos. See https://getfedora.org/en/coreos/download/ for main releases, and https://builds.coreos.fedoraproject.org/browser for development builds, which can answer that question directly, click on "commitmeta.json" e.g. https://builds.coreos.fedoraproject.org/prod/streams/testing-devel/builds/31.20191222.20.0/x86_64/commitmeta.json > > If anyone has a bit of time to help out that'd be appreciated! > > > > One higher level architectural question; why is the NM initrd code > > structured as "run once and quit" rather than running as a systemd > > unit, same way as the main OS, and default to having the switchroot > > stop the service? > > Good question. I don't know. Lubomir might know. > > Maybe: if you run it as systemd service, you would need to know when NM > is done with configuration. In main OS, that works by NetworkManager- > wait-online.service. However, that internally uses D-Bus to find out > when NetworkManager is ready. Currently, our main use case for networking in the initrd is Ignition, which just polls in a loop. Explicitly watching NM's status for being online would be a potential optimization, but not necessary. (I think the better way to do this anyways is the code we landed in GLib to monitor netlink for a default route) > But it doesn't seem much of a difference, is it? What would be the > advantage of running NM as a systemd service? Yes, I don't see why that > couldn't be done. There are several advantages, the main reason I'm asking now is avoiding the dracut "initqueue" which is like a weird separate init system glued onto the side. But the general argument here is just having it work the same as the main system. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
NM in the initrd for Fedora CoreOS
I was trying out the current F31 dracut network-manager module, and couldn't get it to do anything useful. See: https://github.com/coreos/fedora-coreos-config/pull/259 If anyone has a bit of time to help out that'd be appreciated! One higher level architectural question; why is the NM initrd code structured as "run once and quit" rather than running as a systemd unit, same way as the main OS, and default to having the switchroot stop the service? ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager dnsmasq plugin and docker
On Sat, May 25, 2019, at 3:35 AM, Till Maas via networkmanager-list wrote: > Hi, > > I am using NetworkManager with dnsmasq with this confguration: > > cat > '/etc/NetworkManager/conf.d/dns.conf' < [main] > dns=dnsmasq > EOF Using podman will help if you're using host networking: https://github.com/containers/libpod/pull/1846 But as I noted in the PR the general case requires some sort of special API between the container and host, I am not aware of anyone working on it at the moment. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: defaulting `rc_manager=symlink` to creating a symlink?
On Wed, Jul 18, 2018, at 4:20 AM, Thomas Haller wrote: > On Tue, 2018-07-17 at 22:32 -0400, Colin Walters wrote: > > See discussion in https://github.com/projectatomic/rpm-ostree/pull/14 > > 64 > > > > Is there a reason that the `symlink` mode doesn't default to creating > > a symlink? It'd help for mounting `/etc` read-only. > > Hi, > > Writing /etc/resolv.conf as symlink, is an action reserved to the > administrator. Right, but I want to do it by default for CoreOS/Silverblue. Remember here we're talking about the case where the file doesn't exist at all. So we either change NM upstream, change the Fedora package, or do: https://github.com/projectatomic/rpm-ostree/pull/1464 OK, I just read the linked bug: https://bugzilla.redhat.com/show_bug.cgi?id=1367551 and I disagree with the rationale but whatever. No point fighting to change the default back globally I guess. Also particularly because at least for single-node systems we should be using a local caching resolver anyways. > Why is there a problem with "mounting `/etc` read-only"? Just try it, add `/etc /etc none bind,ro 0 0` into your `/etc/fstab`, then e.g.: ``` rm /etc/resolv.conf systemctl stop NetworkManager mount /etc systemctl start NetworkManager ``` As expected you won't have an /etc/resolv.conf since NM gets EPERM, which is what's desired here - /etc should be immutable. Anyways I'll argue to merge the rpm-ostree patch based on this discussion - it will create a new distinction between "classic" and "ostree-based" systems, so if anyone wants to use e.g. networkd on e.g. CoreOS/Silverblue they'll have to also run `rm` (how painful!). ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
defaulting `rc_manager=symlink` to creating a symlink?
See discussion in https://github.com/projectatomic/rpm-ostree/pull/1464 Is there a reason that the `symlink` mode doesn't default to creating a symlink? It'd help for mounting `/etc` read-only. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] tree-wide: Cast after g_object_ref() for proposed GLib patch
This fixes the build with https://bugzilla.gnome.org/show_bug.cgi?id=790697
---
libnm-glib/nm-remote-connection.c | 6 +++---
src/settings/plugins/ibft/nms-ibft-plugin.c | 2 +-
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-plugin.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
From 21d75a518e5feaa18e89f53762478f94fbcef233 Mon Sep 17 00:00:00 2001
From: Colin Walters <walt...@verbum.org>
Date: Tue, 5 Dec 2017 10:44:12 -0500
Subject: [PATCH] tree-wide: Cast after g_object_ref() for proposed GLib patch
This fixes the build with https://bugzilla.gnome.org/show_bug.cgi?id=790697
---
libnm-glib/nm-remote-connection.c | 6 +++---
src/settings/plugins/ibft/nms-ibft-plugin.c | 2 +-
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-plugin.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/libnm-glib/nm-remote-connection.c b/libnm-glib/nm-remote-connection.c
index d147365b7..b9abf4c4c 100644
--- a/libnm-glib/nm-remote-connection.c
+++ b/libnm-glib/nm-remote-connection.c
@@ -479,7 +479,7 @@ updated_get_settings_cb (DBusGProxy *proxy,
} else {
gs_unref_object NMConnection *self_alive = NULL;
- self_alive = g_object_ref (self);
+ self_alive = (NMConnection*)g_object_ref (self);
_nm_connection_replace_settings (NM_CONNECTION (self), new_settings);
g_signal_emit (self, signals[UPDATED], 0, new_settings);
g_hash_table_destroy (new_settings);
@@ -611,7 +611,7 @@ init_sync (GInitable *initable, GCancellable *cancellable, GError **error)
G_TYPE_INVALID))
return FALSE;
priv->visible = TRUE;
- self_alive = g_object_ref (initable);
+ self_alive = (NMConnection*)g_object_ref (initable);
_nm_connection_replace_settings (NM_CONNECTION (initable), hash);
g_signal_emit (initable, signals[UPDATED], 0, hash);
g_hash_table_destroy (hash);
@@ -687,7 +687,7 @@ init_get_settings_cb (DBusGProxy *proxy,
}
priv->visible = TRUE;
- self_alive = g_object_ref (init_data->connection);
+ self_alive = (NMConnection*)g_object_ref (init_data->connection);
_nm_connection_replace_settings (NM_CONNECTION (init_data->connection), settings);
g_signal_emit (init_data->connection, signals[UPDATED], 0, settings);
g_hash_table_destroy (settings);
diff --git a/src/settings/plugins/ibft/nms-ibft-plugin.c b/src/settings/plugins/ibft/nms-ibft-plugin.c
index 9b1f5ccd0..77ed12e96 100644
--- a/src/settings/plugins/ibft/nms-ibft-plugin.c
+++ b/src/settings/plugins/ibft/nms-ibft-plugin.c
@@ -202,5 +202,5 @@ settings_plugin_interface_init (NMSettingsPluginInterface *plugin_iface)
G_MODULE_EXPORT GObject *
nm_settings_plugin_factory (void)
{
- return g_object_ref (nms_ibft_plugin_get ());
+ return (GObject*)g_object_ref (nms_ibft_plugin_get ());
}
diff --git a/src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-plugin.c b/src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-plugin.c
index 1ebdeafa7..0c59f32e1 100644
--- a/src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-plugin.c
+++ b/src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-plugin.c
@@ -1079,5 +1079,5 @@ settings_plugin_interface_init (NMSettingsPluginInterface *plugin_iface)
G_MODULE_EXPORT GObject *
nm_settings_plugin_factory (void)
{
- return g_object_ref (settings_plugin_ifcfg_get ());
+ return (GObject*)g_object_ref (settings_plugin_ifcfg_get ());
}
--
2.14.3
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How to force DHCP renew?
On Wed, Oct 4, 2017, at 06:20 PM, Thomas Haller wrote: > NM has a 5 seconds grace period, during which it ignores carrier going > away. It does so because the link can go down unexpectedly for unknown > reasons. > Actually, after NM changes the MTU, the 5 seconds are extended to 10 > seconds, because [1]. > So, kernel would have to bounce the link for at least 10 seconds. > > Then there is a setting ignore-carrier (`man NetworkManager.conf`). > That causes NM to totally ignore when the link goes down. That setting > is quite common, for example on the package "NetworkManager-config- > server" enables it by default on RHEL. Yeah, but I think we could also fix both of those config options for infrastructure cloud case (Azure, GCE, EC2 etc.), and possibly virtualized in general? ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Do not use /etc/resolv.conf symbolic links on SELinux
On Wed, Sep 28, 2016, at 02:06 PM, Guido Trentalancia wrote: > When SELinux is enabled, do not create a symbolic link to a "resolv.conf" > file outside /etc (e.g. in /var/run/NetworkManager), but instead create a > regular file in /etc. > > This is to avoid creating policy permissions to read files in the other > non-standard "resolv.conf" directories for each application that needs to > access the network. Maybe better to: 1) Standardize e.g. `/run/resolv.conf` and have labeling set up for it 2) Change NetworkManager to label the file as `etc_t` which it likely has permission to do so already ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] libnm-glib/libnm/vpn: fix handling of ConnectInteractive() failure (rh #1298732)
I backported this on top of NetworkManager-1.0.6-28, dropped the hunks for -service.c which appear to not exist, re-upgraded to NetworkManager-vpnc-1.0.8-1.el7.x86_64, and connected to my VPN successfully. Thanks! Tested-by: Colin Walters <walt...@verbum.org> ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 1/1] logging: change logging format to drop "[file:line] func():" part
On Thu, Feb 25, 2016, at 11:21 AM, Thomas Haller wrote: > Choose a new logging format. > > - the logging format must not be configurable and it must be the > same for all backends. It is neat that journal supports additional > fields, but an average user still posts the output of plain > journalctl, without "--output verbose" (which would also be hard > to read). > Also, we get used to a certain logging format, so having different > formats is confusing. If one format is better then another, it should > be used for all backends: syslog, journal and debug. > The only question is, what is the best format. Not sure I'd agree with that. Personally when I'm trying to debug/administrate a system and look at `journalctl` I find it rather annoying when a lot of space is taken up by programs redundantly adding things like timestamp, log level, program name etc to the text, when the journal is recording all of that anyways. Probably journalctl could learn --output longer or something which would include say CODE_FILE and CODE_LINE but not all of the redundant stuff like BOOT_ID. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 1/1] platform: optimize sysctl_set() to use stack allocated buffer
On Tue, Feb 23, 2016, at 05:54 PM, Thomas Haller wrote: > The value written to sysctl is usually a short string. It makes sense > to optimize for this case and avoid allocating a temporary string > on the heap. Hey, so a while ago I was pushing for NetworkManager to use libgsystem, which then got backed out in favor of just copying the local alloc macros. Since then, I've introduced "libglnx", its successor: https://git.gnome.org/browse/libglnx It'd likely be a good match for NetworkManager too, as this time it's *only* a git submodule. It also has backported local alloc macros. Now, the reason I'm mentioning this in reply to this message is that part of libglnx is shamelessly cloning some of the good parts of libsystemd-shared, and specifically in this case: https://git.gnome.org/browse/libglnx/tree/glnx-alloca.h?id=8a7943fef6061a4e9ca368e0042a8a3924affb99#n28 which avoids the hand-rolled string offset handling. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH v2 1/2] Allow building without gtk-doc installed
On Thu, Jun 25, 2015, at 04:57 AM, Lubomir Rintel wrote: This doesn't look good to me. autogen.sh is a maintainer tool and we pretty much always want to create tarballs with GTK-doc. FWIW glib supports this: https://git.gnome.org/browse/glib/tree/autogen.sh ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: broken build: would be good to announce new hard dependencies on the mailing list
On Fri, Feb 14, 2014 at 8:58 AM, Pavel Simerda psime...@redhat.com wrote: I'm curious whether Colin's ostree CI build was ready for the change. Yep, I'd had it split off for quite a while: https://git.gnome.org/browse/gnome-continuous/tree/manifest.json#n447 ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: discuss: NM server defaults
On Mon, 2013-07-08 at 12:47 -0400, Dan Winship wrote: On 07/01/2013 04:14 PM, Dan Winship wrote: danw, any rationale behind the argument for ignore-carrier? Servers, by definition, tend to have fixed IP addresses. Therefore, if you are using DHCP on a server, it's probably for ease of deployment, not because you want dynamism. Any response to this theory? So currently I am thinking for 0.9.10: - flip the default value of monitor-connection-files from true to false for all users, not just server (with a release note) This is a change with the potential to confuse admins temporarily, but I think we should do it. Experience has shown me that while using inotify sounds nice, in practice, it ends up being unpredictable. Notably it makes it impossible to apply changes to multiple files without transiently exposing half-done configuration. - ship a server.conf with: no-auto-default=* This one is the most important. ignore-carrier=* This one I'm still uncertain about... And for future: - further improve the ignore-carrier/DHCP behavior, so that if an ignore-carrier device comes up, and it *does* have an active DHCP connection, we renew the lease without taking the device down. This logic sounds fairly sane though. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: discuss: NM server defaults
On Mon, 2013-07-01 at 15:32 -0400, Pavel Simerda wrote: In my opinion, the default is to treat DHCP connections as fully dynamic on servers as well as on laptops. In other words, a vote against ignore-carrier=* being the default. I think I agree with you - if you're using DHCP, I'd expect things to be more dynamic. danw, any rationale behind the argument for ignore-carrier? ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: discuss: NM server defaults
On Thu, 2013-06-27 at 11:34 -0400, Pavel Simerda wrote: - Original Message - From: Colin Walters walt...@verbum.org To: networkmanager-list@gnome.org Sent: Wednesday, June 26, 2013 4:25:31 PM Subject: discuss: NM server defaults So I filed this downstream: https://bugzilla.redhat.com/show_bug.cgi?id=978081 I think it might be useful to consider this upstream as well. Yep, see: http://cgit.freedesktop.org/~walters/NetworkManager/commit/?h=wip/serverconf Sounds like a useful default for specific class of usage. I, personally, would prefer the server to react on carrier at least when using DHCP. So both you and danw didn't say *why*. My guess here is that in a server situation, we don't want to down the interface and request a new DHCP lease for a brief cable plug + unplug? If an admin accidentally unplugs the wrong one? So this might actually be an area where we as developers don't know yet whether it is preferable and by which groups of people. Right, that's the goal of this thread. Review of above branch appreciated. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
discuss: NM server defaults
So I filed this downstream: https://bugzilla.redhat.com/show_bug.cgi?id=978081 But it seems like something worth talking about here. We could easily maintain nm-server-defaults.conf in the upstream git repo, at least. We could also add --enable-server-defaults as a build time option, for OS builders that do servers and clients as separate builds from source instead of packages. Collecting some comments from IRC: danw we'll probably want ignore-carrier=* too ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] nm-device: Remove bogus warning
On Wed, 2013-06-19 at 08:11 -0500, Dan Williams wrote:
It's more there because it's potentially a bug
Ok, the logic seems odd because we're doing effectively:
if (condition)
{
if (condition)
warning ();
deal_with_it ();
}
If the code had looked like:
if (condition)
{
g_warn_if_reached ();
deal_with_it ();
}
it would have made more sense to me.
What are you seeing it for?
It always fires for me starting NM git master in my Fedora 19 test VM;
it doesn't for you?
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] nm-device: Remove bogus warning
Ok, how about this patch?
From ab22ffd804ba7e91bd6d064cbf5627ab03981c3b Mon Sep 17 00:00:00 2001
From: Colin Walters walt...@verbum.org
Date: Wed, 19 Jun 2013 14:56:26 -0400
Subject: [PATCH] device: Queuing two transitions to the same state is not an error
Just ignore this, since it happens in the current code and is
harmless. While we're here, improve the warning in the case where it
does occur to say whiich state we're overwriting. This should help
debug any future cases.
---
src/devices/nm-device.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/src/devices/nm-device.c b/src/devices/nm-device.c
index 0d741c6..dab951c 100644
--- a/src/devices/nm-device.c
+++ b/src/devices/nm-device.c
@@ -5587,7 +5587,12 @@ nm_device_queue_state (NMDevice *self,
/* We should only ever have one delayed state transition at a time */
if (priv-queued_state.id) {
- g_warn_if_fail (priv-queued_state.id == 0);
+ if (priv-queued_state.state == state)
+ return;
+ nm_log_warn (LOGD_DEVICE, (%s): overwriting previously queued state change to %s (%s),
+ nm_device_get_iface (self),
+ state_to_string (priv-queued_state.state),
+ reason_to_string (priv-queued_state.reason));
nm_device_queued_state_clear (self);
}
@@ -5595,8 +5600,8 @@ nm_device_queue_state (NMDevice *self,
priv-queued_state.reason = reason;
priv-queued_state.id = g_idle_add (queued_set_state, self);
- nm_log_dbg (LOGD_DEVICE, (%s): queued state change to %s (id %d),
- nm_device_get_iface (self), state_to_string (state),
+ nm_log_dbg (LOGD_DEVICE, (%s): queued state change to %s due to %s (id %d),
+ nm_device_get_iface (self), state_to_string (state), reason_to_string (reason),
priv-queued_state.id);
}
--
1.7.1
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] nm-device: Remove bogus warning
This code was broken when it landed with commit
fcc441622ae2632b9b36f352621cfd3baf34dc85 ; it was then later
updated with 2318b3c5252403a52973eae70c32ff715c7994e7
But the assertion is just clearly wrong - if we're going to clear the
previously queued state transition anyways, let's stop warning about
it.
---
src/devices/nm-device.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
From b485ce2c58e7d474392e8987fb834762beecc3ed Mon Sep 17 00:00:00 2001
From: Colin Walters walt...@verbum.org
Date: Tue, 18 Jun 2013 16:44:18 -0400
Subject: [PATCH] nm-device: Remove bogus warning
This code was broken when it landed with commit
fcc441622ae2632b9b36f352621cfd3baf34dc85 ; it was then later
updated with 2318b3c5252403a52973eae70c32ff715c7994e7
But the assertion is just clearly wrong - if we're going to clear the
previously queued state transition anyways, let's stop warning about
it.
---
src/devices/nm-device.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/src/devices/nm-device.c b/src/devices/nm-device.c
index 0d741c6..dedc1e4 100644
--- a/src/devices/nm-device.c
+++ b/src/devices/nm-device.c
@@ -5587,7 +5587,6 @@ nm_device_queue_state (NMDevice *self,
/* We should only ever have one delayed state transition at a time */
if (priv-queued_state.id) {
- g_warn_if_fail (priv-queued_state.id == 0);
nm_device_queued_state_clear (self);
}
--
1.7.1
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] main() init cleanups, logging improvements
See this series: http://cgit.freedesktop.org/~walters/NetworkManager/commit/?h=wip/main-ordering The first few commits are just minor cleanups. The important commit of the series is: http://cgit.freedesktop.org/~walters/NetworkManager/commit/?h=wip/main-orderingid=bd782ec13c831f8040286260cfa0b65a1b0f13d9 The last commit is just a useful log message improvement. The overall goal was: Basically, this allows us to log messages about config file parsing and such, which *greatly* helps with debugging. i.e. you can use nm_log_dbg() inside nm-config.c. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] build: Remove libndp for now
On Thu, 2013-06-13 at 10:29 -0300, Dan Winship wrote: OK, these patches (danw/ndpfix branch) make it not install libndp when building it from source, and make it possible to use a system libndp instead. Ugly =/ But it looks like it will work. If the long term plan is that libndp is a system dependency, and this is just a temporary hack, then I'm fine with it. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] build: Remove libndp for now
On Thu, 2013-06-13 at 10:29 -0300, Dan Winship wrote: OK, these patches (danw/ndpfix branch) make it not install libndp when building it from source, and make it possible to use a system libndp instead. I added the libndp git repo to the gnome-ostree manifest and tested a build with these patches. We still do the AC_CONFIG_SUBDIRS even if we find the system libndp, which is harmless but ugly. Also, you should be using AS_IF() for new configure code: https://bugzilla.gnome.org/show_bug.cgi?id=681413 ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] build: Remove libndp for now
It's installing itself into $(prefix), whereas we need a private library in $(pkglibdir). I think libgsystem is a pretty good example of a useful git submodule; it's designed for nonrecursive automake; it provides a Makefile-libgsystem.am that one can include, but doesn't force the use of SUBDIRS and particularly that the *containing* module does e.g. include libgsystem/Makefile-libgsystem.am pkglibdir_LTLIBRARIES += libgsystem.la So the containing module is choosing where to install. --- .gitmodules |3 --- Makefile.am |1 - configure.ac |1 - libndp |1 - 4 files changed, 0 insertions(+), 6 deletions(-) delete mode 16 libndp From 36d83e054b8bf90dc8b0e820617e3ff17f134ba7 Mon Sep 17 00:00:00 2001 From: Colin Walters walt...@verbum.org Date: Wed, 12 Jun 2013 08:36:29 -0400 Subject: [PATCH] build: Remove libndp for now It's installing itself into $(prefix), whereas we need a private library in $(pkglibdir). I think libgsystem is a pretty good example of a useful git submodule; it's designed for nonrecursive automake; it provides a Makefile-libgsystem.am that one can include, but doesn't force the use of SUBDIRS and particularly that the *containing* module does e.g. include libgsystem/Makefile-libgsystem.am pkglibdir_LTLIBRARIES += libgsystem.la So the containing module is choosing where to install. --- .gitmodules |3 --- Makefile.am |1 - configure.ac |1 - libndp |1 - 4 files changed, 0 insertions(+), 6 deletions(-) delete mode 16 libndp diff --git a/.gitmodules b/.gitmodules index c31ff2a..e93bbea 100644 --- a/.gitmodules +++ b/.gitmodules @@ -1,6 +1,3 @@ [submodule libgsystem] path = libgsystem url = git://git.gnome.org/libgsystem -[submodule libndp] - path = libndp - url = git://github.com/jpirko/libndp.git diff --git a/Makefile.am b/Makefile.am index 3fcc135..9976a2a 100644 --- a/Makefile.am +++ b/Makefile.am @@ -6,7 +6,6 @@ SUBDIRS = \ libnm-util \ libnm-glib \ introspection \ - libndp \ src \ callouts \ cli \ diff --git a/configure.ac b/configure.ac index 51f4aec..4f1649f 100644 --- a/configure.ac +++ b/configure.ac @@ -715,7 +715,6 @@ examples/C/qt/Makefile examples/dispatcher/Makefile vapi/Makefile ]) -AC_CONFIG_SUBDIRS([libndp]) AC_OUTPUT # Print build configuration diff --git a/libndp b/libndp deleted file mode 16 index 39e1f53..000 --- a/libndp +++ /dev/null @@ -1 +0,0 @@ -Subproject commit 39e1f53dd4efc00b84ff097b15558747c92593f2 -- 1.7.1 ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Add libgsystem as a git submodule
On Wed, 2013-05-22 at 08:55 +0200, Jirka Klimes wrote: +#endif /* __LIBGSYSTEM_GLIB_COMPAT__ */ Hum, I must have failed to actually apply the patch to NM's copy of libgsystem. Regardless, pushed, thanks! ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Add libgsystem as a git submodule
On Tue, 2013-05-21 at 09:08 +0200, Jirka Klimes wrote: CC libgsystem_la-gsystem-file-utils.lo libgsystem/gsystem-file-utils.c: In function 'linkcopy_internal_attempt': libgsystem/gsystem-file-utils.c:358:3: error: implicit declaration of function 'g_clear_pointer' [-Werror=implicit-function-declaration] cc1: all warnings being treated as errors Can you try with https://git.gnome.org/browse/libgsystem/commit/?id=759384420c1578bf399473440ab34af18fa46b8d ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Add libgsystem as a git submodule
On Fri, 2013-05-17 at 15:05 -0400, Pavel Simerda wrote:
Any more resources/documentation/posts for that?
Look at the attached patch as a demo. Results:
bash-4.2# journalctl NM_IFACE=eth0
-- Logs begin at Mon 2013-03-25 18:35:24 EDT, end at Fri 2013-05-17 16:31:52
EDT. --
May 17 16:31:18 qemux86-64 NetworkManager[327]: Bound interface eth0
bash-4.2#
As a side note, in future, I'll be adding a dependency on Jiří Pírko's libndp
Link?
From f5554e5371b27c564b0e248d6ccefd9da4176916 Mon Sep 17 00:00:00 2001
From: Colin Walters walt...@verbum.org
Date: Fri, 17 May 2013 16:35:14 -0400
Subject: [PATCH] Demo structured logging
---
configure.ac | 11 +++
src/Makefile.am |3 +++
src/dhcp-manager/nm-dhcp-client.c | 10 ++
3 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index 43e420f..d7641fa 100644
--- a/configure.ac
+++ b/configure.ac
@@ -291,6 +291,17 @@ if test $with_session_tracking = consolekit; then
fi
AC_MSG_RESULT($with_session_tracking)
+AC_ARG_WITH(systemd-journal,
+ AS_HELP_STRING([--without-systemd-journal], [Use systemd @:@default=auto@:@]),
+ [], [with_systemd_journal=auto])
+AS_IF([test x$with_systemd_journal != xno], [
+ PKG_CHECK_MODULES([SYSTEMD_JOURNAL], [libsystemd-journal = 200], have_systemd_journal=yes, have_systemd_journal=no)
+ ])
+AM_CONDITIONAL(ENABLE_SYSTEMD_JOURNAL, test x$have_systemd_journal = xyes)
+AS_IF([test x$have_systemd_journal = xyes], [
+ AC_DEFINE([ENABLE_SYSTEMD_JOURNAL],[1],[Define if you want to build with systemd journal support])
+])
+
AC_ARG_WITH(suspend-resume, AS_HELP_STRING([--with-suspend-resume=upower|systemd], [Build NetworkManager with specific suspend/resume support]))
if test z$with_suspend_resume = z; then
PKG_CHECK_EXISTS([libsystemd-login = 183], [have_systemd_inhibit=yes], [have_systemd_inhibit=no])
diff --git a/src/Makefile.am b/src/Makefile.am
index d34e911..b7b49ef 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -345,6 +345,7 @@ AM_CPPFLAGS = \
$(MM_GLIB_CFLAGS) \
$(POLKIT_CFLAGS) \
$(SYSTEMD_LOGIN_CFLAGS) \
+ $(SYSTEMD_JOURNAL_CFLAGS) \
\
-DBINDIR=\$(bindir)\ \
-DDATADIR=\$(datadir)\ \
@@ -375,6 +376,7 @@ libNetworkManager_la_SOURCES = \
libNetworkManager_la_LIBADD = \
$(top_builddir)/libnm-util/libnm-util.la \
+ $(top_builddir)/libgsystem.la \
$(BLUEZ_LIBS) \
$(DBUS_LIBS) \
$(GLIB_LIBS) \
@@ -383,6 +385,7 @@ libNetworkManager_la_LIBADD = \
$(MM_GLIB_LIBS) \
$(POLKIT_LIBS) \
$(SYSTEMD_LOGIN_LIBS) \
+ $(SYSTEMD_JOURNAL_LIBS) \
$(LIBDL) \
$(LIBM)
diff --git a/src/dhcp-manager/nm-dhcp-client.c b/src/dhcp-manager/nm-dhcp-client.c
index e6c36e9..17d70e7 100644
--- a/src/dhcp-manager/nm-dhcp-client.c
+++ b/src/dhcp-manager/nm-dhcp-client.c
@@ -32,6 +32,7 @@
#include nm-logging.h
#include nm-dbus-glib-types.h
#include nm-dhcp-client.h
+#include libgsystem.h
typedef struct {
char * iface;
@@ -728,6 +729,15 @@ nm_dhcp_client_new_options (NMDHCPClient *self,
if (state_is_bound (new_state)) {
/* Cancel the timeout if the DHCP client is now bound */
timeout_cleanup (self);
+ {
+ #define BOUND_IFACE_MSGID bc498d9d08dfdda9432d74a6737ac73e
+ gs_free char *iface_key = g_strconcat (NM_IFACE=, priv-iface);
+ gs_free char *msg = g_strdup_printf (Bound interface %s, priv-iface);
+ char *keys[] = { MESSAGE_ID= BOUND_IFACE_MSGID,
+ iface_key,
+ NULL };
+ gs_log_structured (msg, keys);
+ }
}
if (priv-ipv6) {
--
1.7.1
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Add libgsystem as a git submodule
On Fri, 2013-05-17 at 19:44 -0400, Pavel Simerda wrote: From: Colin Walters walt...@verbum.org On Fri, 2013-05-17 at 15:05 -0400, Pavel Simerda wrote: Any more resources/documentation/posts for that? Look at the attached patch as a demo. Ah, interesting. Is it capable of working without systemd at least to the level of using syslog and/org stderr? Yes, it just prints to stdout on non-systemd, though I'd definitely consider adding the ability to do syslog instead of stdout. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 2/2] core: runtime detect logind and ConsoleKit
On Tue, 2013-04-16 at 07:05 +0100, Fabio Erculiani wrote: If --with-session-tracking=systemd, but logind is not currently running, the code now falls back to ConsoleKit. This is particularly useful for covering the interim, while waiting for distros to abandon ConsoleKit completely. There's lots of reimplementations of things like this; polkit has one, gnome-session has one. It'd be a lot nicer if it was refactored into something copypaste-able. It looks like you're not deleting nm-session-monitor-ck.c, but it's unused? I find the #ifdef approach a bit ugly; it'd be more elegant to have real GObjects and have an egg_session_monitor_get() which checks for logind exactly once, and returns an instance of EggSessionMonitorSystemd or EggSessionMonitorCK as appropriate, rather than constantly checking and having the code for both rolled together. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Add libgsystem as a git submodule
On Mon, 2013-05-06 at 12:50 -0500, Dan Williams wrote: On Fri, 2013-04-26 at 16:42 -0400, Colin Walters wrote: And change src/main.c to use the local allocation macros. This results in much cleaner code, as one can see from the diff. Because libgsystem is designed for nonrecursive make, it fits best in the current recursive setup if we build . first. This will be a lot nicer when we switch NM to a nonrecursive setup. --- .gitmodules |3 +++ Makefile.am |7 +++ libgsystem |1 + src/Makefile.am |2 ++ src/main.c | 50 -- 5 files changed, 25 insertions(+), 38 deletions(-) create mode 100644 .gitmodules create mode 16 libgsystem Patch looks good to me; Pavel, I'll assume you acked it too, given you had objections last time? Any thoughts, Pavel? ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] Use g_cclosure_marshal_generic
This Just Works(tm). However, there is one ugly part worth calling out - we're still calling dbus_g_object_register_marshaller(). In the future, that won't be necessary with: See https://bugs.freedesktop.org/show_bug.cgi?id=64214 --- .gitignore |1 - src/bluez-manager/nm-bluez-device.c |3 +-- src/bluez-manager/nm-bluez-manager.c |5 ++--- src/dhcp-manager/nm-dhcp-manager.c |1 - src/generated/Makefile.am|7 +-- src/ip6-manager/nm-ip6-manager.c |5 ++--- src/modem-manager/nm-modem-generic.c |3 +-- src/modem-manager/nm-modem-manager.c |3 +-- src/modem-manager/nm-modem.c |7 +++ src/nm-dbus-manager.c|9 - src/nm-device-bt.c |5 ++--- src/nm-device-modem.c|1 - src/nm-device-wifi.c |3 +-- src/nm-device.c | 11 +-- src/nm-manager.c |3 +-- src/nm-udev-manager.c|5 ++--- src/platform/nm-platform.c |3 +-- src/ppp-manager/nm-ppp-manager.c |5 ++--- src/settings/nm-default-wired-connection.c |1 - src/settings/nm-inotify-helper.c |3 +-- src/settings/nm-settings-connection.c|1 - src/supplicant-manager/nm-supplicant-interface.c | 17 - src/vpn-manager/nm-vpn-connection.c |5 ++--- src/vpn-manager/nm-vpn-manager.c |1 - 24 files changed, 40 insertions(+), 68 deletions(-) From d3df947623f1f2d8487f0792a3e0981228e1ae89 Mon Sep 17 00:00:00 2001 From: Colin Walters walt...@verbum.org Date: Wed, 8 May 2013 08:53:59 -0400 Subject: [PATCH] Use g_cclosure_marshal_generic This Just Works(tm). However, there is one ugly part worth calling out - we're still calling dbus_g_object_register_marshaller(). In the future, that won't be necessary with: See https://bugs.freedesktop.org/show_bug.cgi?id=64214 --- .gitignore |1 - src/bluez-manager/nm-bluez-device.c |3 +-- src/bluez-manager/nm-bluez-manager.c |5 ++--- src/dhcp-manager/nm-dhcp-manager.c |1 - src/generated/Makefile.am|7 +-- src/ip6-manager/nm-ip6-manager.c |5 ++--- src/modem-manager/nm-modem-generic.c |3 +-- src/modem-manager/nm-modem-manager.c |3 +-- src/modem-manager/nm-modem.c |7 +++ src/nm-dbus-manager.c|9 - src/nm-device-bt.c |5 ++--- src/nm-device-modem.c|1 - src/nm-device-wifi.c |3 +-- src/nm-device.c | 11 +-- src/nm-manager.c |3 +-- src/nm-udev-manager.c|5 ++--- src/platform/nm-platform.c |3 +-- src/ppp-manager/nm-ppp-manager.c |5 ++--- src/settings/nm-default-wired-connection.c |1 - src/settings/nm-inotify-helper.c |3 +-- src/settings/nm-settings-connection.c|1 - src/supplicant-manager/nm-supplicant-interface.c | 17 - src/vpn-manager/nm-vpn-connection.c |5 ++--- src/vpn-manager/nm-vpn-manager.c |1 - 24 files changed, 40 insertions(+), 68 deletions(-) diff --git a/.gitignore b/.gitignore index 3b9d587..8c8da45 100644 --- a/.gitignore +++ b/.gitignore @@ -160,7 +160,6 @@ libnm-glib/libnm-glib-test libnm-glib/nm-glib-marshal.* src/NetworkManager src/nm-crash-logger -src/generated/nm-marshal.* src/supplicant-manager/tests/test-supplicant-config src/dhcp-manager/nm-dhcp-helper system-settings/src diff --git a/src/bluez-manager/nm-bluez-device.c b/src/bluez-manager/nm-bluez-device.c index b12a861..9b593a4 100644 --- a/src/bluez-manager/nm-bluez-device.c +++ b/src/bluez-manager/nm-bluez-device.c @@ -31,7 +31,6 @@ #include nm-bluez-common.h #include nm-dbus-glib-types.h #include nm-logging.h -#include nm-marshal.h G_DEFINE_TYPE (NMBluezDevice, nm_bluez_device, G_TYPE_OBJECT) @@ -424,7 +423,7 @@ nm_bluez_device_new (const char *path, NMConnectionProvider *provider) BLUEZ_DEVICE_INTERFACE); g_object_unref (dbus_mgr); - dbus_g_object_register_marshaller (_nm_marshal_VOID__STRING_BOXED, + dbus_g_object_register_marshaller (NULL, G_TYPE_NONE, G_TYPE_STRING, G_TYPE_VALUE, G_TYPE_INVALID
Re: [PATCH] Use g_cclosure_marshal_generic
On Wed, 2013-05-08 at 09:22 -0400, Dan Winship wrote: Oh, I just did this too as part of the danw/movedevs branch... -dbus_g_object_register_marshaller (_nm_marshal_VOID__STRING_BOXED, +dbus_g_object_register_marshaller (NULL, Does that work? From what I can see in the dbus-glib source code, it seems like you would need to pass g_cclosure_marshal_generic explicitly, not NULL. My read of the source agrees; I suspect I simply didn't hit any of these in my testing (boot gnome-ostree buildmaster in a VM). I'll update the patch. But if someone reviews my dbus-glib patch, that'd be awesome, so we can eventually depend on it. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Add libgsystem as a git submodule
On Fri, 2013-04-26 at 16:42 -0400, Colin Walters wrote: And change src/main.c to use the local allocation macros. This results in much cleaner code, as one can see from the diff. Because libgsystem is designed for nonrecursive make, it fits best in the current recursive setup if we build . first. This will be a lot nicer when we switch NM to a nonrecursive setup. Any opinions on this? ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] Add libgsystem as a git submodule
And change src/main.c to use the local allocation macros. This
results in much cleaner code, as one can see from the diff.
Because libgsystem is designed for nonrecursive make, it fits best in
the current recursive setup if we build . first. This will be a lot
nicer when we switch NM to a nonrecursive setup.
---
.gitmodules |3 +++
Makefile.am |7 +++
libgsystem |1 +
src/Makefile.am |2 ++
src/main.c | 50 --
5 files changed, 25 insertions(+), 38 deletions(-)
create mode 100644 .gitmodules
create mode 16 libgsystem
From 1bf944af8a321cebe2ddc45d0649f744c8828bab Mon Sep 17 00:00:00 2001
From: Colin Walters walt...@verbum.org
Date: Fri, 26 Apr 2013 16:20:22 -0400
Subject: [PATCH] Add libgsystem as a git submodule
And change src/main.c to use the local allocation macros. This
results in much cleaner code, as one can see from the diff.
Because libgsystem is designed for nonrecursive make, it fits best in
the current recursive setup if we build . first. This will be a lot
nicer when we switch NM to a nonrecursive setup.
---
.gitmodules |3 +++
Makefile.am |7 +++
libgsystem |1 +
src/Makefile.am |2 ++
src/main.c | 50 --
5 files changed, 25 insertions(+), 38 deletions(-)
create mode 100644 .gitmodules
create mode 16 libgsystem
diff --git a/.gitmodules b/.gitmodules
new file mode 100644
index 000..e93bbea
--- /dev/null
+++ b/.gitmodules
@@ -0,0 +1,3 @@
+[submodule libgsystem]
+ path = libgsystem
+ url = git://git.gnome.org/libgsystem
diff --git a/Makefile.am b/Makefile.am
index 2847616..9419d35 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1,6 +1,7 @@
include $(GLIB_MAKEFILE)
SUBDIRS = \
+ . \
include \
libnm-util \
libnm-glib \
@@ -53,3 +54,9 @@ CLEANFILES = cscope.in.out cscope.out cscope.po.out
.PHONY: cscope
cscope:
cscope -b -q -R -Iinclude -ssrc -slibnm-glib -slibnm-util -scli/src;
+
+libgsystem_srcpath := libgsystem
+libgsystem_cflags := $(GLIB_CFLAGS) -I$(srcdir)/libgsystem
+libgsystem_libs = $(GLIB_LIBS)
+include libgsystem/Makefile-libgsystem.am
+noinst_LTLIBRARIES = libgsystem.la
diff --git a/libgsystem b/libgsystem
new file mode 16
index 000..51736db
--- /dev/null
+++ b/libgsystem
@@ -0,0 +1 @@
+Subproject commit 51736db5f49b4b798fd2f9d0ccb8eff453105162
diff --git a/src/Makefile.am b/src/Makefile.am
index 113b527..f81c37a 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -26,6 +26,7 @@ endif
SUBDIRS += . tests
INCLUDES = -I${top_srcdir} \
+ -I${top_srcdir}/libgsystem \
-I${top_builddir}/include \
-I${top_srcdir}/include \
-I${top_builddir}/src/generated \
@@ -324,6 +325,7 @@ NetworkManager_CPPFLAGS += -DCKDB_PATH=\${CKDB_PATH}\
endif
NetworkManager_LDADD = \
+ $(top_builddir)/libgsystem.la \
./generated/libnm-generated.la \
./logging/libnm-logging.la \
./config/libnm-config.la \
diff --git a/src/main.c b/src/main.c
index ed71bb6..37e05c4 100644
--- a/src/main.c
+++ b/src/main.c
@@ -38,6 +38,7 @@
#include gmodule.h
#include string.h
+#include gsystem-local-alloc.h
#include NetworkManager.h
#include NetworkManagerUtils.h
#include nm-manager.h
@@ -305,18 +306,19 @@ main (int argc, char *argv[])
GOptionContext *opt_ctx = NULL;
gboolean become_daemon = FALSE;
gboolean g_fatal_warnings = FALSE;
- char *pidfile = NULL, *state_file = NULL;
+ gs_free char *pidfile = NULL;
+ gs_free char *state_file = NULL;
gboolean wifi_enabled = TRUE, net_enabled = TRUE, wwan_enabled = TRUE, wimax_enabled = TRUE;
gboolean success, show_version = FALSE;
NMPolicy *policy = NULL;
- NMVPNManager *vpn_manager = NULL;
- NMDnsManager *dns_mgr = NULL;
- NMDBusManager *dbus_mgr = NULL;
- NMSupplicantManager *sup_mgr = NULL;
- NMDHCPManager *dhcp_mgr = NULL;
- NMFirewallManager *fw_mgr = NULL;
- NMSettings *settings = NULL;
- NMConfig *config;
+ gs_unref_object NMVPNManager *vpn_manager = NULL;
+ gs_unref_object NMDnsManager *dns_mgr = NULL;
+ gs_unref_object NMDBusManager *dbus_mgr = NULL;
+ gs_unref_object NMSupplicantManager *sup_mgr = NULL;
+ gs_unref_object NMDHCPManager *dhcp_mgr = NULL;
+ gs_unref_object NMFirewallManager *fw_mgr = NULL;
+ gs_unref_object NMSettings *settings = NULL;
+ gs_unref_object NMConfig *config = NULL;
GError *error = NULL;
gboolean wrote_pidfile = FALSE;
@@ -579,41 +581,13 @@ done:
if (policy)
nm_policy_destroy (policy);
- if (manager)
- g_object_unref (manager);
-
- if (settings)
- g_object_unref (settings);
-
- if (vpn_manager)
- g_object_unref (vpn_manager);
-
- if (dns_mgr)
- g_object_unref (dns_mgr);
-
- if (dhcp_mgr)
- g_object_unref (dhcp_mgr);
-
- if (sup_mgr)
- g_object_unref (sup_mgr);
-
- if (fw_mgr)
- g_object_unref (fw_mgr);
-
- if (dbus_mgr)
- g_object_unref (dbus_mgr);
+ g_clear_object (manager);
nm_logging_shutdown ();
if (pidfile wrote_pidfile
Re: [PATCH] man: Rewrite NetworkManager.8 and NetworkManager.conf.5 in DocBook
On Wed, 2013-04-10 at 12:25 -0500, Dan Williams wrote: Though now that I look again, where does docbook.xsl come from, and is that going to be available when there's no network? Does xsltproc look in some local cache before hitting a network for the .xsl? Yes, there's this elaborate catalog system for caching locally; see /etc/xml/catalog. In this particular case it's a string match on !DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook XML ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] man: Rewrite NetworkManager.8 and NetworkManager.conf.5 in DocBook
DocBook is not my favorite thing in the world, but it's lots-of-emphasisfar/lots-of-emphasis saner than troff. Some style parts cribbed from systemd. This is preparatory work for actually improving the content of the man pages. --- configure.ac |2 - man/Makefile.am | 16 ++ man/NetworkManager.8.in | 145 - man/NetworkManager.conf.5.in | 310 man/NetworkManager.conf.xml | 362 ++ man/NetworkManager.xml | 223 ++ 6 files changed, 601 insertions(+), 457 deletions(-) delete mode 100644 man/NetworkManager.8.in delete mode 100644 man/NetworkManager.conf.5.in create mode 100644 man/NetworkManager.conf.xml create mode 100644 man/NetworkManager.xml From d6c878114d0088ff1a313b52f08e40c011bc1e2f Mon Sep 17 00:00:00 2001 From: Colin Walters walt...@verbum.org Date: Tue, 9 Apr 2013 16:41:00 -0400 Subject: [PATCH] man: Rewrite NetworkManager.8 and NetworkManager.conf.5 in DocBook DocBook is not my favorite thing in the world, but it's lots-of-emphasisfar/lots-of-emphasis saner than troff. Some style parts cribbed from systemd. This is preparatory work for actually improving the content of the man pages. --- configure.ac |2 - man/Makefile.am | 16 ++ man/NetworkManager.8.in | 145 - man/NetworkManager.conf.5.in | 310 man/NetworkManager.conf.xml | 362 ++ man/NetworkManager.xml | 223 ++ 6 files changed, 601 insertions(+), 457 deletions(-) delete mode 100644 man/NetworkManager.8.in delete mode 100644 man/NetworkManager.conf.5.in create mode 100644 man/NetworkManager.conf.xml create mode 100644 man/NetworkManager.xml diff --git a/configure.ac b/configure.ac index 034bd68..fb2e118 100644 --- a/configure.ac +++ b/configure.ac @@ -706,8 +706,6 @@ initscript/linexa/networkmanager introspection/Makefile introspection/all.xml man/Makefile -man/NetworkManager.8 -man/NetworkManager.conf.5 man/nm-system-settings.conf.5 man/nm-online.1 man/nmcli.1 diff --git a/man/Makefile.am b/man/Makefile.am index 7db5623..fdf2041 100644 --- a/man/Makefile.am +++ b/man/Makefile.am @@ -14,6 +14,22 @@ nm-settings.xml: $(top_builddir)/tools/generate-settings-spec $(top_builddir)/li $(top_builddir)/tools/generate-settings-spec refentry $(builddir)/$@ CLEANFILES += nm-settings.xml +XSLTPROC_FLAGS = \ +--nonet \ +--stringparam man.output.quietly 1 \ +--stringparam funcsynopsis.style ansi \ +--stringparam man.th.extra1.suppress 1 \ +--stringparam man.authors.section.enabled 0 \ +--stringparam man.copyright.section.enabled 0 + +XSLTPROC_MAN_FLAGS = $(XSLTPROC_FLAGS) http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl + +%.8: %.xml + $(AM_V_GEN) xsltproc $(XSLTPROC_MAN_FLAGS) $ + +%.5: %.xml + $(AM_V_GEN) xsltproc $(XSLTPROC_MAN_FLAGS) $ + man_MANS +=\ NetworkManager.8 \ NetworkManager.conf.5 \ diff --git a/man/NetworkManager.8.in b/man/NetworkManager.8.in deleted file mode 100644 index 38a195f..000 --- a/man/NetworkManager.8.in +++ /dev/null @@ -1,145 +0,0 @@ -.\ NetworkManager(8) manual page -.\ -.\ Copyright (C) 2005 - 2013 Red Hat, Inc. -.\ Copyright (C) 2005 - 2009 Novell, Inc. -.\ Copyright (C) 2005 Robert Love -.\ -.TH NETWORKMANAGER 8 17 January 2012 -.SH NAME -NetworkManager \- network management daemon -.SH SYNOPSIS -.B NetworkManager [\-\-version] | [\-\-help] -.PP -.B NetworkManager [\-\-no\-daemon] [\-\-pid\-file=filename] [\-\-state\-file=filename] [\-\-config=filename] [\-\-config-dir=directory] [\-\-plugins=plugin1,plugin2,...] [\-\-log\-level=level] [\-\-log\-domains=domain1,domain2,...] -.SH DESCRIPTION -The \fINetworkManager\fP daemon attempts to make networking configuration and -operation as painless and automatic as possible by managing the primary network -connection and other network interfaces, like Ethernet, WiFi, and Mobile -Broadband devices. NetworkManager will connect any network device when a -connection for that device becomes available, unless that behavior is disabled. -Information about networking is exported via a D-Bus interface to any interested -application, providing a rich API with which to inspect and control network -settings and operation. -.P -NetworkManager will execute scripts in the /etc/NetworkManager/dispatcher.d -directory in alphabetical order in response to network events. Each script -should be: -.IP (a) 4 -a regular file -.IP (b) 4 -owned by root -.IP (c) 4 -not writable by group or other -.IP (d) 4 -not set-uid -.IP (e) 4 -and executable by the owner -.PP -Each script receives two arguments, the first being the interface name of the -device just activated, and second an action. -.PP -Actions: -.TP -.I up -The interface has been activated. The environment
Re: [PATCH] man: Rewrite NetworkManager.8 and NetworkManager.conf.5 in DocBook
On Wed, 2013-04-10 at 13:15 -0400, Dan Winship wrote: On 04/10/2013 06:37 AM, Colin Walters wrote: DocBook is not my favorite thing in the world, but it's lots-of-emphasisfar/lots-of-emphasis saner than troff. Some style parts cribbed from systemd. This is preparatory work for actually improving the content of the man pages. Yay. Makes sense to me. There are a few trailing-whitespace issues in the XML files (blank lines that contain whitespace), and a few minor glitches in the layout: dnsmasqNetworkManager will run dnsmasq as a local caching Fixed both of those, new patch attached. but yeah, troff sucks, and we never even bothered to figure out how to do some of the layout that we really needed to be doing there. (Like, the section under dns really ought to be another variablelist...) Yeah, I was just going for a literal translation as a starting point. I wouldn't bother converting nmcli.1 right now, since jklimes is changing the syntax around a lot. Ok. The main thing I think needs to be documented well is the semantics around the connection state; what's there isn't bad, but how it interacts with the plugin is not obvious to me yet. From aea75fd404d363f565594f6563d6c5e4bda2c6fb Mon Sep 17 00:00:00 2001 From: Colin Walters walt...@verbum.org Date: Tue, 9 Apr 2013 16:41:00 -0400 Subject: [PATCH] man: Rewrite NetworkManager.8 and NetworkManager.conf.5 in DocBook DocBook is not my favorite thing in the world, but it's lots-of-emphasisfar/lots-of-emphasis saner than troff. Some style parts cribbed from systemd. This is preparatory work for actually improving the content of the man pages. --- configure.ac |2 - man/Makefile.am | 16 ++ man/NetworkManager.8.in | 145 - man/NetworkManager.conf.5.in | 310 man/NetworkManager.conf.xml | 361 ++ man/NetworkManager.xml | 223 ++ 6 files changed, 600 insertions(+), 457 deletions(-) delete mode 100644 man/NetworkManager.8.in delete mode 100644 man/NetworkManager.conf.5.in create mode 100644 man/NetworkManager.conf.xml create mode 100644 man/NetworkManager.xml diff --git a/configure.ac b/configure.ac index 034bd68..fb2e118 100644 --- a/configure.ac +++ b/configure.ac @@ -706,8 +706,6 @@ initscript/linexa/networkmanager introspection/Makefile introspection/all.xml man/Makefile -man/NetworkManager.8 -man/NetworkManager.conf.5 man/nm-system-settings.conf.5 man/nm-online.1 man/nmcli.1 diff --git a/man/Makefile.am b/man/Makefile.am index 7db5623..fdf2041 100644 --- a/man/Makefile.am +++ b/man/Makefile.am @@ -14,6 +14,22 @@ nm-settings.xml: $(top_builddir)/tools/generate-settings-spec $(top_builddir)/li $(top_builddir)/tools/generate-settings-spec refentry $(builddir)/$@ CLEANFILES += nm-settings.xml +XSLTPROC_FLAGS = \ +--nonet \ +--stringparam man.output.quietly 1 \ +--stringparam funcsynopsis.style ansi \ +--stringparam man.th.extra1.suppress 1 \ +--stringparam man.authors.section.enabled 0 \ +--stringparam man.copyright.section.enabled 0 + +XSLTPROC_MAN_FLAGS = $(XSLTPROC_FLAGS) http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl + +%.8: %.xml + $(AM_V_GEN) xsltproc $(XSLTPROC_MAN_FLAGS) $ + +%.5: %.xml + $(AM_V_GEN) xsltproc $(XSLTPROC_MAN_FLAGS) $ + man_MANS +=\ NetworkManager.8 \ NetworkManager.conf.5 \ diff --git a/man/NetworkManager.8.in b/man/NetworkManager.8.in deleted file mode 100644 index 38a195f..000 --- a/man/NetworkManager.8.in +++ /dev/null @@ -1,145 +0,0 @@ -.\ NetworkManager(8) manual page -.\ -.\ Copyright (C) 2005 - 2013 Red Hat, Inc. -.\ Copyright (C) 2005 - 2009 Novell, Inc. -.\ Copyright (C) 2005 Robert Love -.\ -.TH NETWORKMANAGER 8 17 January 2012 -.SH NAME -NetworkManager \- network management daemon -.SH SYNOPSIS -.B NetworkManager [\-\-version] | [\-\-help] -.PP -.B NetworkManager [\-\-no\-daemon] [\-\-pid\-file=filename] [\-\-state\-file=filename] [\-\-config=filename] [\-\-config-dir=directory] [\-\-plugins=plugin1,plugin2,...] [\-\-log\-level=level] [\-\-log\-domains=domain1,domain2,...] -.SH DESCRIPTION -The \fINetworkManager\fP daemon attempts to make networking configuration and -operation as painless and automatic as possible by managing the primary network -connection and other network interfaces, like Ethernet, WiFi, and Mobile -Broadband devices. NetworkManager will connect any network device when a -connection for that device becomes available, unless that behavior is disabled. -Information about networking is exported via a D-Bus interface to any interested -application, providing a rich API with which to inspect and control network -settings and operation. -.P -NetworkManager will execute scripts in the /etc/NetworkManager/dispatcher.d -directory in alphabetical order in response to network events. Each script -should
Re: Compile and Install Network Manager
Hi Malintha, On Sun, 2013-04-07 at 19:41 +0600, Malintha Adikari wrote: Hi, I want to change the NM code, compile it and re-install it on my local system. Im using Fedora 18.Is it safer to do it so ? Or is there any safer way to do it other than do it on Virtual machine? If you're talking about overwriting /usr with e.g. sudo make install, I recommend downloading a known-good RPM of NetworkManager; then if you run into trouble you can just reinstall it. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] dhclient: copy leasefiles from old location if needed (rh #916233)
On Thu, 2013-03-14 at 14:38 -0500, Dan Williams wrote: + error error-message ? error-message : (unknown)); How could error be != NULL but error-message be NULL? Sounds like there was some buggy gobject library out there? If so the right thing is to fix it and not work around it everywhere... g_set_error() will warn if the message is NULL, at least in current glib git. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] keyfile plugin patches
Hopefully the first patch for error handling is something we can do in
the rest of the codebase too, because it's s much better.
From de1e3e809d06529afc0eb95ba38b374e1487924b Mon Sep 17 00:00:00 2001
From: Colin Walters walt...@verbum.org
Date: Wed, 6 Mar 2013 14:00:41 -0500
Subject: [PATCH 1/2] keyfile: Use goto out style error handling
Just code cleanup: This is much less error-prone than manual nesting,
and will mesh very well with future changes to use the libgsystem
cleanup macros.
---
src/settings/plugins/keyfile/plugin.c | 146 ++---
1 files changed, 81 insertions(+), 65 deletions(-)
diff --git a/src/settings/plugins/keyfile/plugin.c b/src/settings/plugins/keyfile/plugin.c
index e7e350b..a50f8c5 100644
--- a/src/settings/plugins/keyfile/plugin.c
+++ b/src/settings/plugins/keyfile/plugin.c
@@ -412,48 +412,53 @@ get_unmanaged_specs (NMSystemConfigInterface *config)
GKeyFile *key_file;
GSList *specs = NULL;
GError *error = NULL;
+ char *str;
if (!priv-conf_file)
return NULL;
key_file = g_key_file_new ();
- if (g_key_file_load_from_file (key_file, priv-conf_file, G_KEY_FILE_NONE, error)) {
- char *str;
-
- str = g_key_file_get_value (key_file, keyfile, unmanaged-devices, NULL);
- if (str) {
- char **udis;
- int i;
-
- udis = g_strsplit (str, ;, -1);
- g_free (str);
-
- for (i = 0; udis[i] != NULL; i++) {
-/* Verify unmanaged specification and add it to the list */
-if (strlen (udis[i]) 4 !strncmp (udis[i], mac:, 4) ether_aton (udis[i] + 4)) {
- char *p = udis[i];
-
- /* To accept uppercase MACs in configuration file, we have to convert values to lowercase here.
- * Unmanaged MACs in specs are always in lowercase. */
- while (*p) {
-*p = g_ascii_tolower (*p);
-p++;
-}
- specs = g_slist_append (specs, udis[i]);
-} else {
- g_warning (Error in file '%s': invalid unmanaged-devices entry: '%s', priv-conf_file, udis[i]);
- g_free (udis[i]);
+ if (!g_key_file_load_from_file (key_file, priv-conf_file, G_KEY_FILE_NONE, error)) {
+ g_prefix_error (error, Error parsing file '%s': , priv-conf_file);
+ goto out;
+ }
+
+ str = g_key_file_get_value (key_file, keyfile, unmanaged-devices, NULL);
+ if (str) {
+ char **udis;
+ int i;
+
+ udis = g_strsplit (str, ;, -1);
+ g_free (str);
+
+ for (i = 0; udis[i] != NULL; i++) {
+ /* Verify unmanaged specification and add it to the list */
+ if (strlen (udis[i]) 4 !strncmp (udis[i], mac:, 4) ether_aton (udis[i] + 4)) {
+char *p = udis[i];
+
+/* To accept uppercase MACs in configuration file, we have to convert values to lowercase here.
+ * Unmanaged MACs in specs are always in lowercase. */
+while (*p) {
+ *p = g_ascii_tolower (*p);
+ p++;
}
+specs = g_slist_append (specs, udis[i]);
+ } else {
+g_warning (Error in file '%s': invalid unmanaged-devices entry: '%s', priv-conf_file, udis[i]);
+g_free (udis[i]);
}
-
- g_free (udis); /* Yes, g_free, not g_strfreev because we need the strings in the list */
}
- } else {
- g_warning (Error parsing file '%s': %s, priv-conf_file, error-message);
- g_error_free (error);
+
+ g_free (udis); /* Yes, g_free, not g_strfreev because we need the strings in the list */
}
- g_key_file_free (key_file);
+ out:
+ if (error) {
+ g_warning (%s, error-message);
+ g_error_free (error);
+ }
+ if (key_file)
+ g_key_file_free (key_file);
return specs;
}
@@ -470,14 +475,20 @@ plugin_get_hostname (SCPluginKeyfile *plugin)
return NULL;
key_file = g_key_file_new ();
- if (g_key_file_load_from_file (key_file, priv-conf_file, G_KEY_FILE_NONE, error))
- hostname = g_key_file_get_value (key_file, keyfile, hostname, NULL);
- else {
- g_warning (Error parsing file '%s': %s, priv-conf_file, error-message);
- g_error_free (error);
+ if (!g_key_file_load_from_file (key_file, priv-conf_file, G_KEY_FILE_NONE, error)) {
+ g_prefix_error (error, Error parsing file '%s': , priv-conf_file);
+ goto out;
}
- g_key_file_free (key_file);
+ hostname = g_key_file_get_value (key_file, keyfile, hostname, NULL);
+
+ out:
+ if (error) {
+ g_warning (%s, error-message);
+ g_error_free (error);
+ }
+ if (key_file)
+ g_key_file_free (key_file);
return hostname;
}
@@ -485,45 +496,50 @@ plugin_get_hostname (SCPluginKeyfile *plugin)
static gboolean
plugin_set_hostname (SCPluginKeyfile *plugin, const char *hostname)
{
+ gboolean ret = FALSE;
SCPluginKeyfilePrivate *priv = SC_PLUGIN_KEYFILE_GET_PRIVATE (plugin);
- GKeyFile *key_file;
+ GKeyFile *key_file = NULL;
GError *error = NULL;
- gboolean result = FALSE;
+ char *data = NULL;
+ gsize len;
if (!priv-conf_file) {
- g_warning (Error saving hostname: no config file);
- return FALSE;
+ g_set_error (error, G_IO_ERROR, G_IO_ERROR_FAILED,
+ Error saving hostname: no config file);
+ goto out;
}
+
+ g_free (priv-hostname);
+ priv-hostname = g_strdup (hostname
Re: [PATCH] fix build: disable -Werror by default (Bug #679130)
On Fri, 2012-11-02 at 11:59 +0100, Clemens Buchacher wrote: So this has been an issue for a while, and the -Werror flag does not help anything besides breaking the build. You're going to have to learn how to pass options to configure if you're building software in general. It's really the maintainer's discretion what the defaults are. However, I just landed https://bugzilla.gnome.org/show_bug.cgi?id=687385 for GLib, and will shortly be attempting to do it in more of GNOME. I think it gives you a practical middle ground between -Werror and nothing. Were NM to consider changes here, it's worth a look. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: review request: pavlix/build
On Mon, 2012-10-29 at 18:54 -0400, Pavel Simerda wrote: In that case, also worth stating explicitly. What would you like to see there if we're just tidying up? Exactly that - add Just tidying up. in the commit message then. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: review request: pavlix/build
On Sat, 2012-10-27 at 19:39 -0400, Pavel Simerda wrote: Hi, I just pushed an updated version of 'pavlix/build', rebased to the current master. It's still a singe patch: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=pavlix/buildid=4dd911361871f8b8407f4f1c5deaf7422f4f76f8 The commit message here says what, but not *why*. What's the motivation for making the change? e.g. Look prettier in the filesystem? That's a valid motivation, but should be stated in the commit. Or your comment kind of implies it might be done to make it easier to write e.g. SELinux or AppArmor policy? In that case, also worth stating explicitly. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: review request: pavlix/distro
On Sat, 2012-10-27 at 19:47 -0400, Pavel Simerda wrote: Hi all, I would like to recieves comments on my 'pavlix/distro' branch that consists of three patches aiming towards distro-agnostic build system. http://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=pavlix/distro dcbw: I recall that you wanted to build all plugins. The last patch enables you to do that but defaults to the current behavior. This patch makes total sense to me - for Red Hat, we don't want to install the legacy sysvinit script, but we do want the ifcfg plugin. And so by default now, this will only build the keyfile plugin? If so, that's totally cool by me for the gnome-ostree side (I added --with-distro=generic). ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: __attribute__ ((cleanup) patch
On Fri, 2012-10-26 at 09:54 -0400, Pavel Simerda wrote: One thing I would like to give it some reasonable time. I'd still like to consult some people. Please do forward any feedback. A couple of programmers questions, though, that will help me to assess the actual value of gsystem: I'll create a wiki page soon and answer some of this stuff there. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: __attribute__ ((cleanup) patch
On Thu, 2012-10-18 at 11:59 -0500, Dan Williams wrote: On Thu, 2012-10-18 at 11:56 -0400, Colin Walters wrote: On Thu, 2012-10-18 at 11:51 -0400, Colin Walters wrote: I don't oppose that. Attached. Well, *if* we did that, we'd just git revert sha instead of applying a patch to do it. So the patch ended up getting reverted, which I'm OK with, but what I still want to know is - what are the hurdles I need to jump to move this forward? Pavel mentioned he felt like NetworkManager was being used as an experimental testbed; I don't quite agree with that characterization, but for example, is having more projects use the local allocation something that would help? I can work on that. I'd actually hoped to do NM first since I still plan to do some development on it, but that's OK. More documentation on how to use it? Document which compilers support it? Detect if we don't have it in configure.ac and error out? Other stuff? ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: __attribute__ ((cleanup) patch
On Fri, 2012-10-19 at 12:05 -0400, Pavel Simerda wrote: I, personally, was considering using some faster compiler for development. Pavel Tišnovský wrote an article about tcc and it might save me a lot of time waiting for compilation. I doubt it, though it does depend on what kind of build you're doing. For developer incremental builds (i.e. you haven't touched the Makefiles, only modified .[ch] files), where you have a decently fast machine (circa 2010+ CPU and hard disk), and a warm cache from a recent build...you're talking about a ballpark possibility of going from 1.5 seconds to 1.3 I'd guess. Just not worth it. Also, from a quick inspection, tcc isn't going to speed up g-ir-compiler, unfortunately one of the slower parts of the build (my fault actually, but very hard to make faster). And even if it's faster, how good is the DWARF generation? Your build may be even 10 seconds faster, but if you have to rebuild it when you want to use GDB, that's not really a win. Anyways if you come back to me and tell me that building with tcc is useful for you, I bet I can gain back a substantial amount of the lost speed (or more) by e.g. switching to nonrecursive automake. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: __attribute__ ((cleanup) patch
On Fri, 2012-10-19 at 08:47 -0400, Pavel Simerda wrote: 1) Do we consider the Linux non-GCC community if *they* want to use NetworkManager? So concretely, the major ones are LLVM and ICC; both of these I know both implement a lot of the GCC extensions, and they're also C++ compilers, which means implementing this feature should be trivial. (I just double checked; clang handles __attribute__ ((cleanup)) just fine) The other ones like PCC - yeah, just ignore it. Basically if you look at how much __attribute__ ((cleanup)) improves the code in one hand, and what PCC brings (basically nothing over GCC/LLVM) in the other hand... I think that regardless the actual technical aspects, by doing what we do here, we say: “We are NetworkManager. We are Linux. We are GCC. Otherwise, fuck off.” I don't agree the change says that. A lot of the useful bits of GNU C have become a de facto C language subset that are implemented by the important C compilers (with the major exception of MSVC). So again, this isn't restricted to just GCC. On the other hand, reverting, and starting again in a community-positive way, we would be saying: “Yes, you are welcome to work with us and we are ready to listen to your concerns and *then* decide.” I'll be meeting with SUSE networking developers during the weekend. What should I tell them? That it's not worth trying to work with us unless they are ready to see big changes going under their hands? I believe that this is a matter of attitude. Either we prove to be assholes who don't care, or we maintain a healthy open source project. It's not possible to do both. The technical debates about compilers though do pale beside this issue, and again, let me apologize. *I* screwed up. You are absolutely right that this should have gone through the mailing list. (It was public in Bugzilla, but I didn't really elaborate on it much there). I guess to show that we know we screwed up is not good enough. Talking about a change that has been merge is ranting. I think your concerns are reasonable, and it's not ranting. Post-commit debate happens in larger projects too; look at linux-kernel. And some of that has definitely resulted in commits being reverted. Other times, the author of the commit follows up and addresses the concerns. I'm not going to pretend a discussion over something that has been already decided. Ultimately I guess as project maintainer it's dcbw's call, but that I still think this discussion is valuable. But what I need is a list of problems to address, and feedback about how I'm addressing them. Documentation is one, and if you got a chance to review that patch, it'd be appreciated. The other concern is about process, and all I can say there is I apologize, and it won't happen again. I'm off to hopefully get some more projects like gdm to use this, and I'll make sure all the maintainers and consumers are in the loop. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
__attribute__ ((cleanup) patch
Hi, https://bugzilla.gnome.org/show_bug.cgi?id=685440 has a patch which just landed, but I wanted to give wider discussion to this, because it's a very important infrastructural change. First, one thing that came up is a concern about a GCC hard dependency. My understanding is that LLVM implements this too. For compilers which implement C++, this is easy to support. And since NetworkManager is highly tied to Linux, it's not like we have to care about MSVC. Now, I plan to do a followup patch pretty soon which would let us get rid of a *lot* of g_free()/g_object_unref() calls. By a conservative estimate, around 1500 lines. I've been using libgsystem cleanup extensively in several projects, and it's been a massive win. Other examples of projects using this in C are systemd and upstart. The downside is that this is kind of a one-way door. Once done, it'd be immensely tedious to try to go back and add them again. However, the benefit to the code is huge, and even better - trust me, it makes writing C fun again =) So, thoughts? ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: __attribute__ ((cleanup) patch
On Thu, 2012-10-18 at 11:19 -0400, Pavel Simerda wrote: Then why it wasn't good enough for Glib but is good enough for NetworkManager? Why See this thread: https://mail.gnome.org/archives/gtk-devel-list/2012-April/msg3.html Basically, because the GTK+ stack needs to compile with MSVC. Unfortunately. And Microsoft said they'll never implement anything beyond C89, not even C99. I don't see a link to elaborate explanation and documentation? I'll add some more docs to libgsystem. But the most important thing to read first is http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html Success stories. Like I said, systemd and upstart both use it, and I completely rely on it inside ostree (http://git.gnome.org/browse/ostree) which is 15,000 lines of GObject/C. A tenth the size of NM, true, but also not a trivial project. We're using it in another currently Red Hat internal project. I think Ray is amenable to doing it for GDM. Ultimately though, the only way the library is going to get better is if people use it and help out. More information? I did blog a bit ago about it too: http://blog.verbum.org/2012/05/09/__attribute__-cleanup-or-how-i-came-to-love-c-again/ That's exactly the problem I have with such quick inclusions without a proper discussion. Fair enough. I'm not yet even convinced about this because of total lack of documentation to be found right away. Ok, I'll add some more. And I'm not convinced that switching to a non-standard programming language is the price to pay. It's kind of a leap to call this a non-standard programming language. In reality of course, GLib (which NM relies on) is a *heavy* user of GCC extensions. Things like atomic intrinstics and statement expressions. This is larger, too, but it's really just C with one feature from C++. So, I haven't changed my mind. I propose the following path: 1) Revert I don't oppose that. 2) Document including the reasons why this cannot be added to Glib but should be added to NetworkManager Already done here. 3) Discuss In progress =) ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: __attribute__ ((cleanup) patch
On Thu, 2012-10-18 at 11:51 -0400, Colin Walters wrote:
I don't oppose that.
Attached.
From c43e095419423b36544e221f9f0896d2579fb0a0 Mon Sep 17 00:00:00 2001
From: Colin Walters walt...@verbum.org
Date: Thu, 18 Oct 2012 11:53:05 -0400
Subject: [PATCH] Revert core: import libgsystem, use it for
local-allocations in main.c (bgo #685440)
This reverts commit 89623b99c44bd7c6b721955ebc0a9550cb8dd978 pending
further discussion.
See: https://mail.gnome.org/archives/networkmanager-list/2012-October/msg00065.html
---
src/Makefile.am | 14 +
src/libgsystem/Makefile-libgsystem.am | 31 ---
src/libgsystem/README | 7 ---
src/libgsystem/README-NetworkManager-import | 5 --
src/libgsystem/gsystem-file-utils.c | 86 -
src/libgsystem/gsystem-file-utils.h | 34
src/libgsystem/gsystem-local-alloc.c| 65 --
src/libgsystem/gsystem-local-alloc.h| 42 --
src/libgsystem/libgsystem.doap | 31 ---
src/libgsystem/libgsystem.h | 33 ---
src/main.c | 76 +
11 files changed, 56 insertions(+), 368 deletions(-)
delete mode 100644 src/libgsystem/Makefile-libgsystem.am
delete mode 100644 src/libgsystem/README
delete mode 100644 src/libgsystem/README-NetworkManager-import
delete mode 100644 src/libgsystem/gsystem-file-utils.c
delete mode 100644 src/libgsystem/gsystem-file-utils.h
delete mode 100644 src/libgsystem/gsystem-local-alloc.c
delete mode 100644 src/libgsystem/gsystem-local-alloc.h
delete mode 100644 src/libgsystem/libgsystem.doap
delete mode 100644 src/libgsystem/libgsystem.h
diff --git a/src/Makefile.am b/src/Makefile.am
index 697203a..ba7d2d6 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -21,20 +21,11 @@ endif
SUBDIRS += . tests
-noinst_LTLIBRARIES =
-EXTRA_DIST =
-NULL =
-libgsystem_srcpath := libgsystem
-libgsystem_cflags = $(GIO_CFLAGS)
-libgsystem_libs = $(GIO_LIBS)
-include libgsystem/Makefile-libgsystem.am
-
INCLUDES = -I${top_srcdir} \
-I${top_builddir}/include \
-I${top_srcdir}/include \
-I${top_builddir}/src/generated \
-I${top_srcdir}/src/generated \
- -I${top_srcdir}/src/libgsystem \
-I${top_srcdir}/src/logging \
-I${top_srcdir}/src/posix-signals \
-I${top_srcdir}/src/dns-manager \
@@ -56,7 +47,7 @@ INCLUDES = -I${top_srcdir} \
# Test libraries
###
-noinst_LTLIBRARIES += \
+noinst_LTLIBRARIES = \
libtest-dhcp.la \
libtest-policy-hosts.la \
libtest-wifi-ap-utils.la
@@ -322,7 +313,6 @@ endif
NetworkManager_LDADD = \
./generated/libnm-generated.la \
- libgsystem.la \
./logging/libnm-logging.la \
./posix-signals/libnm-posix-signals.la \
./dns-manager/libdns-manager.la \
@@ -373,7 +363,7 @@ NetworkManager_DATA = gdb-cmd
dbusservicedir = $(DBUS_SYS_DIR)
dbusservice_DATA = org.freedesktop.NetworkManager.conf
-EXTRA_DIST += \
+EXTRA_DIST = \
$(dbusservice_DATA) \
$(NetworkManager_DATA)
diff --git a/src/libgsystem/Makefile-libgsystem.am b/src/libgsystem/Makefile-libgsystem.am
deleted file mode 100644
index b0e87c5..000
--- a/src/libgsystem/Makefile-libgsystem.am
+++ /dev/null
@@ -1,31 +0,0 @@
-# Copyright (C) 2012 Colin Walters walt...@verbum.org
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the
-# Free Software Foundation, Inc., 59 Temple Place - Suite 330,
-# Boston, MA 02111-1307, USA.
-
-noinst_LTLIBRARIES += libgsystem.la
-
-EXTRA_DIST += $(libgsystem_srcpath)/README
-
-libgsystem_la_SOURCES = \
- $(libgsystem_srcpath)/gsystem-local-alloc.h \
- $(libgsystem_srcpath)/gsystem-local-alloc.c \
- $(libgsystem_srcpath)/gsystem-file-utils.h \
- $(libgsystem_srcpath)/gsystem-file-utils.c \
- $(libgsystem_srcpath)/libgsystem.h \
- $(NULL)
-
-libgsystem_la_CFLAGS = $(AM_CFLAGS) $(libgsystem_cflags)
-libgsystem_la_LIBADD = $(libgsystem_libs)
diff --git a/src/libgsystem/README b/src/libgsystem/README
deleted file mode 100644
index 0694940..000
--- a/src/libgsystem/README
+++ /dev/null
@@ -1,7 +0,0 @@
-libgsystem is intended to be used as a git external for components
-that depend on GLib, but accept a hard dependency on things which are
-difficult to do in GLib itself
Re: __attribute__ ((cleanup) patch
On Thu, 2012-10-18 at 11:19 -0400, Pavel Simerda wrote:
I'm not yet even convinced about this because of total lack of documentation
to be
found right away.
What do you think about this patch? Does it help address your concerns?
Is there anything that could be clearer?
From a6f48a9720aa7b01b8abee1fc0eb78230b273485 Mon Sep 17 00:00:00 2001
From: Colin Walters walt...@verbum.org
Date: Thu, 18 Oct 2012 13:11:04 -0400
Subject: [PATCH] Document more
Thanks to Pavel Simerda psime...@redhat.com for bringing this up.
---
gsystem-local-alloc.c | 48
gsystem-local-alloc.h | 43 +++
2 files changed, 91 insertions(+)
diff --git a/gsystem-local-alloc.c b/gsystem-local-alloc.c
index 1bbea90..b19a329 100644
--- a/gsystem-local-alloc.c
+++ b/gsystem-local-alloc.c
@@ -22,6 +22,54 @@
#include gsystem-local-alloc.h
+/**
+ * SECTION:gslocalalloc
+ * @title: GSystem local allocation
+ * @short_description: Release local variables automatically when they go out of scope
+ *
+ * These macros leverage the GCC extension __attribute__ ((cleanup))
+ * to allow calling a cleanup function such as g_free() when a
+ * variable goes out of scope. See ulink
+ * url=http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html;
+ * for more information on the attribute.
+ *
+ * The provided macros make it easy to use the cleanup attribute for types
+ * that come with GLib. The primary two are #gs_lfree and #gs_lobj,
+ * which correspond to g_free() and g_object_unref(), respectively.
+ *
+ * The rationale behind this is that particularly when handling error
+ * paths, it can be very tricky to ensure the right variables are
+ * freed. With this, one simply applies gs_lobj to a
+ * locally-allocated #GFile for example, and it will be automatically
+ * unreferenced when it goes out of scope.
+ *
+ * Note - you should only use these macros for emphasisstack
+ * allocated/emphasis variables. They don't provide garbage
+ * collection or let you avoid freeing things. They're simply a
+ * compiler assisted deterministic mechanism for calling a cleanup
+ * function when a stack frame ends.
+ *
+ * example id=gs-lfreetitleCalling g_free automatically/title
+ * programlisting
+ *
+ * GFile *
+ * create_file (GError **error)
+ * {
+ * gs_lfree char *random_id = NULL;
+ *
+ * if (!prepare_file (error))
+ * return NULL;
+ *
+ * random_id = alloc_random_id ();
+ *
+ * return create_file_real (error);
+ * // Note that random_id is freed here automatically
+ * }
+ * /programlisting
+ * /example
+ *
+ */
+
void
gs_local_free (void *loc)
{
diff --git a/gsystem-local-alloc.h b/gsystem-local-alloc.h
index 24e7ca2..28d857f 100644
--- a/gsystem-local-alloc.h
+++ b/gsystem-local-alloc.h
@@ -25,16 +25,59 @@
G_BEGIN_DECLS
+/* These functions shouldn't be invoked directly;
+ * they are stubs that:
+ * 1) Take a pointer to the location (typically itself a pointer).
+ * 2) Provide %NULL-safety where it doesn't exist already (e.g. g_object_unref)
+ */
void gs_local_free (void *loc);
void gs_local_obj_unref (void *loc);
void gs_local_variant_unref (void *loc);
void gs_local_ptrarray_unref (void *loc);
void gs_local_hashtable_unref (void *loc);
+/**
+ * gs_lfree:
+ *
+ * Call g_free() on a variable location when it goes out of scope.
+ */
#define gs_lfree __attribute__ ((cleanup(gs_local_free)))
+
+/**
+ * gs_lobj:
+ *
+ * Call g_object_unref() on a variable location when it goes out of
+ * scope. Note that unlike g_object_unref(), the variable may be
+ * %NULL.
+ */
#define gs_lobj __attribute__ ((cleanup(gs_local_obj_unref)))
+
+/**
+ * gs_lvariant:
+ *
+ * Call g_variant_unref() on a variable location when it goes out of
+ * scope. Note that unlike g_variant_unref(), the variable may be
+ * %NULL.
+ */
#define gs_lvariant __attribute__ ((cleanup(gs_local_variant_unref)))
+
+/**
+ * gs_lptrarray:
+ *
+ * Call g_ptr_array_unref() on a variable location when it goes out of
+ * scope. Note that unlike g_ptr_array_unref(), the variable may be
+ * %NULL.
+
+ */
#define gs_lptrarray __attribute__ ((cleanup(gs_local_ptrarray_unref)))
+
+/**
+ * gs_lhash:
+ *
+ * Call g_hash_table_unref() on a variable location when it goes out
+ * of scope. Note that unlike g_hash_table_unref(), the variable may
+ * be %NULL.
+ */
#define gs_lhash __attribute__ ((cleanup(gs_local_hashtable_unref)))
G_END_DECLS
--
1.7.11.7
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: __attribute__ ((cleanup) patch
On Thu, 2012-10-18 at 11:28 -0500, Dan Williams wrote: I don't consider this an experiment at this point. Well, I do think Pavel has a point; it's true that NetworkManager is an order of magnitude more code than any other project I've used it in before, and it's larger in terms of people too. Yes, there is a bit of education required, but perhaps we could also work on making some things compile-time errors instead of runtime gotchas. Would require a GCC plugin. But the way I see it is these patches don't *regress* type safety - the compiler isn't going to warn you right now if you call g_free (some_object) either. Anyways, bottom line: given the benefits, my goal here is to figure out where the bar is in the opinion of the NetworkManager developers, and do what I need to reach it. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH](or feature-request) build both systemd and ck versions
On Wed, 2012-10-17 at 15:02 -0400, Luke T.Shumaker wrote: I propose that the build system should generage both `NetworkManager-ck' and `NetworkManager-systemd' binaries and symlink `NetworkManager' to one of them. This way a distro that supports both sysvinit and systemd (such as Arch) can easily offer both. In the case of Arch, the correct version can be decided by symlinking `NetworkManager'-`NetworkManager-ck' (for compatability) and modifying the systemd `NetworkManager.service' file to run `NetworkManager-systemd' instead of just `NetworkManager'. You could just have two separate binary packages that conflict. So anyways in GNOME, we do the same compile-time flag. Changing it to be fully dynamic like this in the large scale would be really insane. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH](or feature-request) build both systemd and ck versions
On Thu, 2012-10-18 at 05:19 -0400, Pavel Simerda wrote: In my opinion, you should have just one binary. It is easy to detect systemd at runtime, as it requires cgroups and creates one. There is sd_booted() as public API for that. For what NetworkManager is doing, runtime detection may indeed be simple enough. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network-Manager Trunk and Fedora 12
- Dan Williams d...@redhat.com wrote: /var/log/messages: Mar 25 19:51:58 localhost dbus-daemon: Rejected send message, 2 matched rules; type=method_return, sender=:1.12 (uid=0 pid=1424 comm=/usr/sbin/bluetoothd) interface=(unset) member=(unset) error name=(unset) requested_reply=0 destination=:1.10 (uid=0 pid=1414 comm=NetworkManager)) At what point does that failure come? This could be caused by recent (well, year-old) dbus policy changes for unrequested reply messages which I'm not 100% sure how to get fixed... walters; what could be the cause of this sort of thing again? The operative component here is requested_reply=0, and the policy is to reject unrequested replies. Often this is harmless because if a message wasn't expecting a reply, denying a reply shouldn't matter. If however the binding/code was setting no_reply AND actually expecting to process the reply, that's a bug in the calling code. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: problem with networkmanager dbus api
On Wed, Oct 29, 2008 at 6:50 AM, Dan Williams [EMAIL PROTECTED] wrote: It's been in dbus-glib since June, right after the release of 0.76: http://gitweb.freedesktop.org/?p=dbus/dbus-glib.git;a=blobdiff;h=ee760113af2d89ac526ac247f25552f90239972f;hp=3744d8439b461957040df4dd1ba555906bbedc54;hb=d1b80d803a0268bd4b3dd5b9a9522230461f2947;f=dbus/dbus-gobject.c maybe that means time for another dbus-glib release Colin? There are a couple of patches queued that would be good to get in first, but should be soon. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] Support Debian's resolvconf
On Sun, 2005-07-31 at 15:15 +0200, Olivier Blin wrote: Ok, but you could have enhanced the current system to have this kind of status reporting. Currently, I guess you have lost the ability to manage ppp connections, dsl connections and isdn connections in NetworkManager. I think a big component of the design thought behind NetworkManager is to make the common case work really, really well, even if that comes at the expense of some of the less-common cases. For example, making 802.11 work really well, and not including ppp and idsn. I know ppp/isdn are probably very important to some people, but in good design you have to make some trade-offs. I don't think it's impossible to support these things in NetworkManager, be that some basic integration with and awareness of existing distro tools for these connection types, or implementing it all in NetworkManager if that proves necessary. Right, the network scripts can't handle that currently, but it's quite easy to add this feature. In Mandriva, I plan to use wpa_supplicant as default roaming daemon for wireless interfaces. So the wireless settings would be configured in wpa_supplicant.conf. Then, the network level parameters (IP settings, DHCP) could be configured in per-wireless-network configuration files. We could use files named by the ESSID or BSSID to store this settings, in for example /etc/sysconfig/network-scripts/wireless So there's a lot of implementation details here; what are you getting over NetworkManager (as it stands today)? As far as I can see, you get: o Support for static IP addresses on 802.11b etc o Backwards compatibility Now the first item, I guess my thought would be - there's probably about 50 networking nerds out there who have hardcoded static IP addresses for their wireless networks; are they really important? It's really weird to use static IP for wifi in general anyways since you have to also do things like hardcode the MAC address of the access point etc, or you don't support roaming basically. Maybe in specialized situations the static IP makes sense, but we should sit down and talk about what those situations are and think about the problem rather than just deciding that since it was supported before, it has to be in the future. The second item has some importance I understand - but we could discuss how to get some basic integration of NM and the existing ppp/isdn configuration; this might be basically just sending NetworkManager a dbus signal from the isdn script to say i'm on isdn, don't do wired/wireless. Maybe it's harder than that, I don't know, but again we should discuss it. To have a dynamic behaviour, the network scripts only miss ifplugd and wpa_supplicant support. We already have both in Mandriva, we just have to allow to use the two daemons for the same interface. No offense but this feels pretty handwavy to me :) Sure, you have ifplugd and wpa_supplicant and some network scripts...but do they all really form a coherent whole when you put them all together? For example if you are on wireless through wpa_supplicant and then plug into a static IP network, does ifplugd activate the static IP address in addition to the wireless? Who owns the routing table? What if both want to do DHCP, and write out resolv.conf? How does VPN interact with both of these? How does the user control and configure the VPN? A lot of thought has gone into these issues in NetworkManager, and I think they've been solved pretty well. To me, current network scripts are a good starting point, and I don't find it really difficult to make them mobility-aware. I would like to convince you otherwise - we really want to see NetworkManager become the core of Linux networking, because this is an area that is hugely fragmented and having the NetworkManager API always available means applications can adjust their programs to dynamically respond to network availability via the dbus signals. Fair enough. So, you're currently using network scripts for corporate servers and NetworkManager for desktop. Do you have some migration scripts to handle the transition in the future? The answer is that right now there is basic backwards compatibility with ethernet static addressing in the form of simply doing nothing if an interface already has an IP address (presumably configured via distro scripts). There isn't compatibility with existing ppp/isdn, but that may not be too hard to do as I said above. signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] Support Debian's resolvconf
On Sat, 2005-07-30 at 14:38 -0400, Will Dyson wrote: On 7/28/05, Steev [EMAIL PROTECTED] wrote: Will Dyson wrote: I can work on moving the resolv.conf management into the backends, if people think that would be useful. Do any other distributions (or any of the BSDs) have their own systems for managing resolver information? Gentoo currently just uses /etc/resolv.conf, however there is a new baselayout package in the works, and they are planning on the ability to either use the static /etc/resolv.conf or it being somewhere like /var/lib/etc (no, i don't think thats where it is, just know that soon you can set it to be a symlink or not. If at least one other system is going to want to have /etc/resolv.conf be a symlink to something else, then I guess I'll put together a patch to move the management of libc resolver info out of named-manager/nm-named-manager.c and into NetworkManagerSystem.c (where it can cleanly call into code from backends/whatever.c). If Gentoo and/or Ubuntu are taking the stance that no application can modify resolv.conf and must be patched to use some other interface, we can support that I guess, but: Of course, Colin won't like it. Right, because I'd rather work on integrating NetworkManager fully and in the meantime just work around incompatibility (e.g. Conflicts: resolvconf). signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] Support Debian's resolvconf
On Thu, 2005-07-28 at 18:28 -0400, Will Dyson wrote: I really use resolvconf because it seems more elegant than having various different scripts and programs rewriting my resolv.conf file. My point is, NetworkManager should be the only program writing out your resolv.conf. For example, NetworkManager now has integrated VPN support, which obviates one major class of programs which also want to change network configuration. In other words, the general idea is that NetworkManager owns the network configuration completely. This is a good thing, because NetworkManager has a holistic and dynamic view of the network; it's keeping track of what the user wants, when the network is available and not, what hardware is plugged in, etc. Random shell scripts or whatever dropped in /etc/resolvconf.d or whatever don't. I don't really see the value in extra indirection through resolvconf unless it actually solves some real-world problem that users care about. If you can come up with one, great; we can discuss implementation details in solving that problem using resolvconf versus NetworkManager plugins versus whatever. And because I actually do run caching nameservers on some of my other systems, and like to keep things as similar as possible across my machines. This confuses me - NetworkManager does contain a caching nameserver. Are you talking about making your NetworkManager machines similar to machines which currently don't run NM? Or something else? signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] Support Debian's resolvconf
On Fri, 2005-07-29 at 12:12 -0400, Will Dyson wrote: So the added value here is the removal of a potential failure case (and one that I'm sure others will hit) when NetworkManager is stopped or removed. NetworkManager is supposed to be friendly, and I feel that includes doing everything it can to avoid causing breakage even in the face of operator error (if you want to insist that using NM with resolvconf is an error). Now, one could say that the real solution here is for Debian/Ubuntu packages of NetworkManager to Conflict: with resolvconf. Right, adding a conflicts would work. Or just don't include resolvconf at all in their repositories and instead work on integrating NetworkManager by default, as we're going to do for Fedora. But playing nice with resolvconf is so easy, I just don't understand the objection to it. If I remember from when I used Debian there's about 50 networking packages with various bits of functionality; we could include code in NetworkManager to e.g. optionally use ifupdown to monitor link state, guessnet for doing DHCP, etc. We could add patches to use all of these, but what's the point? Just don't install those packages. The former. My laptop is the only machine that runs NM. All my machines have resolvconf. What we want to do is get to the point where NM is installed everywhere, from servers to desktops to laptops. It should be *the* networking API. That way even on servers or desktops, applications can e.g. listen for D-BUS signals on network availability and react accordingly. signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] Support Debian's resolvconf
On Fri, 2005-07-29 at 22:10 +0200, Thomas Hood wrote: Will Dyson wrote: Now, one could say that the real solution here is for Debian/Ubuntu packages of NetworkManager to Conflict: with resolvconf. But playing nice with resolvconf is so easy, I just don't understand the objection to it. One advantage of resolvconf is that it already supports delivery of nameserver addresses to dnsmasq and pdnsd as well as bind9. It is also compatible with nscd. So if NM uses resolvconf then it doesn't need to run its own private instance of named and the admin is free to choose a local caching nameserver to go along with NM. Well, yes...but I would like to pick one caching nameserver that works instead of supporting N different ones. Now, if you're making the argument that we should remove the bind code from NetworkManager and instead depend on resolvconf, that makes a certain amount of sense. My concern with that is that one of the original reasons I decided to do the managed bind setup is for VPN support; e.g. changing the BIND config to only use the VPN nameservers for subdomains of the VPN. Does resolvconf have an interface for that? In Ubuntu and Debian it appears that NM will be packaged to be compatible with resolvconf. If in Ubuntu the resolvconf package will be installed by default, I guess we can put in the resolvconf support in order to be more compatible until such time as NetworkManager can replace the networking system entirely. Is it going to be installed by default? I'm not trying to be a pain - if this patch would make life significantly easier for Ubuntu or Debian we can put it in. I'm trying to make the general point though that we should concentrate on end user functionality and making things work instead of churning the dependencies and code. signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] Support Debian's resolvconf
On Thu, 2005-07-28 at 11:54 -0400, Will Dyson wrote: I've been playing with NetworkManager on my laptop (running Ubuntu). I'm rather pleased with it in general, but I use the resolvconf [1] package for managing /etc/resolv.conf. Can you explain why you use resolvconf and NetworkManager? What additional nameserver configuration do you use? signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: 2 questions...
On Mon, 2005-07-25 at 20:27 -0400, Derek Atkins wrote: Colin Walters [EMAIL PROTECTED] writes: Seriously, what's the difference to the end user? Having to type their password first? Not necessarily: Having to restart gaim or psi or other apps because there's a race condition between login and network startup? As far as technical implementation I don't see using cached credentials to be less straightforward than trying to do network configuration before login. Caching credentials is a HARD problem. How is PAM supposed to know my kerberos password, unless it stores it somewhere? I don't want PAM to store my _kerberos_ password. Why not? If you wanted to avoid the second password prompt, there's no reason for example we couldn't have PAM pass the password on to your user session, and then krb5-auth-dialog would try that first before prompting you. Meanwhile, storing network passwords in a place that only root/NM can get to it? We might need to end up doing this for the server case, but for your laptop case I think requiring end users to do system administrator type things just to get their laptop working is wrong. Any time an end user needs the root password we have failed. signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: 2 questions...
On Tue, 2005-07-26 at 03:05 +0200, Sebastien ESTIENNE wrote: D I also need it for other reasons than kerberos: - i can't acces my samba shares until i log in, using my laptops as mobile file server, sometimes i expect to just power it on and be able to acces my files. - the same for apache (holding my wiki) and hula holding my contacts/planning There's two answers. First, we could say his is the same as the server use case, regardless of the fact that you're running the servers on a laptop. The second answer is, what if we changed the OS so that when your laptop boots up, gdm would detect that there was only one user on the system, and would just start logging you in, but with the screensaver already locked. That way everything in your user session (including nm-applet) would run, and your servers would have network connectivity. signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: 2 questions...
On Tue, 2005-07-26 at 10:14 -0400, warlord wrote: Dan, you keep conflating two issues which are not the same. You seem to be confusing network exists at startup from network changes from under you. I'm concerned about the former, you seem to talking about the latter. I would conflate the two as well, since to me (as a software developer) it seems that if you can handle the latter, the former is easy. Most applications fail harder if there's no network when they start, but will deal much better if the network changes from under them. Really? What applications? And why is it so much harder to handle no-network-at-start? Why should wireless networks be treated differently than wired networks in terms of when they are started? They aren't treated differently in the design really, just the implementation detail makes wired networks start earlier in the boot process. Depending on that implementation detail is a bug. signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: 2 questions...
On Tue, 2005-07-26 at 12:58 -0400, warlord wrote: Quoting Colin Walters [EMAIL PROTECTED]: Having to restart gaim or psi or other apps because there's a race condition between login and network startup? You ignored this issue... I ignored it because Dan answered it: all applications have to handle network unavailability at any time. Because I don't want my kerberos password cached.. Anywhere.. Anytime. What is the threat, exactly? Laptop theft? In that case, since the password is only cached in memory, as soon the thief reboots the laptop, the password is gone. Note also that we could clear the password from the memory cache on suspend; when you unsuspend the screensaver comes up, and we regenerate the memory cache from that. It only knows my keys derived from my password. But honestly I'm sorry I brought up Kerberos -- it's detracting from the real issue which is that Wireless and Wired networks are treated differently during the startup sequence. I answered this elsewhere; they aren't really. Who said anything about requiring users to SysAdmin type things? I never did. You said: Meanwhile, storing network passwords in a place that only root/NM can get to it? I interpreted that as requiring a root password to change. I've ALWAYS said that NM should remember the preferences globally instead of storing them in nm-applet. I don't think we want to do that as we do want to support the multiuser laptop case. Imagine a family with a father and a daughter. The father takes the laptop to work and logs into the corporate wireless network and VPN. The daughter wants to use the laptop at home. The daughter really likes to install lots of random software from the internet. If the networks are per-user, malware installed in the daughter's account can't email the father's network passwords and VPN configuration to the world. So I think we should keep strong separation between users wherever possible, and in this case, we can. I agree that any time an end user needs the root password we have failed. I certainly don't want to have to type that just to connect to a new/different wireless network. OTOH I *DO* want the wireless network to come up on its own BEFORE I LOGIN if it's a network I've ever seen before (or an open network). Again, every application has to handle the case where you power on your laptop without any network connectivity at all, and know what to do when it comes back or vanishes. The only reason to start before login would be the implementation detail of letting pam_krb5 talk to the Kerberos server, and we already came up with a solution for that with ccreds and krb5-auth-dialog. signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: 2 questions...
On Mon, 2005-07-25 at 17:55 -0400, David Zeuthen wrote: On Mon, 2005-07-25 at 16:54 -0400, Derek Atkins wrote: no offense intended, but I still disagree with that design choice. It means you cannot use NM in a situation where you have wireless network and network-based login (e.g. Kerberos/Hesiod, NIS, etc). In the current design you have to already be logged in in order to start the wireless network, which means you have to have a local account. IMNSHO it would be much better to store this information globally so that NM can choose from pre-defined networks before the user is logged in. This certainly works fine for WEP or unprotected networks, and even for shared-key WPA networks. It might not work as well for interactive 802.1x authentication... Even Windows will setup the network before the login process, assuming the wireless network was configured a priori! How could Windows get something right and Linux not? I've tried to argue for some time that the right solution here is clearly to run nm-applet on top of, and managed by, your login manager, e.g. gdm. I think this kind of jumping to implementation details. This may be in large part the approach we want, but I'd like to look at some of the use cases and interaction choices that fall out from it. We already fixed the Kerberos thing, so that's a non-use-case. The other thing that came up in this thread is the server case. The way system administrators configure networking right now is $EDITOR /etc/blah or possibly some tool like system-config-network. Your nobody/GConf suggestion basically makes it impossible to configure server wireless networking by hand with $EDITOR. You will probably get a lot of unhappy Unix sysadmins, who tend to live and breathe text files (as we don't have any better common system). For the server case, an alternative to nobody/GConf is to have nm-static-info, a little binary which parses distro wireless network config files (and possibly reads /etc/NetworkManager/wireless.conf or something), and owns the org.freedesktop.NetworkManagerInfo service on the bus. It doesn't link to GTK+ or GConf, and there's no user interaction expected, it just runs early as part of the server bootup. This approach lets Unix admins use $EDITOR and also keeps all the existing distro tools for server wireless network configuration (like system-config-network, YaST, etc.) working unchanged. Possibly we could even have the default NetworkManager init script start this daemon by default; we need to figure out how to kill it (really, make it not own NetworkManagerInfo) though when the user logs in. The current semantics for D-BUS service names are backwards from what we want here. - the UI will have to be a bit different and it will store keys in the user 'nobody' gconf-tree, alternatively use keys from the system-wide (or site-wide) default/mandatory gconf-trees. Wait, am I understanding you correctly and you're saying gdm would gain a notification area and a wireless networking selector? Or are you just talking about implementation details? The goal in my mind here is to solve the server case. Btw, we desperately need this kind of infrastructure in GNOME for other things such as running gnome-volume-manager, gnome-screensaver, gnome-power-manager etc. I proposed this [1] to be part of the GNOME session services framework that people at Red Hat been working on; it makes a lot of sense to me. I guess what makes me nervous about this is it seems like part of a big plan to unify how servers and desktops are configured, and while I think that's valuable in theory, the current design is a pretty nontrivial change to how many server system administrators are used to working. I mean...the server admin experience for configuring wireless manually would be like: sudo nobody gconftool-2 -t string /system/networking/wireless/networks/Company/essid blah sudo nobody gconftool-2 -t string /system/networking/wireless/networks/Company/timestamp ?? sudo nobody gconftool-2 -t string /system/networking/wireless/networks/Company/key secret ... versus just $EDITOR /etc/blah, which is what admins have to do anyways for all the stuff they truly care about like Samba and Apache. The primary value in your proposal seems to be that we share a lot more code between the desktop/server cases. But for g-v-m and g-p-m, do you really want to have the same set of knobs available for desktops and servers? ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: 2 questions...
On Tue, 2005-07-26 at 18:20 -0400, Derek Atkins wrote: Colin Walters [EMAIL PROTECTED] writes: Because I don't want my kerberos password cached.. Anywhere.. Anytime. What is the threat, exactly? Laptop theft? In that case, since the password is only cached in memory, as soon the thief reboots the laptop, the password is gone. Note also that we could clear the password from the memory cache on suspend; when you unsuspend the screensaver comes up, and we regenerate the memory cache from that. Um, if it's only cached in memory then that doesn't solve the bootup problem. You're still stuck if you bootup on a wireless network. You can't login because you're not on the network, and you can't get on the network because you can't login. If the creds aren't cached on disk, then you lose. It does seem to me the very first time you log in you need to be on the network, in order to get the credentials cached. Maybe the credential caching is the wrong idea entirely, and we should drop pam_krb5 from the gdm auth component and instead just use it in the password section (so you get local password changes when you change your kerberos password). Then to get the ticket you use krb5-auth-dialog. What is the threat? Laptop theft is certainly high on my list. My tickets are only valid for a short period of time. My password is valid until I change it. Sure, and I think we can address the laptop theft threat by clearing the memory cache on suspend, and logout. So doing it your way is no more secure.. In fact, I would argue it's even LESS secure, because the malware could read out the daughter's passwords whereas in my scenario it couldn't, because network passwords would be write-only from nm-applet! So, my approach is even more secure than yours against user-installed malware. That's a good point; but I think we should still be concerned about integrity and not just confidentiality; i.e. daughter's malware shouldn't be able to overwrite/destroy the VPN/wireless configuration of the father. As a side note I would like to get GConf enhanced to act as a SELinux userspace object manager; what this means is it would do access control based on the security context of the process requesting a preference key, so we could e.g. ensure that only nm-applet can read/write the wireless config keys and prevent a compromised firefox from accessing them. This way we get equivalent security to what you were suggesting of having the keys be stored in a write-only fashion to the user session. Also, having the wireless/VPN config system instead of per-user makes it more difficult to fix the bug (and it is a bug, IMO!) that when the father logs out the system is still on the VPN. signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: 2 questions...
On Mon, 2005-07-25 at 16:54 -0400, Derek Atkins wrote: Quoting Dan Williams [EMAIL PROTECTED]: All the wireless keys, preferred network, and which networks you're actually allowed to connect to are stored per-user, as designed, and also as designed, NetworkManager won't attempt to connect to a wireless network without that data since it couldn't possibly know which one to connect to. no offense intended, but I still disagree with that design choice. It means you cannot use NM in a situation where you have wireless network and network-based login (e.g. Kerberos/Hesiod, NIS, etc). In the current design you have to already be logged in in order to start the wireless network, which means you have to have a local account. If you're using network login, your computer is tied specifically to that network; you can't switch networks, which invalidates a lot of the point of NetworkManager as it is today. For the short term you could just use your OS native wireless networking scripts, hardcode the wireless network and WEP key in /etc/whatever. Longer term it probably makes sense to have NetworkManager handle these oddball cases (including things such as static IP), but there isn't anyone working on it AFAIK. I think the value that NetworkManager provides in these cases is as an OS-agnostic frontend for querying network status etc. So maybe we should just have a separate NetworkManagerStatic server with its own backends that has plugins for various systems. signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: 2 questions...
On Mon, 2005-07-25 at 16:54 -0400, Derek Atkins wrote: Quoting Dan Williams [EMAIL PROTECTED]: All the wireless keys, preferred network, and which networks you're actually allowed to connect to are stored per-user, as designed, and also as designed, NetworkManager won't attempt to connect to a wireless network without that data since it couldn't possibly know which one to connect to. no offense intended, but I still disagree with that design choice. It means you cannot use NM in a situation where you have wireless network and network-based login (e.g. Kerberos/Hesiod, NIS, etc). In the current design you have to already be logged in in order to start the wireless network, which means you have to have a local account. Oh, one other thing; my personal opinion (as opposed to the occasional-NetworkManager-hacker opinion from my other post) is that requiring network auth at login for laptops is pretty crack unless you're in a very specific environment. I mean...I see the value in single-sign-on systems like Kerberos, but as a user I'd be unhappy if may laptop became a brick if I couldn't access the wireless network temporarily for whatever reason. Not to mention simply taking the laptop on a road trip away from the office. A while ago some Fedora hackers were working on cached credentials for PAM; the idea is that when you logged in, the credentials would be cached locally, so that if you were ever away from the network, you could still log in. I'm not sure what the status on that is. signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: 2 questions...
On Mon, 2005-07-25 at 17:24 -0400, Derek Atkins wrote: Quoting Colin Walters [EMAIL PROTECTED]: If you're using network login, your computer is tied specifically to that network; you can't switch networks, which invalidates a lot of the point of NetworkManager as it is today. For the short term you could just use your OS native wireless networking scripts, hardcode the wireless network and WEP key in /etc/whatever. Actually, that's not true at all. I could be in any of a dozen different buildings at MIT, at my house, at Usenix or IETF or some other conference -- Yep, NetworkManager rocks for this. and I should be able to use my standard network login from any of those locations. I completely agree! The PAM cached credentials work should fix this. Moreover, I have a bunch of network services that don't like to startup without network. Even now I have to restart ntpd, sendmail, and athena-zhm by hand.. As Dan said, this is just bugs in the init system and/or those daemons. And I don't even want to think about the hell that OpenAFS would be! Most network file systems were designed before the roaming laptop era, and do not account for the network arbitrarily disappearing and instead like to eat applications by blocking them in IO wait state (hi NFS!). I don't know whether OpenAFS is similar but I imagine so. I just gave up on network file systems like NFS for my laptop long ago. Yea, every once in a blue moon do I need a static IP.. It would be nice to have it available. OTOH I don't think it's odd at all to want the network to come up during the boot sequence. Note the desktop login is really part of the boot sequence from the normal user perception. signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: 2 questions...
On Mon, 2005-07-25 at 17:36 -0400, Colin Walters wrote: A while ago some Fedora hackers were working on cached credentials for PAM; the idea is that when you logged in, the credentials would be cached locally, so that if you were ever away from the network, you could still log in. I'm not sure what the status on that is. http://www.redhat.com/archives/fedora-devel-list/2004-September/msg01038.html If you're interested I'd probably ping John or ask on fedora-devel-list. signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DNS problem (forwarding order?)
On Mon, 2005-07-11 at 20:52 +0200, Thomas Hood wrote: Here is a good reason, then, to use dnsmasq rather than bind. When dnsmasq is run with the --strict-order option it always consults nameservers in the specified order. But again, this would only help most (i.e. not all) of the time. The network setup where David is is just broken. (Its default behavior is to try to be smart: Start with no current server, in this state queries are sent in parallel to all servers. The first one to reply becomes the current server. Subsequent queries are sent to that server alone. If a query to the current server times out without a reply, revert to the initial state and retransmit to all in parallel, select a ne current server based on who wins the race.) Actually this looks to me like it would make things worse; in David's case, suppose that one of the external servers happens to win the race. It will give back a negative reply for an internal name. If that's then cached, then one loses. Another reason: the dnsmasq package in Debian is one third the size of the bind9 package. Another reason: dnsmasq is designed from the ground up as a caching nameserver. Ok, but these reasons aren't very convincing on their own. Another reason: dnsmasq does not need to be restarted or even signalled when the list of nameservers chagnes. dnsmasq can be configured to poll a file which lists the nameservers it should use. Sending SIGHUP or whatever it is is a pretty trivial amount of code. Another reason: If dnsmasq is used then there is no need for it to be run as NM's private instance. dnsmasq naturally coexists with bind running as an authoritative nameserver. When NetworkManager handles servers too we can be concerned about the possibility of running an authoritative nameserver alongside it, but for now I'm just not too worried about it. There may be reasons for preferring bind but if they were mentioned then that was before I joined the list. Hopefully someone will clue me in if that is the case. Basically just that it was there and worked. I had a lot of code already written in eggcups for managing cupsd (writing out a conf file, etc), it was easy enough to port to named. If you really really care it shouldn't be too difficult to implement nm-named-manager-dnsmasq.c and do conditional compilation. Not sure if Dan would take the patch, but it's probably not too much of a maintenance burden. Personally though I don't really see the value of spending developer time on replacing bits of NetworkManager's internals (which is essentially what bind is now); better to spend time on the user-visible issues and features like VPN support, reliability, etc. signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DNS problem (forwarding order?)
On Thu, 2005-07-07 at 12:52 -0700, David MacMahon wrote: Dan Williams wrote: Can you file a bug with exactly this information against 'bind' in Red Hat bugzilla? This sounds like a caching nameserver problem more than a NetworkManager one. If you could add me to the CC-list of the bug that would be great too. I'm reluctant to file a bug without first verifying that the forwarders are in fact supposed to be called in order. I've looked through the copy of the BIND 9 Administrator's Reference Manual included with FC4, but I couldn't find any explicit statement about whether forwarders MUST be tried in the order given or MAY be tried in some arbitrary/random order. Do you know where this would be spelled out? Most likely in the BIND code. My guess though given the behavior is it does round-robin. I think the key here is not what BIND does, but what the DHCP specification says. If it says that clients must resolve names using the nameservers given in order, than what NetworkManager is doing is broken. If however it does not specify (this is my guess), then NetworkManager is not doing anything wrong, and the bug would lie in your network setup for giving non-internal nameservers in the DHCP response. In the latter case the internal server should simply forward queries for external names. signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] first pass at gnome-keyring support, baby.
On Wed, 2005-06-22 at 22:02 -0400, Robert Love wrote: Attached patch adds support for gnome-keyring to nm-applet and stores the essid key encrypted in the keyring instead of cleartext in gconf. It is a first pass, but it seems to work well [1]. One issue is it causes the gnome-keyring decrypt your keyring dialog to pop up as soon as the applet loads (presuming that your keyring is not already decrypted, of course). Offtopic, but IMO we should just get rid of that dialog (and the whole keyring access control). It is a pretty small barrier versus a compromised application, confusing to users, and it's also annoying. signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] add a connection information dialog.
On Tue, 2005-06-21 at 15:44 -0400, Robert Love wrote: On Tue, 2005-06-21 at 15:42 -0400, Robert Love wrote: The attached email implements a Connection Information dialog, accessible from the right-click menu, with connection-related information such as IP address, subnet mask, active interface, and so on. I can't really comment as to whether it's a good idea or not, but from a code point of view: You create several different error dialogs like this: + error_dialog = gtk_message_dialog_new_with_markup ( + GTK_WINDOW (info_dialog), + 0, GTK_MESSAGE_ERROR, GTK_BUTTONS_OK, + _(span weight=\bold\ size=\larger \ + Error displaying connection information: + /span\n\n + No active connection!)); Speaking from experience, you'll get yelled at by translators. They don't like having the span in the translated text; they suggest wrapping it in g_strdup_printf, like: msg = g_strdup_printf (span weight=\bold\ size=\larger\%s/span, _(Error displaying connection information: %s)); error_dialog = gtk_message_dialog_new_with_markup (GTK_WINDOW (info_dialog), 0, GTK_MESSAGE_ERROR, GTK_BUTTONS_OK, msg, _(No active connection!)); g_free (msg); And actually looking more closely it looks like you're missing a %s. Also, you have several variants of this message which only differ on one technical detail (Unable to open socket versus SIOCGIFFLAGS failed on socket!), you probably want to extract that to a separate printf so the translators only have to do the Error displaying connection information: string once. Maybe just do a goto socket_error;. signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DBus reconnect support (initial attempt)
On Mon, 2005-03-14 at 17:14 -0800, Tomislav Vujec wrote: On Mon, 14 Mar 2005 18:22:26 -0500, Colin Walters wrote: The system bus will be restarted on reboot, however often that happens. For my personal system that's several times a day, as apm and acpi are broken on my laptop. I think that the fact that acpi is broken on your laptop should be considered a bug. Umm...I'd be the first to agree with you. I was in a same situation a couple of months ago, but ever since I managed to reliably suspend, my uptime holds time difference since the last kernel upgrade. If you run a desktop system, you should include X and gdm in there. Neither are restarted automatically for security updates. I'm sure there are others too that I'm not thinking of. I would argue that there is really no fundamental difference between restarting X and restarting the system. Sure, you have the output of 'uptime', but what you *really* care about is how long it takes you to get back into the desktop session and do work. If we can make the system bootup fast enough (and Windows XP and MacOS X show it's possible), then restarting the whole system isn't a big deal. No matter how optimized the startup procedure really is, it will never be the same as keeping the status of all running applications, which always requires manual interaction. Not necessarily. We could have a way for the system to ask the user sessions do you have any unsaved data. If they don't, and it's between 3am and 5am, and the user hasn't touched the computer in 3 hours, we simply reboot. Note that if apps are written correctly and preserve state otherwise (what documents were open, what web pages were being visited, what IM conversations were active, etc), then to the user there isn't a big difference. Therefore reboot is evil, and it should be avoided at all costs. Now since the dbus serves as a very low service, it might require restart of all dependent applications, which in turn could be very similar to reboot. To me there are two major cases here: 1) Desktop - Here to the user, logging out the desktop == reboot. If as an implementation detail we make rebooting really just restarting some dependency chain which includes X, then what we're really doing is making rebooting faster. 2) Server - If you're running e.g. a production webserver with Apache, then yes, not rebooting is important. But it's not like we're going to just put 'reboot' into the %post of the dbus package. Instead, the smart way to do it is to notify the system administrator that an installed upgrade requires a reboot to take effect. At that point they have a decision to make. Let's say that the dbus upgrade is for a security errata. In that case they evaluate whether dbus is exposed to any threats and whether they can ignore the upgrade for now. If they have no hostile local users, it's probably reasonable to just not reboot. Just like for a lot of the kernel flaws that have been exposed recently. I'll admit here that I am not deeply familiar with the dbus interface, but why shouldn't be possible to reliably wait for d-bus to start again? In theory, it is possible. Just like in theory, you could take the code from a new kernel update and attempt to overlay it into the running kernel, by writing custom upgrade code. My point is that no one is going to make it work reliably. Our current usage of D-BUS is small relative to our plans for it; for example, I'd like it if the packaging system could notify the sessions when a new package is installed (so you can tell the user An update was installed which requires a reboot, if they installed a new kernel or dbus package). There's also some plans to base a new init system on it. All of this becomes significantly more difficult if the bus can randomly go away. You mentioned reliable locking, but my hope would be that the apps can choose between the full restart requirement, and the some kind of graceful handling of the situation. Now the way I see it, a lot of apps could be able to do the graceful handling of the d-bus restart, and therefore it pays of if their status is kept and the user is not forced to restart. The problem is it has to work 100% reliably, for every application, or you have lost any benefit from all of the work. As soon as e.g. some app locks up and the user is unable to save their data (this actually happened to me when I upgraded dbus in Fedora, which screwed HAL, which then screwed gnome-vfs, which in turn screwed gedit), then we lose. Far, far better to require a reboot at the user's convenience for just a few packages and ensure we reliably preserve their data and running applications until they choose to reboot. signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo
Re: DBus reconnect support (initial attempt)
On Tue, 2005-03-15 at 08:01 -0500, Bill Rugolsky Jr. wrote: If it is some huge bloated behemoth that may die due to bugs, Any software can crash due to bugs. The same is true for someone writing some hypothetical D-BUS replacement on top of netlink or whatever. But you might notice that the D-BUS authors care a lot about checking for bugs; for example, there's a lot of unit tests, patches are reviewed carefully, etc. or gets killed by the OOM-killer, etc., The OOM killer is really just a last gasp for the kernel; I've seen several kernel hackers like Alan Cox say that it isn't even guaranteed to kick in or work. I do think we should be able to exclude certain applications from it though like the system bus. then apps must reliably reconnect. If it _can_ crash, it _will_ crash, quite often for certain workloads. D-BUS is designed to be reliable. Anyways, I'm confused as to how we started talking about reliability in a conversation about upgrades. If it is compact, simple, and never crashes, then a less complex model fault model may be appropriate. But, at a minimum, I'd expect the system dbus to be able to checkpoint its state and rexec itself, with file-descriptors held open across exec() if necessary. It certainly wouldn't be the first daemon with such requirements. That's not written though, and we need to work with what we have now. I'd like to see all of networking handled dynamically, so that the Linux networking stack can be used to its full potential. The same is true for storage mgmt (which looks more like networking every day). But if dbus is not going to be as robust as init, What makes you think it's not? signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DBus reconnect support (initial attempt)
On Sun, 2005-03-13 at 23:29 +0100, Tom Parker wrote: One of the things that NM has needed for a while is the ability to properly handle Dbus disconnects, and to reconnect sanely. I don't think we should really try to support this. Restarting D-BUS should be viewed like trying to live-restart a new kernel. There's so many complicated issues in it, and it'll be a rarely-tested code path. Right now it's a bug that the Fedora D-BUS and NetworkManager RPM scripts restart after a package upgrade. You should just have to reboot, IMO. signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DBus reconnect support (initial attempt)
On Tue, 2005-03-15 at 00:27 +0200, Paul Ionescu wrote: On Mon, 14 Mar 2005 14:00:50 -0500, Colin Walters wrote: On Sun, 2005-03-13 at 23:29 +0100, Tom Parker wrote: One of the things that NM has needed for a while is the ability to properly handle Dbus disconnects, and to reconnect sanely. I don't think we should really try to support this. Restarting D-BUS should be viewed like trying to live-restart a new kernel. I think there are some people already doing this. (live-restart a new kernel) I doubt they'll get anywhere. It's just a nearly insoluble problem. There's so many complicated issues in it, and it'll be a rarely-tested code path. Right now it's a bug that the Fedora D-BUS and NetworkManager RPM scripts restart after a package upgrade. You should just have to reboot, IMO. I hope this is a joke. If not, then this sounds a lot like MS Windows. Not everything Windows does is bad. And nowadays, to reboot a FC4 takes ages (far more than MS windows), so let's try to decrease the number of reboots. Totally agreed! So let's spend time fixing that bug. People are already working on it. It is enough that we need to reboot after a kernel upgrade, please don't make us reboot after upgrading any other package x,y,z. No one is suggesting you be forced to reboot after upgrading immediately. But in order to get the upgrade functionality, yes, you will have to reboot. The way Windows XP security updates work is actually really nice; if you're not using the computer it just reboots it for you, otherwise it gives you a notification that you should reboot at some point soon. Hopefully we'll get notifications landed for GNOME 2.12 and we'll be able to do something similar. signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DBus reconnect support (initial attempt)
[ CC'ing dbus list as this discussion is important for writers of D-BUS applications and for packagers ] On Mon, 2005-03-14 at 23:49 +0100, Tom Parker wrote: I'd disagree. Yes, it'll be a pain in the ass to get right, and yup this ain't exactly going to be the most tested code path. I'm certain your posted code is full of races and problems; you just set the connection to NULL, but NetworkManager has a number of threads and idle handlers which are not expecting it to be NULL. Some of the code has g_return_if_fail (connection != NULL), but at best you get lots and lots of error spew, and at worst NetworkManager segfaults. These failure modes are a lot worse than simply running an old instance, reliably. However, I don't think that restarting D-BUS should be counted as anywhere even close to being like a new kernel. The kernel has a lot of jobs, but really it comes down to two things: 1) Drivers for hardware 2) Providing the required locking for inter-process communication, via the filesystem or sockets, etc. D-BUS is exactly like 2. Heck, I'd rather if we didn't have to restart for new kernels (hello kexec...), kexec is just a faster way of rebooting (hence the name exec which implies resetting state); it doesn't magically upgrade you to a newer kernel while it's running. and I certainly can't see any reason why we should restart for D-BUS. Because it's too hard, and creates user expectations which will ultimately not be met. Especially as despite the fact that more and more other tools are starting to become reliant on D-BUS, it should still just be treated as just another service. But the difference with D-BUS is that it provides reliable communication semantics between those services. If the bus can go away arbitrarily, you lose that. Even if it's just on desktop machines, it's still very annoying when you have to restart your machine to install something, as opposed to a few seconds of downtime while the old version is removed and the new version brought up. No one is suggesting you have to reboot to install something. Windows doesn't require that either. I'm just suggesting that for a few critical packages such as dbus and NetworkManager, you don't get the new functionality or security update until you reboot. Given that D-BUS will occasionally (weeks, months) get restarted, we have 3 choices The system bus will be restarted on reboot, however often that happens. For my personal system that's several times a day, as apm and acpi are broken on my laptop. 1) [...] 2) [...] 3) [...] The alternative I am suggesting is: 0) Assume the bus never goes away, and make sure distributors don't restart dbus or NetworkManager in package upgrade scripts My 2p. I think restarts of a whole system should be avoided, and that graceful degradation is the way to go. I agree they should be avoided, but I would much rather have a system that works 100% reliably on upgrades but requires occasional fast reboots (and we could do plenty to optimize it) for a few packages, instead of a system which works 75% of the time but the other 25% causes random hard-to-debug application crashes and eventually requires a reboot anyways to sort out. For people on the dbus list, the initial thread is here: http://mail.gnome.org/archives/networkmanager-list/2005-March/msg00022.html signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: CVS 8/2 compile error
On Tue, 2005-02-08 at 13:34 +0100, Tom Parker wrote: Getting errors on NetworkManagerDevice.c, because I don't appear to have a pci/types.h. No idea where the heck this would be (on a Debian system), but then worked out that we only needed a few types from it and so wrote a patch. Index: src/NetworkManagerDevice.c === RCS file: /cvs/gnome/NetworkManager/src/NetworkManagerDevice.c,v retrieving revision 1.91 diff -u -r1.91 NetworkManagerDevice.c --- src/NetworkManagerDevice.c 7 Feb 2005 23:04:05 - 1.91 +++ src/NetworkManagerDevice.c 8 Feb 2005 12:32:11 - @@ -3600,7 +3600,10 @@ /**/ /*Ethtool capability detection*/ /**/ -#include pci/types.h +typedef unsigned long long u64; +typedef unsigned int u32; +typedef unsigned short u16; +typedef unsigned char u8; #include linux/sockios.h #include linux/ethtool.h Hmm. Why not port the code to the glib typedefs (e.g. guint32) instead? While those typedefs are correct (AFAIK) on all the important platforms that Linux runs on today, there's no guarantee that in the future e.g. int will be 32 bits. On such a platform the code will probably start failing mysteriously. signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
