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
