Re: Ifupdown dysfunctional, is a Provides: interface possible please?
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
> 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
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 :-)