Summary: Using the LSB Bootscripts

DJ Lucas dj at linuxfromscratch.org
Mon May 16 00:07:42 PDT 2011


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.




More information about the lfs-dev mailing list