[arch-projects] [initscripts][netcfg] deprecating advanced network functionality from initscripts

[Dan McGee]

On Tue, Apr 26, 2011 at 3:33 PM, Dave Reisner <d at falconindy.com> wrote:
> On Tue, Apr 26, 2011 at 10:17:26PM +0200, Tom Gundersen wrote:
>> On Tue, Apr 26, 2011 at 8:43 PM, Dan McGee <dpmcgee at gmail.com> wrote:
>> > I do- making a system unbootable without a config change is never a
>> > good idea. My hope with selection number 2 was that no one using a
>> > "normal" config would have to change anything, e.g. those using
>> > headless systems would not have to tweak any dials.
>>
>> This is a good point (which I should have elaborated on). The problem
>> is that there is currently no limit to what weird things people might
>> use the network script to do, so it is very hard to keep 100%
>> backwards compatibility (unless we opt for not changing anything at
>> all).
>>
>> What I had in mind was to map the old configuration to the new one in
>> such a way that those who had a vanilla setup before would not notice
>> anything. However, those who set up weird stuff would have to change
>> their config.
>>
>> Note that we cannot keep 100% backwards compatibility if we want to
>> move to iproute2  (which I really think we should as net-tools has
>> been dead for more than 10 years), so something would have to break
>> (Dave, correct me if I'm wrong here...).
>
> net-tools uses the kernel's ioctl syscall interface to get/set values in
> the kernel's routing tables. This entire interface has been deprecated,
> but I've seen no indication of it going away yet. I suspect that perhaps
> one day, it will.
>
> iproute2 uses netlink sockets to communicate with the kernel, which is a
> far more extensible and flexible interface. It's already fairly old,
> being introduced in the 2.2 series. iproute2 also has the advantage of
> being maintained by the same people in charge of the network stack in
> the kernel. If something were to change, we'd surely see appropriate
> changes in iproute2 as well.
>
>> So the question is: is it worth trying to keep some network
>> functionality in initscripts, taking into account that we cannot be
>> 100% backwards compatible? Alternatively, is backwards compatibility
>> so important that we should not change it at all?
>>
>
> Maybe there's some way to have an ugly pubescent transition where we
> fall back on the old config if variables are missing and complain loudly
> to the user, citing deprecation. Large warnings in the bridge and
> bonding functionality would be appropriate too.

I imagine the majority of setups look like this for people:

$ grep eth /etc/rc.conf
# DHCP:     Set your interface to "dhcp" (eth0="dhcp")
eth1="dhcp"
INTERFACES=(eth1)

At the very least, you need to make this a no-hassle out of the box
netcfg configuration setup (perhaps there can be some sort of netcfg
use rc.conf mode?). With that said, coming from someone working on a
system-critical piece of software: anything you want to remove or make
inoperable needs at least a year of warning and prep time. I know that
sounds absurd with an "always changing" Arch, but note how an rc.conf
from near 0.1 days would probably still work today.

-Dan