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 7/29/05, Colin Walters [EMAIL PROTECTED] wrote: 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. Hmm. Thinking back, the reason I first looked into this was the following sequence of events: 1) I had resolvconf already installed. 2) I installed NetworkManager through Ubuntu's Multiverse repo. The package had a dependency on resolvconf, btw (although this is clearly an error on the part of the packager). 3) That version of NetworkManager simply did not work (no offense, current CVS works great), and so I eventually removed it. 4) Ifup-ing my network resulted in no name service because the symlink had been replaced with an empty file. No problem to fix once, but it got annoying as I went through several iterations of starting NM, stopping it, and bringing up my network manually so I could research the problem. It never actually occured to me to simply remove the resolvconf package. In my mind, resolvconf has become The Way it Works rather than a tool to deal with special configurations. 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. But playing nice with resolvconf is so easy, I just don't understand the objection to it. 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? The former. My laptop is the only machine that runs NM. All my machines have resolvconf. -- Will Dyson ___ 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
format string bug in nm_info_handler
static void
nm_info_handler (const gchar*log_domain,
GLogLevelFlags log_level,
const gchar *message,
gboolean is_daemon)
{
...
syslog (syslog_priority, message);
}
This should read:
syslog (syslog_priority, %s, message);
I can't figure out whether this is exploitable. That would depend on
what kinds of messages an attacker could get passed g_log.
Ian.
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
