On Mar 30, 2012, at 8:28 PM, Bruce Dubbs wrote:
>> In fact, ifdown should *only* set DOWN when there are no IP configs
>> still attached to the logical interface. If there *is* an IP config
>> still attached to the logical interface, then ifdown should just
>> report a warning that it cannot set DOWN on that interface because
>> either 1) there are still IP configs on other linked virtual
>> interfaces, or 2) that the services failed to properly tear down the
>> IP configs. It might be hard to distinguish between the two, without
>> polluting ifdown with more service-like code.
>
> Leaving an eth0 up when bringing down eth0:2 is not an error. It
> shouldn't even get a warning. It would make a normal shutdown quite noisy.
The point is that when an IP config is still attached after ifdown, it's hard
to distinguish whether it's a downstream service-related failure from the valid
state of having multiple virtual NICs. So, I'm saying it *could* be an
error--but, regardless, it's information we need to convey.
It's somewhat analogous to unlinking a file descriptor that someone else has
open. The difference is that in the unlink() situation, it will happen, just
later. But, in our case, calling ifdown doesn't have the nice behavior of
setting DOWN once all the virtual NICs are gone. That's why I think the user
needs a notification. Because it *could* indicate a problem with other virtual
NICs (or their services) tied to to this PHYS. It might not. But, that's for
the user to figure out, based on having the information.
If you want to try to disambiguate them, that's just more work that goes into
ifdown...Something like: check the IPs...if there's a virtual link up, and it
matches the IFACE we're taking down, we clearly know its service
failed...report it...otherwise (if all IPs belong to other IFACEs), assume they
are perfectly valid, and say anything "non-alarming". I suppose that could
work. But, the less you say, the more state you hide.
Noise is only noise if it tells you something you already know. Issuing ifdown
eth1:1 and not setting DOWN on eth1 could easily be viewed as "exceptional".
I'm just on the side of more-rather-than-less info. Frankly, IDC if it's noisy
on shutdown--if the tradeoff is to get more info than less. Because, when I'm
running the script manually, I'm very interested in
alerts/warnings/info-messages which pertain to the current state of the system.
>> It should be up to the service(s) to bring down the configs. With
>> respect to virtual interfaces, presumably each eth0:n will be its own
>> config file, and each ipv4-static (or whatever service gives the IP
>> config) should tear down the IP config, too.
>
> Yes, the service script does remove the ip address. Trying to merge
> dhcp, bridging, static addresses, multiple IPs, etc is quite involved.
Frankly, it's not too bad. I just happen to write long emails, because I'm
never sure if everyone involved in the conversation knows all the pieces or
followed the previous threads. I could be less expository about my lines of
reasoning. In short: we're at least 95% of the way there.
Making sure virtual NIC support is solid is the last bit, and I'm fine with
using "ip addr show" as the reference counter. I'm bummed that there's isn't
an immediately-obvious "neater" way, but I think it's probably even more
important to solve the 99% case quickly.
As for the "warning", I still think that if ifdown can't finish (i.e.,
successfully set DOWN on the interface) you tell the user, regardless of the
reason. Let's not get hung up on my earlier use of the word "warning". My
point is that there's info that needs to conveyed. It could be delivered in
"white text" form with something like:
PHYS eth0 still has IP addresses assigned; not setting DOWN.
eth0:2 ....... 192.168.0.42
eth0:75 ...... 192.168.0.254
Moving forward, I'm also stipulating that the set of DHCP, bridging, static IP,
and virtual NICs is the entirety of the problem space. I agree that we're not
trying to solve every case, and that a hint suffices for people who need more.
I'm content with having IFACE represent the logical interface (and retracting
my <SERVICE>_IF idea). In the problem space defined above, BRIDGE_IF and
IPV4_IF (or DHCP_IF) is always the same. It's possible the virtual interface
is always the same for all services. And, if it isn't, we'll cross that
"bridge" later.
I propose adding PHYS as the physical link variable. I'd like to guarantee to
services that IFACE is always the logical interface, which means that we need
put the smarts in ifup: specifically, if no PHYS variable is found, use IFACE.
Doing so will preserves the existing semantics and require no modification of
the existing vanilla config files. That covers all the vanilla cases,
including virtual NICs. In the bridge case, where IFACE doesn't match PHYS,
both variables need to be included.
So, it boils down to this:
1) Replace "INTERFACES" with "PHYS" to bridge configs.
2) Allow ifup to use IFACE when no PHYS is set.
3) Apply hardware-type parameters (e.g., UP, MTU) in ifup.
This allows perfect compatibility with the existing network configs. It needs
ifup to be a bit smarter ("if-no-PHYS-use-IFACE" logic). It also allows ifup
to deal with setting UP and MTU on the PHYS link. And, as long as you enforce
the virtual interface vs physical interface semantics--i.e., PHYS is always
physical, IFACE is always virtual, and IFACE could be physical if PHYS variable
isn't set--then services can be well-encapsulated. Everything else remains
intact (along with my changes to bridge to take the PHYS handling out).
Just so I'm clear, I understand the need for incremental changes, and I'm
backing off my original proposal (what's in the ticket) of having a
<SERVICE>_IF variable for each service. I'm fine collapsing all those into
IFACE to represent a single logical interface (the one that receives IP
configurations). We just need a variable to represent the physical interface
for stuff like bridge. And, we want ifup and ifdown to set the physical
parameters on PHYS (even if we just set PHYS to IFACE when PHYS isn't present
in the config file).
And, yes, the equality check--as Xing said--is indeed (==), not (!=).
Q
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
