On 05/16/2011 12:49 AM, Bryan Kadzban wrote: > Zachary Kotlarek wrote: >> On May 15, 2011, at 12:31 PM, Bryan Kadzban wrote: >> >>> I'm trying to figure out why it'd be necessary to do this. We >>> already have the previous configuration of every interface stuffed >>> away in /run, and we use that when deciding which service scripts >>> to call when bringing down networking. Doesn't that kill the pppd >>> / pppoe / dhclient / dhcpcd / whatever daemons already? And >>> doesn't that remove the IPs that were configured already, for >>> static? >> I thought the goal was to predictably handle scenarios where the >> running config didn't match the cached version, or where there was no >> cached version. > While I don't want to speak for the people actually doing the work here, > it seems to me like this might be getting a bit complicated for the wins > here. I don't think it's very likely that there is no cached version > (since we store it away at boot time when the scripts set up the > interfaces). > > I also *think* the only way the cached config might not match the > running config is if root mucked with the running config manually. And > in that case, I don't think it's smart to override that decision. > > (Consider, for instance, a setup that requires two IPs on a single NIC, > both on a single subnet -- say one for management and another for real > traffic, with filtering upstream to prevent management packets from the > public Internet. The management IP might be set up outside the scripts > for some reason (especially at machine setup time, but potentially in > other cases as well, for configuration management and redundancy > reasons), in which case flushing all IPs at interface-down would be > actively harmful.) > > Though I suppose this isn't terribly likely either. Hmm. > >> If the goal is only to directly cancel the configuration as-cached, >> and not to care if that cache is no longer accurate or no longer >> exists, then I agree, there's no need to do any of this special >> handling as the normal service scripts should be sufficient. > I'm not sure what the goal *should* be. :-) Does it make sense to try > to clean up completely in this kind of setup? Maybe or maybe not. > > I do think it's least *surprising* to only undo the effects of the start > script, though. For whatever that's worth. It is worth a lot, and I'm kind of in the same camp. However, there was a request, and I'd like for this to be the same solution for all _if_possible_. The thing is, what do admins typically do when using other distros? I know how I make changes in LFS, and that involves a temporary config file, stop networking, copy new config, start networking, which seems pretty obvious to me having been using LFS for so long. When I use a distro, I usually use some distro supplied tool to make configuration changes, but I only maintain maybe 10 distro Linux servers at this point, and couldn't tell you the last time I had to make networking changes. This may not be the case for somebody who has been using say RedHat on 50+ servers for the past 10 years and knows the format of the configuration files like the back of her hand.
For instance, take a temporary configuration change, admin might simply run 'ifdown eth0' (or 'service network stop') expecting all the configuration changes to go out the window right then (I don't honestly know if that is the case in other distros, I know that it works as is for ). I don't think that is unacceptable, it's just finding a working solution that is agreeable by everyone. An argument can equally be made for root changes to be undone by root (as above, and I am actually in that group). As far as I'm concerned, what is there now works well enough for my purposes, and probably greater than 99.99% of all users, but I don't mind spending the extra time to explore the possibility of additional functionality to cover the other less than .01%, but I do need to step back for a second and take into account all arguments for/against. If I do come up with what I think to be a working solution, it certainly won't go in without review because I don't use the other services very often (at all right now, everything is static now). I need to see if it would reek havoc on other corner cases such as the one mentioned above. It may be that we can't meet everyone's expectations (which is why I haven't simply added 'ip addr flush $1' to the end of the ifdown script yet). That is another thing too, now that ifup and ifdown are no longer in a controlled environment and available to admins without mucking around in the network-devices tree, some error checking needs to be done in the scripts for proper arguments and maybe a help text. As it is now, if you run ifdown on an interface that has no config file, you get a warning and an ugly error message from bash. That will probably be another small change that doesn't have any affect the existing automated setup. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
