Re: cloner interface handling in rc.d/network

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> 3a [ ! ... ] should better be written ! [ ... ], no?
> Probably yes, but it works either way.

I see no reason to prefer either over the other.  What am I missing?

>> 3b ! [ ... ] && foo could be written [ ... ] || foo
> It could, but that would alter the semantic slightly.

How would it alter the semantics?  The only way I can see is that it
would alter the status returned from the construct in the case where it
doesn't run foo.  In this case, though, the status returned from that
construct appears to be ignored, so I'm clearly missing something.

>> 3c What is this trying to catch? Directories called
>> /etc/ifconfig.tun0?
> Cloner interfaces that exist but have no /etc/ifconfig.* files at
> all.

It actually does a little more than that...in theory.  See below.

> Non-file isn't really it (-e would work) - but an /etc/ifconfig.*
> which isn't a file isn't very likely, and certainly isn't likely to
> work.

Does -f accept a symlink to a plain file?  The presence of -h argues
that it uses lstat(), but it might do so only for -h.  (I would argue
that a symlink to a plain file should work.)

> The idea is to simply stop if the file doesn't exist.  Since the file
> comes from a glob expansion, the only way it can not exist is if the
> pattern didn't match, and so what "int" was set to is the pattern,
> ie, literally just like  int='/etc/ifconfig.${cloner}[0-9]*'

In theory, there's also the question of what happens if there is a file
called, say, /etc/ifconfig.tun0* (the * being part of the name).
As another possible issue, consider a cloner interface called, say,
tun0foo, whose unit 1 would be tun0foo1, whose file would match the
tun0* pattern.  (Obviously, not a concern with the current crop of
cloners, but nothing prevents someone from implementing one, right?)

More serious, to me, is that it pays attention to only files, ignoring
any possible ifconfig_$int$num variables.  This is admittedly
auto_ifconfig-specific code, and all the versions I have easy access to
(4.0.1, 5.2, and 9.1 - 1.4T didn't have cloners at all) all ignore
those variables in the auto_ifconfig case.  But it still feels broken
to me - I've never liked splitting interface configuration across
multiple files.

> Not sure why ## rather than # - in the case where an interface was
> named foo3.7 or something the ## variant is likely to fail.

Possibility: maybe it was adapted from something that gathered files
from subdirectories, many of which might have dots in their names, and
that particular bit of syntax was never updated?

I'm not sure whether I think it's more likely that the /etc/ifconfig.
prefix would be changed to grow another dot or that a cloner interface
with a dot in its name would appear.  Neither feels very likely to me.

> [...] but then again, I don't think we have any cloner interfaces
> with names like that, and because of the way cloners are generated, I
> don't think we ever can, so it really doesn't matter

Um?  What prevents a cloner from having a name like x.y.z?  I haven't
looked at the code, but that seems like a peculiar restriction.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B