[arch-projects] [netctl] Still some weird behaviour with bridges

Dave Reisner d at falconindy.com
Mon May 6 14:03:34 EDT 2013


On Mon, May 06, 2013 at 07:49:48PM +0200, Jouke Witteveen wrote:
> On Mon, May 6, 2013 at 7:36 PM, Dave Reisner <d at falconindy.com> wrote:
> > On Mon, May 06, 2013 at 07:23:58PM +0200, Jouke Witteveen wrote:
> >> On Mon, May 6, 2013 at 10:22 AM, Thomas Bächler <thomas at archlinux.org> wrote:
> >> > I have this profile:
> >> >
> >> > Interface=vmnet
> >> > Connection=bridge
> >> > BindsToInterfaces=()
> >> > IP=static
> >> > SkipNoCarrier=yes
> >> > Address=('1.2.3.4/5')
> >> >
> >> > While it seems to work fine, systemd prints these messages:
> >> >
> >> > Starting network profile 'vmnet'...
> >> > Cannot find device "on"
> >> > Usage: ip addr {add|change|replace} IFADDR dev STRING [ LIFETIME ]
> >> > [ CONFFLAG-LIST ]
> >> > ip addr del IFADDR dev STRING
> >> > ip addr {show|save|flush} [ dev STRING ] [ scope SCOPE-ID ]
> >> > [ to PREFIX ] [ FLAG-LIST ] [ label PATTERN ] [up]
> >> > ip addr {showdump|restore}
> >> > IFADDR := PREFIX | ADDR peer PREFIX
> >> > [ broadcast ADDR ] [ anycast ADDR ]
> >> > [ label STRING ] [ scope SCOPE-ID ]
> >> > SCOPE-ID := [ host | link | global | NUMBER ]
> >> > FLAG-LIST := [ FLAG-LIST ] FLAG
> >> > FLAG  := [ permanent | dynamic | secondary | primary |
> >> > tentative | deprecated | dadfailed | temporary |
> >> > CONFFLAG-LIST ]
> >> > CONFFLAG-LIST := [ CONFFLAG-LIST ] CONFFLAG
> >> > CONFFLAG  := [ home | nodad ]
> >> > LIFETIME := [ valid_lft LFT ] [ preferred_lft LFT ]
> >> > LFT := forever | SECONDS
> >> > interface  does not exist!
> >> > Started network profile 'vmnet'
> >> >
> >> > This is most likely related to netctl not handling the empty
> >> > BindsToInterfaces properly.
> >> >
> >>
> >> You are right. This (arrays in Bash) is pretty tricky. I believe it is
> >> fixed now. If so, the fix will land in netctl 1.1.
> >>
> >> Thanks,
> >> - Jouke
> >
> > The problem is that you're declaring it initially as a string, and then
> > expecting it to be an array. You simply cannot interchange the types
> > without encountering unwanted behavior like this.
> 
> I'd like to keep the possibility of having declarations like this in a profile:
> 
>   Address='1.2.3.4/5'
> 
> Although Address is treated like an array internally, this works. As
> far as I can tell it is relatively safe to treat non-empty strings as
> 1-element arrays.

I think this is the wrong thing to do. You need to enforce types if
you're consuming raw bash as configuration. You're telling people that
k='foo' is valid, but k='foo bar' is not and suddenly they must use
k=(foo bar). This is bizzare.

> > Note that you're still doing this in src/netctl.in:112. I'll also point
> > out that your -v check allows people to create profiles that do not bind
> > to any interfaces since it checks for the definition and not the
> > existence of a value -- are you sure you want this?
> 
> Regarding src/netctl.in:112, the variable is set to a non-empty string
> (in src/lib/globals:load_profile, it is actually verified that
> $Interface is non-empty). By the above safety assumption, this should
> be acceptable.
> The current behavior is to bind to the Interface by default. By
> explicitly setting BindsToInterfaces, this behavior can be altered.
> Indeed, it is possible to do
> 
>   BindsToInterfaces=''
> 
> in a profile, which will most likely screw things up (it will instruct
> systemd to bind to a device without a name). However, I consider this
> a usage error. The current configuration allows setting
> BindsToInterfaces to a possibly empty array as well as specifying it
> correctly by a non-empty string. Those are the uses that I would like
> to support. If a better way exists, I'd be happy to hear about it :-).

And based on what you said above, you don't believe this is a double
standard? If someone were to adhere to the fact that BindsToInterfaces
is an array and not a string, then BindsToInterfaces=() is a valid way
of declaring this as empty and netctl will respect that.

d


More information about the arch-projects mailing list