IFUPDOWN - connections that are mapped should be locked to the mapping device

On Sat, Nov 29, 2008 at 08:45:13PM -0000, Stephan Trebels wrote:
> ** Description changed:
>
> Binary package hint: network-manager
>
> When running in managed=true mode, ifupdown will export configurations
> of a mapping entry in /etc/network/interfaces without locking it to the
> mapping device origin.
> +
> + If a device exists with a mapping stanza then the mapping script may
> + select any of iface stanza "devices". The script is pretty much in
> + control of the naming of the device, so a $DEV-.* regex is wrong to
> + assume. A priori not even the link to a physical device is possible
> + without running the script, as the same mapping may be applicable to
> + multiple devices.
> +
> + Probably the right thing to do is to hide all iface/mapping
> + "connections" that do not correspond to HAL-known devices. Then treat a
> + mapping like a DHCP connection, where a script is called on activation
> + (as in ifupdown) to select the iface stanza "connection" for
> + configuration.
>

IMO, the first step should just do the locking to the device through
the Mac Adress. Next step then looks at how to implement detect
commands to dynamically detect the mapping.

But for the command thing we should open a new bug.

 - Alexander

I dont think I understand what you are trying to do.

We could determine the MAC from HAL, right. The issue is, that we cannot do anything from there, I really wonder how this ever worked for me even with the eth0-XXX naming convention, how did it know which interface to operate on? Consider the following example interfaces file from /usr/share/doc/ifupdown/examples/network-interfaces.gz

auto eth0 eth1

mapping eth0 eth1
    script /path/to/get-mac-address.sh
    map 11:22:33:44:55:66 lan
    map AA:BB:CC:DD:EE:FF internet

iface lan inet static
    address 192.168.42.1
    netmask 255.255.255.0
    pre-up /usr/local/sbin/enable-masq $IFACE

iface internet inet dhcp
    pre-up /usr/local/sbin/firewall $IFACE

both auto and mapping apply to multiple values which the parser does not support as of today,
at least I think so.

Additionally we don't know the mac address of each interface before HAL registers
the device. For the iface stanzas we have no clue, which physical interface they will be applied to.
 I suspect this example is to work around issues of ethernet device naming without iftab & friends.

So, a priori we can treat a mapping as a device name (which it is) which can then be used just like a
VPN connection, i.e. it can be switched on and off, or we could allow via nm-applet to "link" one of
the unused stanzas to the mapping device, cool but a lot of change.

On Thu, Dec 04, 2008 at 04:01:57PM -0000, Stephan Trebels wrote:
> I dont think I understand what you are trying to do.
>
> We could determine the MAC from HAL, right. The issue is, that we cannot
> do anything from there, I really wonder how this ever worked for me even
> with the eth0-XXX naming convention, how did it know which interface to
> operate on? Consider the following example interfaces file from
> /usr/share/doc/ifupdown/examples/network-interfaces.gz
>
> auto eth0 eth1
>
> mapping eth0 eth1
> script /path/to/get-mac-address.sh
> map 11:22:33:44:55:66 lan
> map AA:BB:CC:DD:EE:FF internet
>
> iface lan inet static
> address 192.168.42.1
> netmask 255.255.255.0
> pre-up /usr/local/sbin/enable-masq $IFACE
>
> iface internet inet dhcp
> pre-up /usr/local/sbin/firewall $IFACE
>
> both auto and mapping apply to multiple values which the parser does not support as of today,
> at least I think so.
>
> Additionally we don't know the mac address of each interface before HAL registers
> the device. For the iface stanzas we have no clue, which physical
> interface they will be applied to.

How about this:

1. create configurations for all iface stanzas as we do now
2. for each virtual configuration that is configured, we create one
   connection for each interface they might be theoretically be mapped
   to (e.g. for mapping eth0 eth1, we would duplicate the lan
   configuration); e.g. in your example the lan and internet
   connection would be duplicated, so we have one of each that can
   later be locked to eth0 and one that can later be locked to eth1.
2. virtual configurations that have a mapping are not exported through
   getconnections by default, unless they have been locked to a device.
3. everytime we see a hal device change event we go and run all
   mapping scripts; based on the result we lock the config to the
   device and apply the autoconnect flag as its configured for the
   named mapping device(s); also we lock the configuration to the
   mapped device.
4. when a mapping changes, we ensure that connections that are not
   mapped anymore, become unlocked, autoconnect becomes unflagged and
   they are not exported through the getconnections function

Is that simple enough? I am sure I forgot a bunch of
use-cases. anythint you can think of right now?

 - Alexander

The ifupdown interpretation of the mapping is:
a. If auto stanza exists run ifup $DEVICE at startup
b. When ifup $DEVICE is run for a mapping, run the mapping script, and
apply the config.

My personal preference for the ideal user-side experience for a mapping
device would be:
a. when device is not available hide all $MAPPING::$DEVICE virtual
configuration
b. when a device becomes available, and an auto stanza exists, run the
equivalent of ifup $DEVICE
c. when a device becomes available, and no auto stanza exists, offer the
user a choice, i.e. don't activate the device, activate one of the
$MAPPING::$DEVICE virtual connections, and a $MAPPING::automatic option
that runs the script.
d. if a device is available, but the user did not activate it at the
time it became available, then offer all $MAPPING::$DEVICE combinations

Feedback:
For this 1. and 2a. are fine.
I am not sure 2b. is correct if a mapping device is not locked, yet, but
available via hal. I'd prefer to export virtual configuration always
when a device is available via hal (if a list of configurations can be
made mutually exclusive). This is important, if only to allow the user
to override the script decision.
About 3. we should only run the single mapping script that this
hal-device-available event was for, not all of them, and only if the
auto stanza exists (see above).
for 4. you mean a reload of the interfaces file?

This is milestoned, thus assigning to Alex. Alex, please fix, reassign to someone else, or unmilestone (since this is a wishlist bug, this would be appropriate). Thanks!

I can't commit to spending time on this with my limited understanding of the actual problem and whether it's still an issue in NetworkManager now. Could someone running into this kind of issue on a similar setup report back here and confirm whether the latest changes to the ifupdown code in NetworkManager in version 0.9 have resolved this?

Thanks!

[Expired for network-manager (Ubuntu) because there has been no activity for 60 days.]