Re: Ifupdown dysfunctional, is a Provides: interface possible please?
Le 28/03/2014 08:23, Matt Grant a écrit : One thing that put me off ifupdown quite some time ago was finding that configured bridges made NFS client mounts on the host wait... who would implement a bridge with interface listen/wait/STP functionality on a pure work station or server? Sounds like a router/firewall, and they should not be nfs mounting by their nature and functionality ... Real corner case stuff. A work station or server can run virtual machines connected via a bridge and mount staff via NFS. This is not a corner case to me. Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53366fc9.90...@debian.org
Re: Ifupdown dysfunctional, is a Provides: interface possible please?
Stéphane Glondu glo...@debian.org writes: Le 28/03/2014 08:23, Matt Grant a écrit : One thing that put me off ifupdown quite some time ago was finding that configured bridges made NFS client mounts on the host wait... who would implement a bridge with interface listen/wait/STP functionality on a pure work station or server? Sounds like a router/firewall, and they should not be nfs mounting by their nature and functionality ... Real corner case stuff. A work station or server can run virtual machines connected via a bridge and mount staff via NFS. This is not a corner case to me. It's also not unusual to do this sort of thing in a small home network. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87k3bdiixu@windlord.stanford.edu
Re: Ifupdown dysfunctional, is a Provides: interface possible please?
On Sat, 29 Mar 2014 01:34:27 -0400 (EDT), Andrei POPESCU wrote: Or connman. Frankly, I think that the claim that ifupdown is dysfunctional is an exaggeration at best and untrue at worst. I am not claiming that it is bug free; but in my experience, it works just fine; and I see no compelling reason to replace it. My two cents worth. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/966103792.557666.1396101912817.javamail.r...@md01.wow.synacor.com
Re: Ifupdown dysfunctional, is a Provides: interface possible please?
* Stephen Powell (zlinux...@wowway.com) [140329 15:05]: On Sat, 29 Mar 2014 01:34:27 -0400 (EDT), Andrei POPESCU wrote: Or connman. Frankly, I think that the claim that ifupdown is dysfunctional is an exaggeration at best and untrue at worst. I am not claiming that it is bug free; but in my experience, it works just fine; and I see no compelling reason to replace it. I'd put it as works very good for servers, but for roaming laptop usage there could be something better. However, I fail to see yet any which is the better[1] (perhaps guessnet was, but it is removed from testing currently). Andi [1] means e.g. auto-detection of wlans, automatically connecting through whatever there is - wpa psk, portals, dns tunnels, or whatever else, auto-setup of proxies as required, ... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140329143728.gd16...@mails.so.argh.org
Re: Ifupdown dysfunctional, is a Provides: interface possible please?
On Sat, 29 Mar 2014 15:37:28 +0100, Andreas Barth a...@ayous.org wrote: * Stephen Powell (zlinux...@wowway.com) [140329 15:05]: On Sat, 29 Mar 2014 01:34:27 -0400 (EDT), Andrei POPESCU wrote: Or connman. Frankly, I think that the claim that ifupdown is dysfunctional is an exaggeration at best and untrue at worst. I am not claiming that it is bug free; but in my experience, it works just fine; and I see no compelling reason to replace it. I'd put it as works very good for servers, but for roaming laptop usage there could be something better. However, I fail to see yet any which is the better[1] (perhaps guessnet was, but it is removed from testing currently). Network Manager is the solution with clearly the smallest amount of configuration options, but it covers the case notebook with varying WLAN and Ethernet connections quite well. I have given up on my old scheme that automatically configures customer-based local DNS zones and web proxies and am now configuring this manually whenever I change locations. This is a big step back since what we had five years ago, but that's how things go these days: Useful Features are sacrificed for modern ways to do things. wicd is more configurable than network manager, but is mostly unmaintained these days, and still leaves wishes for configuration unfilled. For any decently complex setup such as a firewall or a VM host, ifupdown is still _the_ most functional way to go with no real viable alternative. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1wtxje-00086k...@swivel.zugschlus.de
Re: Ifupdown dysfunctional, is a Provides: interface possible please?
El Fri, 28 de Mar 2014 a las 2:28 AM, Josselin Mouette j...@debian.org escribió: Le vendredi 28 mars 2014 à 20:23 +1300, Matt Grant a écrit : I sincerely would like to work with the ifupdown maintainer and systemd/udev crew to work all this out. A basic level/interface of functionality for replaceable network configuration packages would be nice. Alternatively, we could make NetworkManager the default. It is already here, it works, and it doesn’t have such problems. NetworkManager, as well as Connman, would essentially prevent a network mounted /usr (as well as wicd I believe, but need to check). networkd is the only option that *improves* the situation, and does not worsen it (a network mounted /usr with ifupdown is hard because wpa_supplicant requires some libraries that are in /usr/lib, but much less so than nm or connman, both of which reside in /usr themselves). networkd was specifically created to allow for even deeper remote fs situations (specifically, network mounted root). I think any change to a new network configuration should not ignore the scenario of a network mounted /usr, as NM and connman seem to have done. My 2¢, -- Cameron Norman
Ifupdown dysfunctional, is a Provides: interface possible please?
Hi! I am the developer of netscript-2.4, an alternative network configuration system for Debian written in /bin/bash - quite old. First of all, though, my stuff is not the glorious gloopiest best. I have split the iptables stuff out to netscript-ipfilter, better than iptables-persistent I must say though! But I still persist with it as I find some things about ifupdown rather not good. eg: web: -root- [~] # ip link 1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000 link/ether 52:54:00:97:5a:d6 brd ff:ff:ff:ff:ff:ff web: -root- [~] # ip link set dev eth0 down web: -root- [~] # ifup eth0 ifup: interface eth0 already configured web: -root- [~] # ip link show dev eth0 2: eth0: BROADCAST,MULTICAST mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT qlen 1000 link/ether 52:54:00:97:5a:d6 brd ff:ff:ff:ff:ff:ff web: -root- [~] # Eh what??? ifupdown also cannot add an additional address/subnet to an interface without shutting the interface down and restarting it. Kernel allows it, why not? My package does provide command line compatibility though, and gives ifupdown as a Provides: I have found that the version dependency of resolvconf on ifupdown (= 0.7.5) breaks the Provides on my package... Also, there is quite some scripting glue going on down in udev... Have a look at /lib/udev/net.agent ifupdown also has a whole forest of shell scripts for it in other packages as well. Very similar to sysvinit/systemd stuff we have already gone through. One thing that put me off ifupdown quite some time ago was finding that configured bridges made NFS client mounts on the host wait... who would implement a bridge with interface listen/wait/STP functionality on a pure work station or server? Sounds like a router/firewall, and they should not be nfs mounting by their nature and functionality ... Real corner case stuff. I sincerely would like to work with the ifupdown maintainer and systemd/udev crew to work all this out. A basic level/interface of functionality for replaceable network configuration packages would be nice. I KNOW MY STUFF COULD/SHOULD BE BETTER! Maybe I should reimplement a lot of it using only what is provided by perl-base and /bin/sh, but lets get some sense here please. I also compatibility for upgrades is required, but how compatible does any intentional replacement for ifupdown have to be, especially if the system a firewall or a router? Regards, Matt Grant -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1395991395.16475.25.ca...@moriah.internal.anathoth.net
Re: Ifupdown dysfunctional, is a Provides: interface possible please?
Hello, On Fri, 28 Mar 2014 20:23:15 +1300 Matt Grant m...@mattgrant.net.nz wrote: I KNOW MY STUFF COULD/SHOULD BE BETTER! Maybe I should reimplement a lot of it using only what is provided by perl-base and /bin/sh, but lets get some sense here please. Thanks for the rant, it's been considered. I hope you feel better now, do you? Good. When you calm down and have anything useful to contribute, you're welcome. Please also note that's there's no point in rewriting ifupdown from scratch to provide the same interface; the existing code is good enough for what it does currently, it just needs to be improved. Unfortunately, I don't have enough time currently to implement functionality I'd like to, or to fix some issues which bother me and other people. -- Cheers, Andrew signature.asc Description: PGP signature
Re: Ifupdown dysfunctional, is a Provides: interface possible please?
Le vendredi 28 mars 2014 à 20:23 +1300, Matt Grant a écrit : I sincerely would like to work with the ifupdown maintainer and systemd/udev crew to work all this out. A basic level/interface of functionality for replaceable network configuration packages would be nice. Alternatively, we could make NetworkManager the default. It is already here, it works, and it doesn’t have such problems. Cheers, -- .''`.Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1395998926.5311.65.camel@dsp0698014
Re: Ifupdown dysfunctional, is a Provides: interface possible please?
On Fri, Mar 28, 2014 at 5:28 PM, Josselin Mouette wrote: Alternatively, we could make NetworkManager the default. It is already here, it works, and it doesn’t have such problems. Or systemd-networkd. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKTje6Hzsmc=_w4dfzfasxuvj4fu64nhfz33rh1-kygv4vg...@mail.gmail.com
Re: Ifupdown dysfunctional, is a Provides: interface possible please?
Hi Andrew, I am willing to co-maintain it with you and evolve it. Previously I have worked professionally as a router programmer, and have contributed to Quagga/Zebra OSPF. Please also note that's there's no point in rewriting ifupdown from scratch to provide the same interface; the existing code is good enough for what it does currently, it just needs to be improved. Unfortunately, I don't have enough time currently to implement functionality I'd like to, or to fix some issues which bother me and other people. OK, I agree with this to. Too much does depend on it to rip it out. It has to be kept backwards compatible. Some good work has been done since wheezy (or squeeze) dropping the need for Linux 2.2.x sub-interface names like 'eth0:0' being required to bring up extra interface addresses. Are they still required for kFreeBSD and GNU/HURD? We do need to keep old /etc/network/interfaces files working :-) Would interface state file business be a good place to look at first? I believe I have some good ideas on how it should be done. It would be good to wiki them first, and other possible design changes, and see what others have to contribute. From netscript, I have split the iptables stuff in netscript-2.4 into its own package netscript-ipfilter. That is the most important stuff in there now, and has to be stand alone from network configuration to benefit most systems. Its a better alternative to eg iptables-persistent as it keeps a saved history of so many versions, and provides roll back support, 'helper' chains for IPv6/IPv4 ICMP filtering, border router address checking etc (more important now everyone is getting an IPv6 subnet, no NAT). Not to knock anything, other systems may be better depending on your tastes for firewall/packet filtering. Nftables are coming to replace iptables in the kernel. Lets get some more sense into ifupdown, making it more versatile and take the corners off it operationally. I'd like to be able to send netscript to its grave in a few years :-) Regards, Matt Grant -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1396004493.16475.72.ca...@moriah.internal.anathoth.net
Re: Ifupdown dysfunctional, is a Provides: interface possible please?
Paul Wise pabs at debian.org writes: On Fri, Mar 28, 2014 at 5:28 PM, Josselin Mouette wrote: Alternatively, we could make NetworkManager the default. It is already here, it works, and it doesn’t have such problems. Or systemd-networkd. I surely hope the both of you are kidding. bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/loom.20140328t124555-...@post.gmane.org
Re: Ifupdown dysfunctional, is a Provides: interface possible please?
Le vendredi 28 mars 2014 à 11:45 +, Thorsten Glaser a écrit : Paul Wise pabs at debian.org writes: On Fri, Mar 28, 2014 at 5:28 PM, Josselin Mouette wrote: Alternatively, we could make NetworkManager the default. It is already here, it works, and it doesn’t have such problems. Or systemd-networkd. I surely hope the both of you are kidding. The only joke is to be stuck with ifupdown and its design in total contradiction with the current way the kernel works. Cheers, -- .''`.Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1396008168.5311.81.camel@dsp0698014
Re: Ifupdown dysfunctional, is a Provides: interface possible please?
Paul Wise p...@debian.org writes: On Fri, Mar 28, 2014 at 5:28 PM, Josselin Mouette wrote: Alternatively, we could make NetworkManager the default. It is already here, it works, and it doesn’t have such problems. Or systemd-networkd. systemd-networkd is not even close to mature yet. If someone wanted to work with the systemd project to cover all of Debian's requirements for a simple network management facility, I think that would be a very worthwhile thing to do. But there's a lot of work to do. NetworkManager is closer and *could* be made to handle everything that ifupdown does now, but it's substantially more complex than ifupdown, and speaking as someone who mostly runs servers, I would definitely object. ifupdown has a lot of problems, but most of those problems are around use cases more complex than bringing up a single interface with either DHCP or a static IP address, with no wireless involved. I realize that doing that well is not horribly challenging, but that is the most common server use case (and even desktop), and ifupdown does it quite well. I don't want to lose that, and I don't want to add a bunch of complexity in order to satisfy that case. I think there will always be a place for a very *simple* system to handle that case with some pre and post hooks for things like iptables rule installation. I think part of the problem with ifupdown is that it's trying to do too much. It's trying to handle all possible network configurations, and some of them (such as dynamic wireless with WPA and multiple known wireless networks) are *way* outside of its original design and data model. So it struggles. It's also not particularly adept with the new way that networks are modeled in the kernel. That doesn't make it a bad tool, but I think it means that we should provide more guidance about what things it does well and what things it does poorly. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87eh1mrw4z@windlord.stanford.edu
Re: Ifupdown dysfunctional, is a Provides: interface possible please?
Le vendredi 28 mars 2014 à 11:55 -0700, Russ Allbery a écrit : I realize that doing that well is not horribly challenging, but that is the most common server use case (and even desktop), and ifupdown does it quite well. Come on. We all use ifupdown on our servers just because it is the default and works well enough. Bringing up a pair of static IPs and a bonding link is not very challenging. But we shouldn’t judge a network management tool based on how to achieve the simplest task: any tool will do that. Even Red Hat’s /etc/sysconfig/network-scripts, despite its horrible design and antique syntax, works well enough for most of its users. And in the desktop case, I disagree that ifupdown does the job. User applications want to be notified of the network’s status, and it requires more than what ifupdown can offer. I don't want to lose that, and I don't want to add a bunch of complexity in order to satisfy that case. I think there will always be a place for a very *simple* system to handle that case with some pre and post hooks for things like iptables rule installation. This is one of the possible scopes of systemd-networkd. But I think it is being designed more for cases like the initramfs, where you cannot have a full-blown networking management tool like NM. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1396039687.4331.41.ca...@kagura.malsain.org
Re: Ifupdown dysfunctional, is a Provides: interface possible please?
Josselin Mouette j...@debian.org writes: Le vendredi 28 mars 2014 à 11:55 -0700, Russ Allbery a écrit : I realize that doing that well is not horribly challenging, but that is the most common server use case (and even desktop), and ifupdown does it quite well. Come on. We all use ifupdown on our servers just because it is the default and works well enough. Bringing up a pair of static IPs and a bonding link is not very challenging. But we shouldn’t judge a network management tool based on how to achieve the simplest task: any tool will do that. Even Red Hat’s /etc/sysconfig/network-scripts, despite its horrible design and antique syntax, works well enough for most of its users. And in the desktop case, I disagree that ifupdown does the job. User applications want to be notified of the network’s status, and it requires more than what ifupdown can offer. That sounds like vehement agreement with what I just said. :) Having used both, ifupdown, despite its problems, is certainly better than the Red Hat approach in /etc/sysconfig. I don't want to lose that, and I don't want to add a bunch of complexity in order to satisfy that case. I think there will always be a place for a very *simple* system to handle that case with some pre and post hooks for things like iptables rule installation. This is one of the possible scopes of systemd-networkd. But I think it is being designed more for cases like the initramfs, where you cannot have a full-blown networking management tool like NM. It's quite possible that systemd-networkd will eventually become a good tool to do this. It just isn't now. Now would be a wonderful time for people who care to get involved, if they feel like that would be a good long-term solution, since it would be much easier to design a conversion path from existing ifupdown systems at this early stage in the project. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87eh1mou27@windlord.stanford.edu
Re: Ifupdown dysfunctional, is a Provides: interface possible please?
Hi! Actually, I would love to cleanly modify ifupdown with a lot of the experience I have gained from netscript, and working on actual routers. Making it not so onerous would not be that much work, and it would have far better behaviour once improvements are made. I am putting myself forward for this as with the systemd update netscript-2.4 needs to be 'bodged' in a bit to make it work. I will do this, but getting ifupdown with a better operational method and feature set will make it far easier to use for the server case as well. Cheers, Matt Grant On Fri, 2014-03-28 at 15:08 -0700, Russ Allbery wrote: Josselin Mouette j...@debian.org writes: Le vendredi 28 mars 2014 à 11:55 -0700, Russ Allbery a écrit : I realize that doing that well is not horribly challenging, but that is the most common server use case (and even desktop), and ifupdown does it quite well. Come on. We all use ifupdown on our servers just because it is the default and works well enough. Bringing up a pair of static IPs and a bonding link is not very challenging. But we shouldn’t judge a network management tool based on how to achieve the simplest task: any tool will do that. Even Red Hat’s /etc/sysconfig/network-scripts, despite its horrible design and antique syntax, works well enough for most of its users. And in the desktop case, I disagree that ifupdown does the job. User applications want to be notified of the network’s status, and it requires more than what ifupdown can offer. That sounds like vehement agreement with what I just said. :) Having used both, ifupdown, despite its problems, is certainly better than the Red Hat approach in /etc/sysconfig. I don't want to lose that, and I don't want to add a bunch of complexity in order to satisfy that case. I think there will always be a place for a very *simple* system to handle that case with some pre and post hooks for things like iptables rule installation. This is one of the possible scopes of systemd-networkd. But I think it is being designed more for cases like the initramfs, where you cannot have a full-blown networking management tool like NM. It's quite possible that systemd-networkd will eventually become a good tool to do this. It just isn't now. Now would be a wonderful time for people who care to get involved, if they feel like that would be a good long-term solution, since it would be much easier to design a conversion path from existing ifupdown systems at this early stage in the project. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1396044965.17962.5.ca...@moriah.internal.anathoth.net
Re: Ifupdown dysfunctional, is a Provides: interface possible please?
On Vi, 28 mar 14, 17:39:39, Paul Wise wrote: On Fri, Mar 28, 2014 at 5:28 PM, Josselin Mouette wrote: Alternatively, we could make NetworkManager the default. It is already here, it works, and it doesn’t have such problems. Or systemd-networkd. Or connman. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
