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:
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
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 127.0.0.2 up
up ifenslave -X $IFACE eth1 eth3
up ifconfig $IFACE 0.0.0.0
up ifconfig eth1 0.0.0.0
up ifconfig eth3 0.0.0.0
up echo success
down ifconfig $IFACE 127.0.0.2
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.
-- Guus Sliepen <firstname.lastname@example.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
> 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
> 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
iface eth0.16 inet static
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
> 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 <email@example.com>