Bug#554194: ifupdown virtual package name and mass-filing (if accepted)
On Sat, Jan 16, 2010 at 03:31:28PM +0100, Wouter Verhelst wrote: There was no further discussion on this item since the above date. FWIW, I for one hadn't commented up to now because I find that fundamentally, implementing a compatible commandline interface for ifup/ifdown and not implementing support for /etc/network/interfaces is precisely backwards, and I was waiting to see if anyone else would speak to this point. AFAICS, there are only two places in the system where other packages integrate by calling ifup/ifdown: /etc/init.d/networking, and /lib/udev/net.agent. The former ought to be all but obsoleted by the latter (N.B.: should, but isn't), and the latter could just as well be moved to the ifupdown package itself and a corresponding agent be provided by any conflicting packages. So the commandline ifup/ifdown interface is of little relevance, whereas the configuration state contained in /etc/network/interfaces is of vital importance to the operation of the system and I would expect anyone trying to replace ifupdown to handle this critical configuration migration issue. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#554194: ifupdown virtual package name and mass-filing (if accepted)
On Mon, Jan 18, 2010 at 01:56:17AM -0800, Steve Langasek wrote: On Sat, Jan 16, 2010 at 03:31:28PM +0100, Wouter Verhelst wrote: There was no further discussion on this item since the above date. FWIW, I for one hadn't commented up to now because I find that fundamentally, implementing a compatible commandline interface for ifup/ifdown and not implementing support for /etc/network/interfaces is precisely backwards, and I was waiting to see if anyone else would speak to this point. AFAICS, there are only two places in the system where other packages integrate by calling ifup/ifdown: /etc/init.d/networking, and /lib/udev/net.agent. The former ought to be all but obsoleted by the latter (N.B.: should, but isn't), and the latter could just as well be moved to the ifupdown package itself and a corresponding agent be provided by any conflicting packages. Indeed. In fact, I had assumed that that initscript was, indeed, part of the ifupdown package; so much so, in fact, that I hadn't even checked. Thanks for pointing that out. So the commandline ifup/ifdown interface is of little relevance, whereas the configuration state contained in /etc/network/interfaces is of vital importance to the operation of the system and I would expect anyone trying to replace ifupdown to handle this critical configuration migration issue. It's a fair point, but one I happen not to agree with. As an example, ifplugd has a default configuration that calls 'ifup' when it discovers that the MII reports a link. I think this is a valid case of something using the 'ifup' binary, and not something that needs to be migrated away (at least not until the daemon functionality of ipcfg has been implemented, which might take a while). That's a third example (added to your two above); I'm sure there are more. I think the use of ifup/ifdown as an interface to manage network interfaces (no pun intended) is more widespread than you seem to believe. Second, the main reason I chose not to support the /etc/network/interfaces at this phase is that I believe it is fundamentally limited in what it can support: it makes the assumption that whenver the user calls 'ifup something', we already know which interfaces we're going to be configuring. I specifically do not wish to support that assumption. Now of course I could extend the interfaces format to allow this, but I'm afraid that's going to be kludgy at best. That's why I started off with a different file format. Of course upgradeability is a major cause for concern, and if ipcfg is ever going to replace ifupdown then at one point or another I'll have to deal with this issue. I'm not sure yet how I'll be doing that; it could be by way of a perl script to convert an interfaces file to an ipcfg config file, or it could be by way of an alternate parser. It's not something I want to deal with now, however -- first things first; while it's in experimental now, I don't think it'll be ready for unstable in time for squeeze -- I'd even be surprised if it was ready for prime time in time for squeeze+1. Third, I do not see any good reason why any configuration file format should be part of a described interface. If another software package wishes to do something with network interfaces consistently with ifup's configuration, then that package should not try to read ifup's config file -- it should be calling ifup with the necessary parameters to accomplish what it needs to do. We might need to extend the interface to allow querying of available configuration to allow this better, but that's about it. If another package wishes to write ifup's configuration file, then either it is doing something utterly wrong and against policy, or it is a user configuration agent that needs to know much about the inner workings of the particular ifup implementation it is working for anyway, and has no business depending on a virtual package. Regards, -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554194: ifupdown virtual package name and mass-filing (if accepted)
On Sat, Jan 16, 2010 at 06:09:19PM +0100, Bill Allombert wrote: On Sat, Jan 16, 2010 at 03:31:28PM +0100, Wouter Verhelst wrote: On Thu, Nov 05, 2009 at 09:54:37AM +0100, martin f krafft wrote: [...response that is not very relevant to this mail...] There was no further discussion on this item since the above date. Since I've recently uploaded ipcfg, I'd like this to be finalized. It currently uses 'ifupdown' as the name to conflict/replace/provide, but I don't consider that to be a particularly good idea. I'm suggesting that the package name 'network-config-tool' be described as a tool for a package providing 'ifup' and 'ifdown' binaries. These should provide the following interface: - support 'ifup interface name' or 'ifdown interface name' to bring an interface up or down, consistently with configuration, and exit with non-zero if either operation fails. Is ifup eth0=foo supported ? Should be fairly easy to add that to ipcfg, which might be a good idea. Let's make that part of the interface, too. - may provide a virtual interface name that does not map to an actual physical interface name, but instead uses internal logic to decide what to do. Is not there a namespace issues wrt other interface that should be clarified ? There are namespace issues, but I don't think they should be explained in the interface specification; the tools should do so in their documentation. This is a may part of the specification, not a should. - ifup and ifdown should support a '-a' or '--all' option to configure or deconfigure 'all' interfaces. Here, 'all' is defined as 'all interfaces for which the tool's configuration defines that they should be brought up or down with the -a option'. OK. - ifup and ifdown should support a '-v' or '--verbose' option to aid in debugging. This requirement does not feel necessary. If a tool calls ifup, it may wish to call it with -v to provide some output to the user should bringing the interface up fail, which can be useful. Perhaps it should be clarified that the output format of -v is undefined. - ifup and ifdown should support hook scripts in /etc/network/if-*.d: - the tool should provide a way for the user to set configuration values through environment variables, the name of which start with IF_ - the tool should provide PHASE and MODE variables, describing what we're trying to do - (since I could not find a formal specification of the if-*.d hook script interface, I may have missed some things; if so, please let me know) Obviously this also needs the IFACE= environment variable, defining the interface on which we work. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554194: ifupdown virtual package name and mass-filing (if accepted)
On Sun, Jan 17, 2010 at 10:11:58AM +0100, Wouter Verhelst wrote: On Sat, Jan 16, 2010 at 06:09:19PM +0100, Bill Allombert wrote: an interface up or down, consistently with configuration, and exit with non-zero if either operation fails. Is ifup eth0=foo supported ? Should be fairly easy to add that to ipcfg, which might be a good idea. Let's make that part of the interface, too. OK. - may provide a virtual interface name that does not map to an actual physical interface name, but instead uses internal logic to decide what to do. Is not there a namespace issues wrt other interface that should be clarified ? There are namespace issues, but I don't think they should be explained in the interface specification; the tools should do so in their documentation. I mention it to avoid e.g. eth0=foo to have a very different meaning in each implementation. - ifup and ifdown should support a '-v' or '--verbose' option to aid in debugging. This requirement does not feel necessary. If a tool calls ifup, it may wish to call it with -v to provide some output to the user should bringing the interface up fail, which can be useful. Perhaps it should be clarified that the output format of -v is undefined. OK then. The point is that it should be safe to call 'ifup -v' to get some detail (if any). Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554194: ifupdown virtual package name and mass-filing (if accepted)
On Thu, Nov 05, 2009 at 09:54:37AM +0100, martin f krafft wrote: [...response that is not very relevant to this mail...] There was no further discussion on this item since the above date. Since I've recently uploaded ipcfg, I'd like this to be finalized. It currently uses 'ifupdown' as the name to conflict/replace/provide, but I don't consider that to be a particularly good idea. I'm suggesting that the package name 'network-config-tool' be described as a tool for a package providing 'ifup' and 'ifdown' binaries. These should provide the following interface: - support 'ifup interface name' or 'ifdown interface name' to bring an interface up or down, consistently with configuration, and exit with non-zero if either operation fails. - may provide a virtual interface name that does not map to an actual physical interface name, but instead uses internal logic to decide what to do. - ifup and ifdown should support a '-a' or '--all' option to configure or deconfigure 'all' interfaces. Here, 'all' is defined as 'all interfaces for which the tool's configuration defines that they should be brought up or down with the -a option'. - ifup and ifdown should support a '-v' or '--verbose' option to aid in debugging. - ifup and ifdown should support hook scripts in /etc/network/if-*.d: - the tool should provide a way for the user to set configuration values through environment variables, the name of which start with IF_ - the tool should provide PHASE and MODE variables, describing what we're trying to do - (since I could not find a formal specification of the if-*.d hook script interface, I may have missed some things; if so, please let me know) Comments are welcome. [aj: I haven't seen any comment from you on this, and would like to make sure that you're comfortable with whatever interface we come up with -- please comment.] -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554194: ifupdown virtual package name and mass-filing (if accepted)
On Sat, Jan 16, 2010 at 03:31:28PM +0100, Wouter Verhelst wrote: On Thu, Nov 05, 2009 at 09:54:37AM +0100, martin f krafft wrote: [...response that is not very relevant to this mail...] There was no further discussion on this item since the above date. Since I've recently uploaded ipcfg, I'd like this to be finalized. It currently uses 'ifupdown' as the name to conflict/replace/provide, but I don't consider that to be a particularly good idea. I'm suggesting that the package name 'network-config-tool' be described as a tool for a package providing 'ifup' and 'ifdown' binaries. These should provide the following interface: - support 'ifup interface name' or 'ifdown interface name' to bring an interface up or down, consistently with configuration, and exit with non-zero if either operation fails. Is ifup eth0=foo supported ? - may provide a virtual interface name that does not map to an actual physical interface name, but instead uses internal logic to decide what to do. Is not there a namespace issues wrt other interface that should be clarified ? - ifup and ifdown should support a '-a' or '--all' option to configure or deconfigure 'all' interfaces. Here, 'all' is defined as 'all interfaces for which the tool's configuration defines that they should be brought up or down with the -a option'. OK. - ifup and ifdown should support a '-v' or '--verbose' option to aid in debugging. This requirement does not feel necessary. - ifup and ifdown should support hook scripts in /etc/network/if-*.d: - the tool should provide a way for the user to set configuration values through environment variables, the name of which start with IF_ - the tool should provide PHASE and MODE variables, describing what we're trying to do - (since I could not find a formal specification of the if-*.d hook script interface, I may have missed some things; if so, please let me know) Can't comment. [aj: I haven't seen any comment from you on this, and would like to make sure that you're comfortable with whatever interface we come up with -- please comment.] I agree that the agreement of the ifupdown maintainers is very important. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. signature.asc Description: Digital signature
Bug#554194: ifupdown virtual package name and mass-filing (if accepted)
also sprach Wouter Verhelst wou...@debian.org [2009.11.04.0230 +0100]: Since to me the point of this exercise is so that I can usefully put ipcfg into the archive, and since ipcfg does not actually support /etc/network/interfaces, I'd say that should not be part of the interface. Hehe, but interface definitions usually describe the status quo from the users' perspective, not the state of development of a new tool aiming interface compatibility. Gosh, I wish the ISO 9000 specs worked that way! ;) It *is* questionable how mucn /e/n/i is part of the interface though. I do have code to support /etc/network/if-*.d/*, though I consider that a temporary hack so that the code would be useful sooner rather than later. It also doesn't work yet ;-) Okay. I definitely think the hooks are part of the interface that we need to support in any network configuration tool. Especially the hooks are integral to a lot of other packages that depend on ifupdown. I'd say that's part of any Debian network-config-tool interface. Basically, the interface that I'd like to see is tool that can bring up a given interface as configured by the user. E.g., if ifplugd calls ifup eth0, it should not care which implementation of ifup is being called to actually bring the interface up. Yes. But there are tools that will call it with --verbose, or with --all. I think we agree anyway. Depends: (...), ifupdown (= 0.6.8+nmu3) | network-config-tool, (...) because this is a matter of we need at least this version of ifupdown to work properly rather than we absolutely need ifupdown; after all, it's ifupdown or ipcfg that calls dhclient, not the other way around. That does seem weird and should not be needed, indeed. Cheers, -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems i love deadlines. i like the whooshing sound they make as they fly by. -- douglas adams digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#554194: ifupdown virtual package name and mass-filing (if accepted)
On Wed, Nov 04, 2009 at 10:52:00AM +0100, martin f krafft wrote: also sprach Wouter Verhelst wou...@debian.org [2009.11.04.0230 +0100]: Since to me the point of this exercise is so that I can usefully put ipcfg into the archive, and since ipcfg does not actually support /etc/network/interfaces, I'd say that should not be part of the interface. Hehe, but interface definitions usually describe the status quo from the users' perspective, not the state of development of a new tool aiming interface compatibility. Gosh, I wish the ISO 9000 specs worked that way! ;) That'd be nice, wouldn't it? ;-) It *is* questionable how mucn /e/n/i is part of the interface though. Indeed, and that's really my main point. I could also have said that I don't want to be command-line compatible because it's too much work, but it's *not* questionable how much *that* is part of the interface, so yes, that I do intend to be compatbile with. A config file format is something else; and since, first, Debian packages are not supposed to modify eachother's configuration files; and, second, ifupdown makes the relevant values in its configuration file available through environment variables (so that ifupdown plugins don't have to parse the ifupdown config file), I think it's not unreasonable to make the config file format not part of the interface. Since that would make it easier for me (I'm not aiming for ifupdown config file compatibility, at all), I'd prefer it that way. Of course we could define an interface that requires things to be drop-in replacements for ifupdown, but then I can't use it, and I don't think there's much point in defining a virtual package that ifupdown (and ifupdown alone) could put in its Provides: header. Instead, what I'm trying to accomplish is to come up with an interface that can be used by packages which want to mangle the state of network interfaces without actually caring much about how, specifically, it's done. Since I don't think it can be said that you don't care about that if you care about a config file format, I think it's fair to exclude that from this interface. I do have code to support /etc/network/if-*.d/*, though I consider that a temporary hack so that the code would be useful sooner rather than later. It also doesn't work yet ;-) Okay. I definitely think the hooks are part of the interface that we need to support in any network configuration tool. I'm not sure I fully agree with that, but since the code is there, and since it's a plugin that can be disabled, I don't actually care all that much about the issue. So yeah, that can be kept in for all I care :-) Especially the hooks are integral to a lot of other packages that depend on ifupdown. I'd say that's part of any Debian network-config-tool interface. Basically, the interface that I'd like to see is tool that can bring up a given interface as configured by the user. E.g., if ifplugd calls ifup eth0, it should not care which implementation of ifup is being called to actually bring the interface up. Yes. But there are tools that will call it with --verbose, or with --all. I think we agree anyway. Supporting --all should not be hard. Basically, I just need to map --all to ifup auto or ifdown all internally. That's a no-brainer. Supporting --verbose might be a different issue, and depending on how it's used, might be a bad idea to support from ipcfg. If the --verbose output is just used to log stuff or give a user more information, then that doesn't matter, and I intend to have a --verbose output option, anyhow. If these commands are parsed and executed somewhere else, it might be possible to make sure the --verbose option does some output that these tools can parse, too, but it's an edge case. If the tools try to parse that information to figure out how to bring an interface down again later or some such, then they're really exploiting the fact that ifupdown exposes much about its internals, and it might be said that the statement that they don't care about how it's done is no longer true for these tools. Depends: (...), ifupdown (= 0.6.8+nmu3) | network-config-tool, (...) because this is a matter of we need at least this version of ifupdown to work properly rather than we absolutely need ifupdown; after all, it's ifupdown or ipcfg that calls dhclient, not the other way around. That does seem weird and should not be needed, indeed. Actually, I think Andrew should have made that a versioned Conflicts: rather than a versioned Depends:. I vaguely remember him blogging about ISC DHCP4 not working properly with ifupdown and that the latter needed patches. I guess this version is the first one where these patches are included. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html
Bug#554194: ifupdown virtual package name and mass-filing (if accepted)
also sprach Wouter Verhelst w...@uter.be [2009.11.03.1915 +0100]: As such, I'd like to propose the addition of a virtual package name, network-config-tool, that would be used for any package which provides /sbin/ifup and /sbin/ifdown binaries. You'll need to be a lot more specific on the interface definition. Do they have to be binaries? Do they have to take the same flags, e.g. --force and --all? What about /etc/network/interfaces and /etc/network/if-*.d/*? Especially the hooks are integral to a lot of other packages that depend on ifupdown. I'd say that's part of any Debian network-config-tool interface. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#554194: ifupdown virtual package name and mass-filing (if accepted)
On Tue, Nov 03, 2009 at 08:02:31PM +0100, martin f krafft wrote: also sprach Wouter Verhelst w...@uter.be [2009.11.03.1915 +0100]: As such, I'd like to propose the addition of a virtual package name, network-config-tool, that would be used for any package which provides /sbin/ifup and /sbin/ifdown binaries. You'll need to be a lot more specific on the interface definition. Do they have to be binaries? Do they have to take the same flags, e.g. --force and --all? With 'binaries', I meant 'executables'. Whether they're scripts or compiled programs doesn't actually matter to me. Sorry for the confusion. The goal is indeed for ipcfg to become command-line compatible with ifupdown, though I'm not there yet. What about /etc/network/interfaces and /etc/network/if-*.d/*? Since to me the point of this exercise is so that I can usefully put ipcfg into the archive, and since ipcfg does not actually support /etc/network/interfaces, I'd say that should not be part of the interface. I do have code to support /etc/network/if-*.d/*, though I consider that a temporary hack so that the code would be useful sooner rather than later. It also doesn't work yet ;-) (occasionally, that's the only reason why it's not been uploaded yet) Especially the hooks are integral to a lot of other packages that depend on ifupdown. I'd say that's part of any Debian network-config-tool interface. Basically, the interface that I'd like to see is tool that can bring up a given interface as configured by the user. E.g., if ifplugd calls ifup eth0, it should not care which implementation of ifup is being called to actually bring the interface up. However, it should also be sensible to change the Depends: line in isc-dhcp-client from Depends: (...), ifupdown (= 0.6.8+nmu3), (...) to Depends: (...), ifupdown (= 0.6.8+nmu3) | network-config-tool, (...) because this is a matter of we need at least this version of ifupdown to work properly rather than we absolutely need ifupdown; after all, it's ifupdown or ipcfg that calls dhclient, not the other way around. Of course there are some packages that just don't make sense without ifupdown, and there it's fine to not add the network-config-tool alternative. One example of this is guessnet; ipcfg has a much more flexible way of doing what guessnet does (in fact it's a design goal), and therefore does not have support for ifupdown's mapping scripts that guessnet uses. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html signature.asc Description: Digital signature
Bug#554194: ifupdown virtual package name and mass-filing (if accepted)
Package: debian-policy Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org, ifupd...@packages.debian.org Hi all, As you may or may not know, I've been working on an alternative implementation of ifup and ifdown, which I call 'ipcfg', for a few months now[1]. The code is now nearly at the point where I'll be using it on my own laptop, at which point I intend to upload it to experimental, too. Since it intends to be an ifupdown replacement, and indeed provides ifup and ifdown binaries, it will have to conflict with ifupdown. As a result, I'll have to make sure that it can be installed as an alternative to it, by way of a virtual package name. As such, I'd like to propose the addition of a virtual package name, network-config-tool, that would be used for any package which provides /sbin/ifup and /sbin/ifdown binaries. If accepted, I will also be mass-filing wishlist bugs on packages that currently depend on ifupdown only because they need to be able to use ifup and ifdown, or because they have a versioned dependency on ifupdown to avoid certain bugs, with a request to provide a network-config-tool alternative. Thoughts, comments? [1] The announcement and some more detail can be found at http://grep.be/blog/en/computer/code/ipcfg/announce -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html signature.asc Description: Digital signature
