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 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
address 192.168.48.157
netmask 255.255.252.0
broadcast 192.168.48.255
gateway 192.168.48.1
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: