On Apr 6, 2012, at 3:24 PM, Bruce Dubbs wrote:
> Qrux wrote:
>
>> 1) Why is ifup bringing up the virtual interface? That is clearly a
>> service-level responsibility. In fact, in the case of a bridge, that
>> interface doesn't even exist until you create it with brctl. What
>> purpose does it serve in ifup?
>
> Sine it it placed after the creation/configuration, it brings up the
> interface specified and any component interfaces.
But why is it in ifup? ifup should not be aware of the bridge interface.
>> 2) Why does ifup manage any routing at all (including gw)? That's a
>> service-level issue.
>
> Sort of the same thing. It prevents needing the code in multiple locations.
It should only be in one location: ipv4-static. It's an IP configuration
parameter. Not a physical link parameter.
>> 3) Why does bridge handle setting IP_FORWARD? Why isn't that in
>> ipv4-static? Bridging shouldn't care about IP issues like routing,
>> and that's the wrong place to set it.
>
> It's needed for passing packets from the outside to a bridged device.
> It's there for convenience. If IP_FORWARD isn't specified, then nothing
> happens.
I'm not exactly sure how your bridge configurations look like. Even without my
virtualization setup, when I have a bridge on br0 that enslaves eth0, I don't
need forwarding to see "output" packets. Is there something strange that the
KVM stuff does to the default bridging configuration?
Secondly, (again with the why), IP_FORWARD is a system-wide setting. Why is
bridge handling that? Bridges should not be aware of IP_FORWARD. I would
stand behind your idea that IP forwarding should go in sysctl.conf.
The point is, this running theme of parameters being applied in inappropriate
places is the main motivation behind my scripts. Frankly, they are not that
different. The existing ones--including this round of changes--do not, and
seem to proliferate the surprising behavior of settings parameters in
unexpected places.
>> 4) Why pay any attention to the MTU value? Report an error from ip
>> if a bad MTU value is set; I don't think anyone needs to rely on the
>> ifup-&-co. scripts to check for valid values. ip will report those
>> values. AFAIC--and I was the one who put a numeric check in the
>> first place--it doesn't even need to check if it's a number.
>
> Yes, you suggested a numeric check, but you allowed an illegal value. I
> just added the check for a number at least as large as the minimum value
> allowed.
I give up on this issue--I don't care enough. This is either moot or it will
be changed when someone needs a smaller MTU value. I'm not aware of any
physical or kernel limitations on MTU, so if you are, then your info may be
more current than mine.
>> (Another minor point...Why specify BROADCAST? Isn't it unusual to
>> have an address/prefix that didn't produce the right broadcast
>> address.)
>
> An old habit. It used to be always required. Leaving it doesn't hurt
> anything.
It's completely superfluous. Yes, it *can* hurt. A wrongly configured
broadcast address can bork your IP configuration. If it's entirely unneeded,
don't you think it's better to leave it out? If the logic to look for it is
not there, it can't be misconfigured. It's entirely determined by the IP
address and the PREFIX. If the scripts look at PREFIX instead of a classic
netmask, then it should also avoid BROADCAST.
Look at it another way. Taking the BROADCAST-handling logic out does not hurt
ifconfig scripts that still have it in; it's just completely ignored. People
can get around to removing that extraneous parameter when they need it.
>> 5) What does this mean? "What these scripts to *not* do is process
>> multiple IP addresses if there is more than 1 ethx interface."
>
> I don't handle more than one value of $IP or $PREFIX.
When is this ever necessary? Aren't virtual NICs handled with additional
ifconfig files?
[Apparently, you answer this later...]
I was just asking if it was meant to be more meaningful than: "I don't do
anything that doesn't make sense to do."
>> 6) Also, do we just dislike PHYS as a variable name? That seems
>> preferable to two variables with similar and somewhat confusing names
>> (IFACE vs INTERFACES).
>
> It's a personal preference. The only place INTERFACES makes any sense
> is on a bridge. Most users will never use that.
Even if it's rarely used--which I don't necessarily agree with--should it be
confusing? If it's your scenario (that it's rarely used), then we have lots of
flexibility to choose a meaningful and less ambiguous variable name. If it's
often used, then it should *definitely* be less ambiguous.
>> 7) As for cleanly separating logic...The general guideline should be
>> that ifup should not use IFACE. In fact, only ifdown does, and
>> that's just a reference-counting shortcut. The other guideline is
>> that the service scripts should refer to IFACE, and only use PHYS
>> (what you call INTERFACES) as necessary (for example, in the case of
>> a bridge enslaving ports).
>>
>> Stuff like ifup handling gateways, bridge handling IP-related
>> sysctls, and ifup bringing up bridge interfaces all seem misplaced.
>
> The alternative is to replicate some functionality in multiple service
> scripts.
Where is this replication? In fact, I'm trying to remove replication as well
as surprising parameter setting in unexpected scripts.
> I could put the IP_FORWARD in the bridge script, but a user
> might well want to bring up eth0 and eth2 and enable IP_FORWARD. Of
> course, that could be also done in either syscyl.conf or in the iptables
> configuration script.
I would agree if you're saying that IP_FORWARD is a system parameter, and
should be set in a system-wide fashion, and not in a way that implies a
relationship to a per-logical-interface. Enabling IP forwarding in ifconfig
wrongly implies it's a per-logical-interface setting. It's very much a
system-wide parameter, and doesn't really make sense in ifconfig files.
Consider how it would interact with iptables if setting the sysctl happens only
if a certain ifconfig scripts gets reached.
In fact, if we stick by your "KISS" suggestion, IP forwarding shouldn't even
get treatment here. It's another "advanced" feature that people can enable on
their own. IP forwarding is orthogonal to bridging.
>> It's good to take time to look at this, but can you reframe this in
>> terms of the problems you're solving? AFAIK, there was only one
>> remaining issue to look at, which is how to properly support virtual
>> NICS. I thought I had resolved the issues with MTU, multiple PHYS
>> per bridge, and cleanly separating the service/physical logic issues.
>> It just seems like a lot of changes here are pushing the wrong logic
>> into the wrong scripts.
>
> I'd like to keep the scripts as simple as possible. What are the
> circumstances where more than one physical interface is needed for a
> bridge? How many of our users need such a capability?
>
> I'm trying to provide an alternate solution to the ticket you created.
> I was uncomfortable with your solution.
I don't have any issue with your discomfort, but I'd like to understand the
technical objection(s).
In the ticket, I already mentioned that I don't mind coalescing BRIDGE_IF and
IPV4_IF into IFACE. If I were to guess, that's what I'd say you're objecting
to. Once I get around to that, the ifconfigs look exactly as they did before.
The only difference would be where I'm using PHYS for INTERFACES, but I figure
that's easy to do a mental s/PHYS/INTERFACES/g to understand.
This variable coalescing doesn't change the scripts I provided materially,
except to rename those two variables. What it *does* do is keep IP stuff in
ipv4-static as much as possible, bridge stuff in bridge, and physical stuff in
ifup/ifdown.
They strive for clean separation and "unsurprising" behavior.
It seems that in trying to keep things simple, you're spreading logic into
strange places: ifup handles some IP parameters, physical link parameters, and
also brings up bridges interfaces. Then, bridge handles some IP issues, but
ipv4-static/dhcp also handles IP issues. Then (somewhat unavoidably), ifdown
handles some IP issues (not setting DOWN if there are other still IP
configurations up). You're also advocating an obsolete parameter like
BROADCAST, which ought be omitted if KISS is the guiding principle. And,
you're introducing IP_FORWARD, which should also be omitted on the same grounds.
I still need a few days before I have time to get to this again, and I hope we
have time to wait until then. I'm quite opposed to some of these changes.
Q
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
