On Thu, Mar 19, 2009 at 10:06:37PM +0100, Andreas Henriksson wrote: > Hi Chris! > > On tor, 2009-03-19 at 14:55 -0400, Chris Dukes wrote: > > Per one of the bugs on vlan package vconfig is now considered > > deprecated. > > (Just for reference, vlan package has bug #501402 for this...) > > > Attached is a script 'ip-vlan' to be placed in /etc/network/if-pre-up.d > > and /etc/network/if-post-down.d to retain the ability to have > > rawdev.vlanid devices in /etc/interfaces as well as arbitrarily > > named vlan interfaces. > > Cool! Thank you very much! > > > > > Behavior is the same as the scripts from the vlan package with the > > addition of the vlan-vlanid and ip-vlan-args directives. > > Current behavior is to quietly exit if vconfig is found in the system > > unless overridden in /etc/default/iproute. > > If we can truely replace vconfig, I think this option should not exist. > We should simply Conflict with vlan package to make sure people remove > it. I guess we're still missing the macvlan pieces though?
The vlan bug indicated compatibility issues with sarge. I do not know if they apply to lenny as well. Plus, the vlan package requires iproute2. At this point in time the only thing I know about macvlan is what I learned from from 'ip link add link type macvlan help' and a quick skim of the comments at the start of the driver source code. And what I do know is that at this point in time 'ip' does not appear to support creating macvlan interfaces with arbitrary names, they need to be renamed after the fact. There would also need to be proper handling of 1) veth 2) dummy 3) ifb Plus tunctl functionality should probably be rolled into 'ip' as well. > > > > > It currently mimic vlan's behavior of using ip link show to check for > > the existance of the raw device. I'm not sure if /sys/class/net/<rawdev> > > checking wouldn't be better. It also currently mimics vlan's behavior > > of bringing up the raw dev. > > Re ip link show vs /sys: No strong opinion as long as you don't actually > parse the output of ip link show... Maybe we should throw away any > potential stderr messages as well though. I just copied the exact behavior from the vlan package :-). However, since you don't have a preference, I'm going to opt for /sys because I can do those checks without fork()/exec(). > > > > Should ip allow the creation of arbitrarily named macvlan devices, I > > am willing to add that functionality. > > If you can point me in the right direction I'm willing to implement > stuff in iproute. Don't know anything about macvlan... All I've done > with vlans was with vconfig a bunch of years ago. I'll go see if google > can find me some nice information about this... 'ip link add link ...' is somewhat inconsistant on arguments for the different types. veth actually appears to allow arbitrary naming, but I haven't had a chance to go through the openvz mailing lists to see how people are actually naming their interfaces in production environments. > > > On the other hand, Why don't we implement this straight in ifupdown? > The ifupdown 0.7 package in experimental has been ported over to use > iproute instead of net-tools (ifconfig). I'm willing to help out how to > update ifupdown since I've done some work on it in the past.... It would > be much nicer with "native" vlan support in ifupdown then using external > scripts IMHO, what do you think? I would have to see what ifupdown is doing underneath the covers. I pretty much have two goals. 1) Get things configured with the fewest forks possible. 2) Keep underlying algorhythms transparent so it's easier to figure out aren't working right. Then again, after looking through the inet.defn file for the current version in 'sid', it looks like it could use a good mopping :-). > > I've been lobbying to try to get some action on ifupdown to hopefully > see the 0.7 branch appear in squeeze. > > -- > Regards, > Andreas Henriksson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
