[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ifupdown-bonding package

On Tue, Oct 18, 2005, Jerome Martin wrote:
> Well, I am a bit surprised by the way you see it. Could you be more 
> specific ?

 Of course: what I meant is that the issues you might have encountered
 require fixing, and not documentation.  I can't tell how much of what
 you describe is currently supported by the current ifenslave and vlan
 packages, but it's where things should be implemented or fixed.

 I know that I'm currently using things such as:

auto bond0
iface bond0 inet manual
    up insmod bonding -o bond0 mode=0 miimon=100
    up ifconfig bond0 hw ether 00:04:23:B1:C7:24
    up ifconfig $IFACE up
    down ifconfig $IFACE down
    down rmmod bond0

 or even:

auto bond1
iface bond1 inet manual
    pre-up ifconfig eth1 up
    pre-up ifconfig eth3 up
    up insmod bonding -o $IFACE mode=0 miimon=100
    up ifconfig $IFACE hw ether 00:04:23:B1:C7:25
    up ifconfig $IFACE up
    up ifenslave -X $IFACE eth1 eth3
    up ifconfig $IFACE
    up ifconfig eth1
    up ifconfig eth3
    up echo success
    down ifconfig $IFACE
    down ifenslave -d $IFACE eth1 eth3
    down ifconfig $IFACE down
    down rmmod $IFACE
    post-down ifconfig eth3 down
    post-down ifconfig eth1 down

 on a server running sarge, but it seems that the current ifenslave-2.6
 packages already offer to switch to:

iface bond0 inet static
        slaves eth0 eth1

 since this change:

ifenslave-2.6 (1.1.0-5) unstable; urgency=low

  * Add if-pre-up and if-post-down scripts to enslave and detach interfaces.
    Closes: #306993.

 -- Guus Sliepen <guus@debian.org>  Fri, 30 Sep 2005 14:33:46 +0200

> - provide a way to describe bonding interfaces in network/interfaces 
> without the burden of repeating the same ifup/ifdown definitions.

 That's nice, it offers a bit more control than the current scripts, but
 it's as short as it can already be.

> - provide a way to simplify the process by setting defaults enabling 
> fast testing/setting up. Of course I realise that these defaults cannot 
> be universal, that is the reason why I suggested the possibility to 
> override them in network/options. You tell that this file is deprecated, 
> so I should find some other way to do it, but the spirit remains the 
> same : centralise some defaults, render the interface definition less 
> verbose, lighter.

 I suggest using /etc/default/<your-package>.

> - allow one to configure easily the bonding module from inside the 
> interface definition

 That's good, and is not covered by the current ifenslave-2.6 scripts.
 I suggest you file a request against ifenslave-2.6 with your proposalto
 address this.

> I feel that those 3 goals are fixes to problems I have encountered myself.
> As for my future goals (to be implemented, but I'm working on it and 
> have something soon) :
> - Add logic to check VLANs are up only AFTER the main bond interface is 
> up and attached to at least one slave (in order to ensure no mac address 
> issues will occur)
> - Add logic to check that slave interfaces do not have IPs configured 
> nor routes (in order to prevent conflicts) befor the bond is started
> - Add logic to check there is no IP attached to an underlying bond 
> interface before bringing up VLANs.

 That's useful indeed.  That would be another round of fixes for the
 bonding if-up scripts.

> - Add logic to configure arp monitoring using the default gw / 
> resolvconf hooks / whaterver makes sense (suggestions welcome)

 I don't see what you mean, but it certainly makes sense to add such a
 support in the ifupdown package so that all interface types can benefit
 from the change.

> - Add logic to detect which modules are used by the slave interfaces and 
> eventually unload themfirst and reload them after the bonding module (so 
> that SNMP if queries will report the bond as the "owner" of its IP 
> address). I realise that this impacts heavily the logic dictated by 
> configuring modules in modprobe.conf / modprobe.d, maybe there is 
> something that could be done with an external tool handling this (and 
> storing configuration via debconf ?) ? What would be the "debian way" ?

 I don't understand the above, but I'm sure you'll find your way in
 Debian.  :)

> All that to say that my goal is to provide code to solve issues, not 
> only document them. However, at some point, I hacked down the README as 
> much as a reminder of items to investigate than documentation for people 
> willing to use the embryo of features already coded.

 Ok, so it's more of a TODO.  :)

> However, I'm a lost, because in order to acheive all those "automatic 
> handling of all VLANs+bonding issues" it seems that a lot more changes 
> would be required to the network modules handling + ifupdown 
> architecture than just a few hooks.

 I don't see why, the current approach of if-up scripts seems ok to me.

> While I am at it, my scripts currently require bash (shopts extglod and 
> such) to work. Is that something acceptable in network scripts ?

 Sure, but you need to use #!/bin/bash in the shebang.

> >That file is deprecated in recent netbase packages.
> Where can I find documentation about the reason why, the new policy, and 
> the direction behind it ?

 I don't know, I suppose you can mail the maintainer.  Probably, the
 configured options had nothing to do in there and /etc/sysctl.conf
 could be used instead.

> I agree. But what about a more complete bonding+vlan handling (see 
> above) ? Would that still belong to individual packages providing the 
> underlying feature (ifenslave) ? Or should scattering it should be 
> avoided in order to maintain a coherent whole, more easily maintainable ?

 Well, I don't see anything specific about doing vlan over bonding.
 It's normal vlan usage, normal bonding usage.

> >My feeling is that the current ifenslave packages "feel" like Debian
> >already, but do not offer advanced options, and the vlan packages
> >doesn't feel like Debian and tried encoding information in the
> >interface name instead of defining it's keywords as other packages do.
> Well, I have always felt that the debian way was not to change the 
> semantics of the upstream software. And automagic interface naming IS 
> part of the vconfig semantics, see the set_name_type options. However, 
> in this particular case, I share part of the same feeling : I would 
> prefer  not have the  name of the interface carry any semantic at all. 
> This can be misleading. The reason I mimicked this behavior was mostly 
> to satisfy my crave for consistency, added to the fact that the vlan 
> package being already into debian, I took for granted that this is the 
> right way to do it :-)

 One way to keep the autogeneration of interface names is to use
 something in the lines of:

 iface eth0 inet manual
     vlans 16 32 48
     vlan_name_type vlan_plus_vid_no_pad

 iface eth0.16 inet static
     address x.x.x.x

 The current way of detecting that eth0.16 means setup eth0 for VLANs
 and add it to VLAN 16 is ugly IMO.

> But on the topic of adding "advanced options", I tend to strongly 
> disagree with you, but this requires some explanations :
> - I like uncluttered configuration files [...]
> - However, in a production environment, what I need is : [...]
> - On the topic of network configuration [...]
>  . a centralized place to handle all interfaces configuration
>  . a centralized place to handle default options ( was network/options, 
> I don't know anymore)
>  . checks for coherency of the configuration ( very similar to 
> "robustness" of code when programming, mostly error checking and handling)
>  . a predictable behavior (ordering module load falls into that category)
>  . if a centralized placed cannot be offered [...]
> What do you think ?

 I think as you do, you made some perfectly valid remarks that I can
 only ack.

> Can anyone share pointers with me as of what is the "debian way" ? Or at 
> least what are the conflicting views on those matters ?

 When I said the "Debian way" on the topic of networking I was mostly
 referring to the ifupdown hooks.

> [...]

 In general, I agree with what you said.  Since all you offered to
 comment on were ideas and documentation, I commented on that, and I
 must say I'm now a bit confused on the actual things you're trying to
 fix or change.  My feeling is that you want some broad changes to
 happen, and Debian allows mainly small fixes on a per-package basis.
   I suggest you take a look at the ifenslave-2.6 package in unstable,
 and see how its current if-up hooks can be enhanced, and also file a
 request to include your vlan handling scripts against the vlan package.

   Thanks for improving Debian,
Loïc Minier <lool@dooz.org>

Reply to: