Comment 5 for bug 303159

Revision history for this message
Alexander Sack (asac) wrote : Re: [Bug 303159] Re: IFUPDOWN - connections that are mapped should be locked to the mapping device

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