[arch-projects] [initscripts][netcfg] deprecating advanced network functionality from initscripts
Hi, Has there been a deciscion yet on the new netcfg maintainer? Most of the open initscripts bugs have to do with our network handling, and in my opinion most are outside the scope of initscripts. I would like to solve this by explicitly not supporting more than the most basic setups (if that), and suggesting people to move to netcfg, networkmanager, wicd or something else. However, I'd like to coordinate this with the netcfg maintainer(s), so we can make sure that no one is left out in the cold by any changes we make. Here are some suggestions of what we can do (by order of preference), feedback appreciated: 1) Make sure netcfg support all the usecases that initscripts does, add netcfg to base and remove all network support from initscripts; 2) Similarly, but keep support for one wired interface configured statically (each supported option listed explicitly) or via dhcp (just enough to support a rescue/install scenario); or 3) Something less extreme based on uscases that I have not thought of... Thoughts? -t
On Tue, Apr 26, 2011 at 12:40 PM, Tom Gundersen <teg@jklm.no> wrote:
Here are some suggestions of what we can do (by order of preference), feedback appreciated:
1) Make sure netcfg support all the usecases that initscripts does, add netcfg to base and remove all network support from initscripts; 2) Similarly, but keep support for one wired interface configured statically (each supported option listed explicitly) or via dhcp (just enough to support a rescue/install scenario); or 3) Something less extreme based on uscases that I have not thought of...
I'd vote for #2, keeping old timers (and me) happy. It seems like the right line to draw so that someone using a "normal" desktop computer setup, a VM, a VPS, etc. over Ethernet doesn't need to suddenly dive into netcfg. This would eliminate a lot of code still: wi_up, bond_up/down, bridge_up/down. -Dan
On Tue, Apr 26, 2011 at 12:52:30PM -0500, Dan McGee wrote:
On Tue, Apr 26, 2011 at 12:40 PM, Tom Gundersen <teg@jklm.no> wrote:
Here are some suggestions of what we can do (by order of preference), feedback appreciated:
1) Make sure netcfg support all the usecases that initscripts does, add netcfg to base and remove all network support from initscripts; 2) Similarly, but keep support for one wired interface configured statically (each supported option listed explicitly) or via dhcp (just enough to support a rescue/install scenario); or 3) Something less extreme based on uscases that I have not thought of...
I'd vote for #2, keeping old timers (and me) happy. It seems like the right line to draw so that someone using a "normal" desktop computer setup, a VM, a VPS, etc. over Ethernet doesn't need to suddenly dive into netcfg. This would eliminate a lot of code still: wi_up, bond_up/down, bridge_up/down.
-Dan
I'll vote for #2 as well. Since this involves some amount of dramatic change, can I be annoying and harp on my iproute2 patchwork as well? Seems like it would be an appropriate time to merge, since we're breaking other things as well. d
On Tue, Apr 26, 2011 at 7:55 PM, Dave Reisner <d@falconindy.com> wrote:
I'd vote for #2, keeping old timers (and me) happy. It seems like the right line to draw so that someone using a "normal" desktop computer setup, a VM, a VPS, etc. over Ethernet doesn't need to suddenly dive into netcfg. This would eliminate a lot of code still: wi_up, bond_up/down, bridge_up/down.
I'll vote for #2 as well.
Sounds like #2 it is then :-)
Since this involves some amount of dramatic change, can I be annoying and harp on my iproute2 patchwork as well? Seems like it would be an appropriate time to merge, since we're breaking other things as well.
Yes, that would be great! May I suggest that we no longer allow "open ended" configuration variables, but do something like this: interface="eth0" ip="192.168.0.10" broadcast="" netmask"" gateway="" (removing the ones that are uncommon to change, and adding anything I forgot) Only allow one interface, if ip is unset then use dhcp, and if the other variables are unset use sensible standards. Parse the variables for correctness to stop people from doing weird things. Lastly, (which is where I started), we'd have to check that any use-cases we kill is covered by something else. Any help with this would be greatly appreciated :-) Does anyone object to this plan? Cheers! -t
On Tue, Apr 26, 2011 at 1:37 PM, Tom Gundersen <teg@jklm.no> wrote:
On Tue, Apr 26, 2011 at 7:55 PM, Dave Reisner <d@falconindy.com> wrote:
I'd vote for #2, keeping old timers (and me) happy. It seems like the right line to draw so that someone using a "normal" desktop computer setup, a VM, a VPS, etc. over Ethernet doesn't need to suddenly dive into netcfg. This would eliminate a lot of code still: wi_up, bond_up/down, bridge_up/down.
I'll vote for #2 as well.
Sounds like #2 it is then :-)
Since this involves some amount of dramatic change, can I be annoying and harp on my iproute2 patchwork as well? Seems like it would be an appropriate time to merge, since we're breaking other things as well.
Yes, that would be great! May I suggest that we no longer allow "open ended" configuration variables, but do something like this:
interface="eth0" ip="192.168.0.10" broadcast="" netmask"" gateway=""
(removing the ones that are uncommon to change, and adding anything I forgot)
Only allow one interface, if ip is unset then use dhcp, and if the other variables are unset use sensible standards. Parse the variables for correctness to stop people from doing weird things.
Does anyone object to this plan?
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. If I'm of the minority opinion here I will concede. I will also be sure to assign the "my system isn't responding and I can't SSH in" bug reports to you too though. :P -Dan
On Tue, Apr 26, 2011 at 8:43 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Tue, Apr 26, 2011 at 1:37 PM, Tom Gundersen <teg@jklm.no> wrote:
On Tue, Apr 26, 2011 at 7:55 PM, Dave Reisner <d@falconindy.com> wrote:
I'd vote for #2, keeping old timers (and me) happy. It seems like the right line to draw so that someone using a "normal" desktop computer setup, a VM, a VPS, etc. over Ethernet doesn't need to suddenly dive into netcfg. This would eliminate a lot of code still: wi_up, bond_up/down, bridge_up/down.
I'll vote for #2 as well.
Sounds like #2 it is then :-) My heart beat for #1, my brain for #2. I'm romantic, so i will vote (if i have one) for #1.
Since this involves some amount of dramatic change, can I be annoying and harp on my iproute2 patchwork as well? Seems like it would be an appropriate time to merge, since we're breaking other things as well.
Yes, that would be great! May I suggest that we no longer allow "open ended" configuration variables, but do something like this:
interface="eth0" ip="192.168.0.10" broadcast="" netmask"" gateway=""
(removing the ones that are uncommon to change, and adding anything I forgot)
Only allow one interface, if ip is unset then use dhcp, and if the other variables are unset use sensible standards. Parse the variables for correctness to stop people from doing weird things.
Does anyone object to this plan? On this form, let time for people to read your mail and answer. On the substance, as dan suggest, if we break network configuration in initscripts ,as well do it completely by removing it.
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.
If I'm of the minority opinion here I will concede. I will also be sure to assign the "my system isn't responding and I can't SSH in" bug reports to you too though. :P
We have to think about default installer, which need to be adapted to generate a right configuration if we change something. And think, without a new release of it, all new setup computer, will need a two times network configuration. Maybe we should firstly deal with default installer to consider netcfg as the default way to setup network. After this remove or limit initscripts network roles? -- Sébastien Luttringer www.seblu.net
On Tue, Apr 26, 2011 at 8:59 PM, Seblu <seblu@seblu.net> wrote:
Maybe we should firstly deal with default installer to consider netcfg as the default way to setup network. After this remove or limit initscripts network roles?
Absolutely, that's a good point. We should switch the installer first before merging anything. However, we should decide on what direction to go in, so I know what bug reports to close ;-) -t
On Tue, Apr 26, 2011 at 8:43 PM, Dan McGee <dpmcgee@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...). 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? -t
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@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. d
On Tue, Apr 26, 2011 at 3:33 PM, Dave Reisner <d@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@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
On Wed, Apr 27, 2011 at 5:44 AM, Dan McGee <dpmcgee@gmail.com> wrote:
$ 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?).
Yes, this and the simple case of configuring a static ip.
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.
One year is fine by me. We could keep the legacy stuff near indefinitely, as long as it is clearly marked as unsupported. -t
On Tue, Apr 26, 2011 at 10:33 PM, Dave Reisner <d@falconindy.com> wrote:
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.
Yes, this is probably a good idea. We could have a transitional period where we add the new iproute2 code and vars, but keep the old net-tools stuff around, just with deprecation warnings. We could keep it like this as long as we feel is necessary. -t
participants (4)
-
Dan McGee
-
Dave Reisner
-
Seblu
-
Tom Gundersen