Denis Ovsienko Russia, Moscow Linux system administrator and developer ValueCommerce/Russia
I develop /etc/net project (http://etcnet.org) and my goal is to integrate it into Fedora Core.
I am a member of ALTLinux Team. /etc/net is already integrated into ALTLinux development tree and should soon be seen in 3.0 version. I know that ArchLinux has /etc/net in its repository. IDMS Linux did so too, but i haven't heard from them for last months. My skills include 6 years Linux experience, several programming languages, 5 years of mixed software development and system/network administration and so on, but I guess it's not related much to my goal now. I have reviewed current initscripts buglist.
Some bugs are not bugs in /etc/net: #65114 RFE: ifup-aliases iproute support, ifup/ifup-aliases scop... #75390 it would be nice to tie bandwidth shaping into the networ... #129820 initscripts maclist patch #132252 Request for addition of routing rule config file #132912 No additional IP addresses at ethX without aliased devices #132925 initscripts use old ifconfig instead of iproute2 #154348 Adds support for WPA (Wi-Fi Protected Access) to the ifup... #168990 No ifup-gre/ifdown-gre scripts. #170884 MTU of ethernet card can't be set before interface is up #171763 Enhancement to initscripts
Some bugs gave me ideas how to improve /etc/net: #59114 .d-style scripts for ifup/ifdown #119952 RFE: Add hook for "local" network initialization #124045 Support setting a metric on interface routes
The whole process, if we don't face some unexpected problems, should take 3 to 6 months. What I need: 1. Ability to advocate patches (sometimes heavy) to about 10-20 FC packages. 2. Probably some help with documentation. How can we start?
pub 1024D/6D1844F2 2002-11-11 Key fingerprint = AF2F DDAE 7EB3 4699 09FF F0FC 00B1 6D41 6D18 44F2 uid Denis Ovsienko linux@pilot.org.ua uid Denis Ovsienko (http://pilot.org.ua) pilot@altlinux.ru sub 2048g/57B7ACBE 2002-11-11
On 11/3/05, Denis Ovsienko linux@pilot.org.ua wrote:
How can we start?
Basically, you are advocating a rewrite of /etc/sysconfig/networking and /etc/sysconfig/network-scripts. You may start with a detailed explanation as to why the setup, that Redhat has provided, is not up to task.
-- -jeff
On Thu, 2005-11-03 at 20:16 +0000, Jeff Pitman wrote:
On 11/3/05, Denis Ovsienko linux@pilot.org.ua wrote: How can we start?
Basically, you are advocating a rewrite of /etc/sysconfig/networking and /etc/sysconfig/network-scripts. You may start with a detailed explanation as to why the setup, that Redhat has provided, is not up to task.
While you're at it, some thoughts on why this sort of change is worthwhile in a NetworkManager world would be good, too.
(And don't say "because NM doesn't handle the server case", etc, because obviously it'll eventually have to handle many of those cases, so we don't wind up with two conflicting systems for network setup on one machine. We should all try to skip over the rather rhetorical "NM doesn't have $FOO feature yet" lines of thought ;)
Basically, you are advocating a rewrite of /etc/sysconfig/networking and /etc/sysconfig/network-scripts. You may start with a detailed explanation as to why the setup, that Redhat has provided, is not up to task.
I advocate an alternative, that can be installed and switched into. I know that people are used to initscripts and don't want to throw it away. But some people (not only me) are not satisfied with initscripts-way, see bugzilla.redhat.com for details. I look at that bugs from time to time and some are seen for several years yet. Being net-scripts maintainer in ALTLinux, I can't blame Bill Nottingham for that, some things are unfixable with current design.
A working solution, that was done is ALTLinux, is to: 1. Split initscripts so that network-related part goes to net-scripts package. net-scripts will provide network-config-subsystem. 2. Find all dependencies on initscripts, change some to network-config-subsystem. Patch packages that depend on network-config-subsystem. 3. Pack /etc/net, which will provide network-config-subsystem. Now we have 2 conflicting packages, only one of which will be installed at once. The whole system should work independently of which one is installed, so it's up to user which one to use.
Those who edit ifcfg-eth0 once a year will not want to learn a new way to do it. But those who need more than current initscripts (Ok, network part of initscripts) can provide, are left with rc.local and an editor. Here is a list of what currently /etc/net can do but initscripts can't: - QoS - inter-interface dependencies - configuration profiles - multi-host configuration - routing rules - ifrename support - ifplugd support [...] - EXTENSIBLE DESIGN
I (and other people) find solutions of everyday tasks with /etc/net. I don't want to make others think the way I do, but I need a way to give people choice freedom within FC. This freedom is demanded.
On Mon, 2005-11-07 at 18:02 +0200, Denis Ovsienko wrote:
Basically, you are advocating a rewrite of /etc/sysconfig/networking and /etc/sysconfig/network-scripts. You may start with a detailed explanation as to why the setup, that Redhat has provided, is not up to task.
I advocate an alternative, that can be installed and switched into. I know that people are used to initscripts and don't want to throw it away. But some people (not only me) are not satisfied with initscripts-way, see bugzilla.redhat.com for details. I look at that bugs from time to time and some are seen for several years yet. Being net-scripts maintainer in ALTLinux, I can't blame Bill Nottingham for that, some things are unfixable with current design.
A working solution, that was done is ALTLinux, is to:
- Split initscripts so that network-related part goes to net-scripts package.
net-scripts will provide network-config-subsystem. 2. Find all dependencies on initscripts, change some to network-config-subsystem. Patch packages that depend on network-config-subsystem. 3. Pack /etc/net, which will provide network-config-subsystem. Now we have 2 conflicting packages, only one of which will be installed at once. The whole system should work independently of which one is installed, so it's up to user which one to use.
Those who edit ifcfg-eth0 once a year will not want to learn a new way to do it. But those who need more than current initscripts (Ok, network part of initscripts) can provide, are left with rc.local and an editor. Here is a list of what currently /etc/net can do but initscripts can't:
- QoS
- inter-interface dependencies
- configuration profiles
- multi-host configuration
- routing rules
- ifrename support
- ifplugd support
[...]
- EXTENSIBLE DESIGN
I (and other people) find solutions of everyday tasks with /etc/net. I don't want to make others think the way I do, but I need a way to give people choice freedom within FC. This freedom is demanded.
-- DO4-UANIC
Are you going to add support for all this in to system-config-network as well? :-)
Jon
Denis Ovsienko (linux@pilot.org.ua) said:
Those who edit ifcfg-eth0 once a year will not want to learn a new way to do it. But those who need more than current initscripts (Ok, network part of initscripts) can provide, are left with rc.local and an editor. Here is a list of what currently /etc/net can do but initscripts can't:
- QoS
- inter-interface dependencies
- configuration profiles
- multi-host configuration
- routing rules
- ifrename support
- ifplugd support
[...]
- EXTENSIBLE DESIGN
I (and other people) find solutions of everyday tasks with /etc/net. I don't want to make others think the way I do, but I need a way to give people choice freedom within FC. This freedom is demanded.
Generally... network-scripts will eventually go away - things will be moved to a framework involving NetworkManager. Hence, I don't believe pulling in an entirely different framework in the interim is really worth it.
Bill
Generally... network-scripts will eventually go away - things will be moved to a framework involving NetworkManager. Hence, I don't believe pulling in an entirely different framework in the interim is really worth it.
It is worth. The problem is that other distributions borrow(ed) from FC(RH) and most often borrowed thing is initscripts. Sometimes it's the only thing they do to allow configure networking. If there is no straight way to switch from net-scripts, people will continue to use it. I want modern Linux systems to make use of modern network features independently of distribution they were installed from.
Denis Ovsienko wrote:
Generally... network-scripts will eventually go away - things will be moved to a framework involving NetworkManager. Hence, I don't believe pulling in an entirely different framework in the interim is really worth it.
It is worth. The problem is that other distributions borrow(ed) from FC(RH) and most often borrowed thing is initscripts. Sometimes it's the only thing they do to allow configure networking. If there is no straight way to switch from net-scripts, people will continue to use it. I want modern Linux systems to make use of modern network features independently of distribution they were installed from.
Sure. NetworkManager is not specific to Fedora. It is already being used by several distributions. So instead of switching to net-scripts they can switch over to NeworkManager when it becomes capable of replacing everything else.
regards Rahul
Sure. NetworkManager is not specific to Fedora. It is already being used by several distributions. So instead of switching to net-scripts they can switch over to NeworkManager when it becomes capable of replacing everything else.
I have nothing against NetworkManager and those who want to use or develop it, but my vision of how things should happen is different. I don't request anyting except ability to use community member's right to participate in Fedora Core development.
"The Fedora Project is an open source project sponsored by Red Hat and supported by the Fedora community. It is also a proving ground for new technology that may eventually make its way into Red Hat products. It is not a supported product of Red Hat, Inc." (c) http://fedora.redhat.com/
"The Fedora Project is a Red Hat sponsored and community-supported open source project. It is not a supported product of Red Hat, Inc. The goal? Work with the Linux community to build a complete, general purpose operating system exclusively from free software. Public forum. Open processes. A proving ground for new technology that may eventually make its way into Red Hat products." (c) http://www.redhat.com/en_us/USA/fedora/
I want to add extra functionality to FC, which has been demanded for years. Why do you try to stop me? I want to start.
On Tue, 2005-11-08 at 10:26 +0200, Denis Ovsienko wrote:
Sure. NetworkManager is not specific to Fedora. It is already being used by several distributions. So instead of switching to net-scripts they can switch over to NeworkManager when it becomes capable of replacing everything else.
I have nothing against NetworkManager and those who want to use or develop it, but my vision of how things should happen is different. I don't request anyting except ability to use community member's right to participate in Fedora Core development.
I want to add extra functionality to FC, which has been demanded for years. Why do you try to stop me? I want to start.
Hi Denis,
I could be wrong, but I don't think anyone is trying to stop you. There is, however, a procedure to be followed to get things in. Currently, the way to get your packages "into" Fedora is through Extras which has a well-defined package submittal and maintenance process documented at:
http://fedoraproject.org/wiki/Extras
So, is there some way that you could package your networking scripts as an "add on" that would work alongside the existing scripts? If so, it would be relatively easy to get them into Fedora Extras where they could be tested (including comparisons with the existing scripts!), used by folks so that people become familiar with them, and perhaps eventually added to Core.
Does that sound reasonable?
Ed
I could be wrong, but I don't think anyone is trying to stop you. There is, however, a procedure to be followed to get things in. Currently, the way to get your packages "into" Fedora is through Extras which has a well-defined package submittal and maintenance process documented at:
Thank you for the hint, I will follow the procedure.
So, is there some way that you could package your networking scripts as an "add on" that would work alongside the existing scripts? If so, it would be relatively easy to get them into Fedora Extras where they could be tested (including comparisons with the existing scripts!), used by folks so that people become familiar with them, and perhaps eventually added to Core.
/etc/net can't do it's job without integration into system init, but I hope we will return to it when I am finifhed with Extras.
On Tue, 2005-11-08 at 10:26 +0200, Denis Ovsienko wrote:
Sure. NetworkManager is not specific to Fedora. It is already being used by several distributions. So instead of switching to net-scripts they can switch over to NeworkManager when it becomes capable of replacing everything else.
I have nothing against NetworkManager and those who want to use or develop it, but my vision of how things should happen is different. I don't request anyting except ability to use community member's right to participate in Fedora Core development.
So package your stuff for Fedora Extras. That'd be the first step, whether the rest of us agree that it should (later) go in Core or not.
Bill Nottingham (notting@redhat.com) said:
- QoS
- inter-interface dependencies
- configuration profiles
- multi-host configuration
- routing rules
- ifrename support
- ifplugd support
[...]
- EXTENSIBLE DESIGN
I (and other people) find solutions of everyday tasks with /etc/net. I don't want to make others think the way I do, but I need a way to give people choice freedom within FC. This freedom is demanded.
Generally... network-scripts will eventually go away - things will be moved to a framework involving NetworkManager. Hence, I don't believe pulling in an entirely different framework in the interim is really worth it.
Moreover, some of the things you mention above are either:
a) supported in the scripts already (ifrename) b) supported via NetworkManager (ifplugd, configuration profiles) c) not really as important in a long term view (ifrename, again :) )
Bill
Resurected from the past.
On Mon, Nov 07, 2005 at 14:48:55 -0500, Bill Nottingham notting@redhat.com wrote:
Denis Ovsienko (linux@pilot.org.ua) said:
Those who edit ifcfg-eth0 once a year will not want to learn a new way to do it. But those who need more than current initscripts (Ok, network part of initscripts) can provide, are left with rc.local and an editor. Here is a list of what currently /etc/net can do but initscripts can't:
- QoS
- inter-interface dependencies
- configuration profiles
- multi-host configuration
- routing rules
- ifrename support
- ifplugd support
[...]
- EXTENSIBLE DESIGN
I (and other people) find solutions of everyday tasks with /etc/net. I don't want to make others think the way I do, but I need a way to give people choice freedom within FC. This freedom is demanded.
Generally... network-scripts will eventually go away - things will be moved to a framework involving NetworkManager. Hence, I don't believe pulling in an entirely different framework in the interim is really worth it.
Bill
NetworkManager doesn't seem to be evolving toward providing full use of the network tools (e.g. multiple networks on an interface, bridging, routing, QoS). It seems to be very oriented toward convenient use in simple cases.
If it is not going to ever give access to the more advanced networking features, I think there is a reason to replace the current network configuration scripts with something like etcnet.
Sure you can add commands in rc.local to set up the network properly, but then ifup and ifdown don't work correctly (in the general case) and neither does changing between run levels where the network gets turned off or on.
etcnet does seem to be continuing to be developed, but it looks like they aren't continuing to provide Fedora specific installations.
On 23/10/2007, Bruno Wolff III bruno@wolff.to wrote:
NetworkManager doesn't seem to be evolving toward providing full use of the network tools (e.g. multiple networks on an interface, bridging, routing, QoS). It seems to be very oriented toward convenient use in simple cases.
If it is not going to ever give access to the more advanced networking features, I think there is a reason to replace the current network configuration scripts with something like etcnet.
Sure you can add commands in rc.local to set up the network properly, but then ifup and ifdown don't work correctly (in the general case) and neither does changing between run levels where the network gets turned off or on.
etcnet does seem to be continuing to be developed, but it looks like they aren't continuing to provide Fedora specific installations.
As mentioned in the thread back in 2005, the first step would be submitting etcnet to for inclusion as a Fedora package. That can happen independently of whether or not discussions of replacing network-scripts happens, and what the outcome of them are.
FWIW, I'd quite like to see etcnet in the repo as an alternative, so if you want some help packaging it, drop me a line. That said, the thing that is very unappealing to me about its design is the multitude of configuration files distributed over several subdirectories. That's subjective though.
Jonathan.
On Wed, Oct 24, 2007 at 01:45:26PM +0100, Jonathan Underwood wrote:
As mentioned in the thread back in 2005, the first step would be submitting etcnet to for inclusion as a Fedora package. That can
Right. There has been a submission https://bugzilla.redhat.com/show_bug.cgi?id=195365 It has been closed, but I think it is worth pursuing.
happen independently of whether or not discussions of replacing network-scripts happens, and what the outcome of them are.
FWIW, I'd quite like to see etcnet in the repo as an alternative, so if you want some help packaging it, drop me a line. That said, the
I'd happily review it.
-- Pat
On Wed, Oct 24, 2007 at 13:45:26 +0100, Jonathan Underwood jonathan.underwood@gmail.com wrote:
As mentioned in the thread back in 2005, the first step would be submitting etcnet to for inclusion as a Fedora package. That can happen independently of whether or not discussions of replacing network-scripts happens, and what the outcome of them are.
FWIW, I'd quite like to see etcnet in the repo as an alternative, so if you want some help packaging it, drop me a line. That said, the thing that is very unappealing to me about its design is the multitude of configuration files distributed over several subdirectories. That's subjective though.
I think there are plusses and minuses to that. For scripting stuff, that can be a plus. When editing by hand its a pain to have to go so many places.
When I switch to Fedora 8, I can look at trying to allow use of etcnet by turning off the network service and turning on an etcnet service. This would allow it to be installed without breaking other stuff. Once you started actually using it instead of the standard network service that would break the system-config-network tool, since it would be changing files that aren't being used anymore. If I have success with that, I may submit it as a package after running it for a while.
-
Bill Nottingham -
Bruno Wolff III -
Denis Ovsienko -
Ed Hill -
Jeff Pitman -
Jon Nettleton -
Jonathan Underwood -
Patrice Dumas -
Peter Jones -
Rahul Sundaram