[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Ifupdown dysfunctional, is a Provides: interface possible please?


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.


web: -root- [~] 
# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN mode
    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

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?


Matt Grant

Reply to: