ModularEtcNetworkInterfacesSpec

Differences between revisions 1 and 2
⇤ ← Revision 1 as of 2007-10-28 16:02:19 →
Size: 3700
Editor: 12
Comment: Just throwing a bit of my ideas out there...
← Revision 2 as of 2007-11-01 00:10:12 → ⇥
Size: 4170
Editor: 12
Comment: Updated with rationale and loads of other stuff
Deletions are marked like this. Additions are marked like this.
Line 6: Line 6:
 * '''Packages affected''': ifupdown  * '''Packages affected''': ifupdown, gnome-system-tools-backends, and whatever kubuntu uses :)
Line 14: Line 14:


This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.)

It is mandatory.		 /etc/network/interfaces has been split up and put into /etc/network/interfaces.d with one file per interface. This prevents a single incorrectly configured interface from breaking the entire network configuration, and also makes handling network configuration easier for configuration systems such as eBox, and GNOME's network admin tool.
Line 22: Line 18:
System configuration software commonly has a mechanism for changing network configuration. In order to do this safely, it has to mimic a lot of the logic in ifupdown, which is error prone. This usually results in going in one of two directions: a) trying anyway and likely failing to take all of ifupdown's idiosyncracies into account or b) doing all sorts of tricks to circumvent ifupdown entirely. To fix this, we'll switch to having one file per logical interface with a slightly simpler syntax. We do this to obtain two things:
To contain accidentally wrongfully configured interfaces from affecting other interfaces.
To make life easier for anyone who wants to programmatically read or alter the network configuration on Ubuntu.
Line 26: Line 24:
1. Ante manages some servers remotely. He changes the network configuration of one of the interfaces, makes a typo and reboots the server. He cannot get in contact with the server, and cannot access the any of the other interfaces on ther server either.
1. Soren wants to edit his network configuration with a clever script, but he can't because he only knows grep and sed.
1. Soren wants to quickly extract the ip's for configuration of all the networks named eth* on his machine. He gives up trying to hack something together to parse /etc/network/interfaces.
Line 80: Line 80:
Maybe a separate file that would contain automatically configured interfaces. It could look like
{{{
lo
eth0
ath0=homewifi
}}}

or something like that.
Line 82: Line 91:
This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

=== UI Changes ===

Should cover changes required to the UI, or specific UI that is required to implement this		 ifupdown is well known and well tested, so the implementation will likely be based on that.
Line 90: Line 95:
Code changes should include an overview of what needs to change, and in some cases even the specific details. Keywords, plugins (like wireless-tools and such) and most everything else is just fine as it is, so the changes are limited to making it not bother parsing anything it will not need, so if asked to "ifup ath0=homewifi" it will only have to open /etc/network/interfaces.d/homewifi, and apply the settings found to ath0.
There will also be slight changes to the parser to take care of the new method and family configration.
Line 94: Line 100:
Include:
 * data migration, if any
 * redirects from old URLs to new ones, if any
 * how users will be pointed to the new way of doing things, if necessary.		 The current /etc/network/interfaces will be parsed and put into the new scheme. A big notice will be put in place telling the user that his config is now in the new directory structure.
Line 107: Line 110:
This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved. Changes in the tools using this file will need to be implemented, but in all fairness, this new syntax should make this much simpler.
Line 111: Line 114:
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

Summary

We want to split out /etc/network/interfaces into one file per (logical) interface.

Release Note

/etc/network/interfaces has been split up and put into /etc/network/interfaces.d with one file per interface. This prevents a single incorrectly configured interface from breaking the entire network configuration, and also makes handling network configuration easier for configuration systems such as eBox, and GNOME's network admin tool.

Rationale

We do this to obtain two things: To contain accidentally wrongfully configured interfaces from affecting other interfaces. To make life easier for anyone who wants to programmatically read or alter the network configuration on Ubuntu.

Use Cases

1. Ante manages some servers remotely. He changes the network configuration of one of the interfaces, makes a typo and reboots the server. He cannot get in contact with the server, and cannot access the any of the other interfaces on ther server either. 1. Soren wants to edit his network configuration with a clever script, but he can't because he only knows grep and sed. 1. Soren wants to quickly extract the ip's for configuration of all the networks named eth* on his machine. He gives up trying to hack something together to parse /etc/network/interfaces.

Assumptions

Design

Instead of a stanza /etc/network/interfaces such as: 

iface eth0 inet dhcp

...we'll have a file called /etc/network/interfaces.d/eth0 

family inet
method dhcp

auto eth4

iface eth4 inet static
    address 192.168.1.77
    netmask 255.255.255.0
    broadcast 192.168.1.255
    network 192.168.1.0
    gateway 192.168.1.1

becomes /etc/network/interfaces.d/eth4: 

family inet
method static
address 192.168.1.77
netmask 255.255.255.0
broadcast 192.168.1.255
network 192.168.1.0
gateway 192.168.1.1
auto

auto ath0=homewifi

iface homewifi inet dhcp
    wireless-key s:VerySecret123
    wireless-essid FooBarNet

probably becomes two files. First /etc/network/interfaces.d/homewifi: 

family inet
method dhcp
wireless-key s:VerySecret123
wireless-essid FooBarNet

the rest, I'm not sure about right now.

Maybe a separate file that would contain automatically configured interfaces. It could look like 

lo
eth0
ath0=homewifi

or something like that.

Implementation

ifupdown is well known and well tested, so the implementation will likely be based on that.

Code Changes

Keywords, plugins (like wireless-tools and such) and most everything else is just fine as it is, so the changes are limited to making it not bother parsing anything it will not need, so if asked to "ifup ath0=homewifi" it will only have to open /etc/network/interfaces.d/homewifi, and apply the settings found to ath0. There will also be slight changes to the parser to take care of the new method and family configration.

Migration

The current /etc/network/interfaces will be parsed and put into the new scheme. A big notice will be put in place telling the user that his config is now in the new directory structure.

Test/Demo Plan

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during CD testing, and to show off after release.

This need not be added or completed until the specification is nearing beta.

Outstanding Issues

Changes in the tools using this file will need to be implemented, but in all fairness, this new syntax should make this much simpler.

BoF agenda and discussion

CategorySpec

ModularEtcNetworkInterfacesSpec (last edited 2008-08-06 16:30:50 by localhost)