Re: Summary: Using the LSB Bootscripts

Bryan Kadzban wrote: > DJ Lucas wrote: >> * the path for the setclock script in 55-lfs.rules needs to be >> changed > > So... yeah. > > Why was this whole tree moved in the LSB scripts, again? :-) > > I really really hate systems where I can't reasonably tab-complete > the bootscript filenames

Re: Summary: Using the LSB Bootscripts

On 5/15/11 3:25 AM, DJ Lucas wrote: > wanted anyway). Problem with dhclient is that the value of DHCP_STOP > will always be empty...all interfaces using dhclient will go. If you do > 'service network stop' then no big deal. OTOH, if you execute ifdown > ethn, and you have dhclient configured on mul

Re: Summary: Using the LSB Bootscripts

On 5/18/11 12:28 AM, Bryan Kadzban wrote: > Anybody know how other distros do it? I can't figure out what Debian's > ifdown binary is supposed to do (its source is *extremely* obfuscated, > being built from a texinfo file, and containing a file parser)... Fedora does a much more elaborate version

Re: Summary: Using the LSB Bootscripts

On 05/17/2011 11:34 PM, Bryan Kadzban wrote: > Few nits related to the shell. In the network script: > >> # Process individual configuration files >> for file in `ls "${dir}"`; do > Ew. :-) How about: > > for file in "${dir}"/* ; do > ONBOOT=`grep "ONBOOT" "${file}

Re: Summary: Using the LSB Bootscripts

Few nits related to the shell. In the network script: > # Process individual configuration files > for file in `ls "${dir}"`; do Ew. :-) How about: for file in "${dir}"/* ; do ONBOOT=`grep "ONBOOT" "${file}" | sed ... ... (since it always does a ${dir}/${file} as

Re: Summary: Using the LSB Bootscripts

Jeremy Huntwork wrote: > On 5/16/11 1:49 AM, Bryan Kadzban wrote: >> 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 sc

Re: Summary: Using the LSB Bootscripts

On 05/17/2011 08:54 AM, Jeremy Huntwork wrote: > > I do think we're getting a little overcomplicated here. Let's try to > simplify expectations. Here's what I expect (and I *think* this is > reasonable - you tell me :-) ) > > When I run the equivalent of /etc/init.d/network stop: > > All devices co

Re: Summary: Using the LSB Bootscripts

On 05/17/2011 08:54 AM, Jeremy Huntwork wrote: On 5/16/11 1:49 AM, Bryan Kadzban wrote: 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 s

Re: Summary: Using the LSB Bootscripts

On 5/16/11 1:49 AM, Bryan Kadzban wrote: > 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

Re: Summary: Using the LSB Bootscripts

Zachary Kotlarek wrote: > A compromise might be to provide an `ifreset` script, that does a > full ipflush, walks the services dir calling a `reset` target, etc., > but *not* integrate that script into ifdown. That seems like a pretty good idea. :-) signature.asc Description: OpenPGP digital s

Re: Summary: Using the LSB Bootscripts

Bruce Dubbs wrote: >Zachary Kotlarek wrote: >> On May 16, 2011, at 12:49 AM, Bryan Kadzban wrote: >> >>> I also *think* the only way the cached config might not match the >>> running config is if root mucked with the running config manually. >> >> >> Or when /run is not writable at the time th

Re: Summary: Using the LSB Bootscripts

Zachary Kotlarek wrote: > On May 16, 2011, at 12:49 AM, Bryan Kadzban wrote: > >> I also *think* the only way the cached config might not match the >> running config is if root mucked with the running config manually. > > > Or when /run is not writable at the time the network scripts execute. T

Re: Summary: Using the LSB Bootscripts

On May 16, 2011, at 12:49 AM, Bryan Kadzban wrote: > I also *think* the only way the cached config might not match the > running config is if root mucked with the running config manually. Or when /run is not writable at the time the network scripts execute. Or if the cached config were lost fo

Re: Summary: Using the LSB Bootscripts

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

Re: Summary: Using the LSB Bootscripts

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

Re: Summary: Using the LSB Bootscripts

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. Do

Re: Summary: Using the LSB Bootscripts

Zachary Kotlarek wrote: > On May 15, 2011, at 2:25 AM, DJ Lucas wrote: >> might actually be easier to provide a default IFCONFIG values in >> each service script, and walk /lib/network-services. > > This make sense to me -- then it's easy to extend the same approach > for arbitrary service types

Re: Summary: Using the LSB Bootscripts

DJ Lucas wrote: > * the path for the setclock script in 55-lfs.rules needs to be > changed So... yeah. Why was this whole tree moved in the LSB scripts, again? :-) I really really hate systems where I can't reasonably tab-complete the bootscript filenames. And there's way too much junk in /etc

Re: Summary: Using the LSB Bootscripts

On May 15, 2011, at 2:25 AM, DJ Lucas wrote: > might actually be easier to provide a default IFCONFIG values > in each service script, and walk /lib/network-services. This make sense to me -- then it's easy to extend the same approach for arbitrary service types -- say pppoe -- which might wa

Re: Summary: Using the LSB Bootscripts

On 05/15/2011 01:39 AM, Nathan Coulson wrote: On Sat, May 14, 2011 at 9:36 PM, DJ Lucas > wrote: On 05/14/2011 04:37 PM, DJ Lucas wrote: > Everything is covered per this conversation in SVN with the exception of > accounting for missing /run i

Re: Summary: Using the LSB Bootscripts

On 05/15/2011 01:22 AM, DJ Lucas wrote: > On 05/15/2011 12:11 AM, Zachary Kotlarek wrote: >> Could we just do this in ifdown: >> >> if [ -x /lib/network-services/dhcp ]; then >> /lib/network-services/dhcp $interface down >> fi >> >> and assume that whatever DHCP client is ins

Re: Summary: Using the LSB Bootscripts

On Sat, May 14, 2011 at 9:36 PM, DJ Lucas wrote: > On 05/14/2011 04:37 PM, DJ Lucas wrote: > > Everything is covered per this conversation in SVN with the exception of > > accounting for missing /run in LightCube OS, but I think it was decided > > that it would be added. Also no ip flush (I forgo

Re: Summary: Using the LSB Bootscripts

On 05/15/2011 12:11 AM, Zachary Kotlarek wrote: > Could we just do this in ifdown: > > if [ -x /lib/network-services/dhcp ]; then > /lib/network-services/dhcp $interface down > fi > > and assume that whatever DHCP client is installed (if any) provides a script > appropria

Re: Summary: Using the LSB Bootscripts

On May 14, 2011, at 11:36 PM, DJ Lucas wrote: > I'll need to setup both DHCP clients to test functionality for this, > which is why I didn't just do it tonight. The problem I want to avoid is > if we do a flush, but the client daemon is still running, come > expiration, the client daemon might

Re: Summary: Using the LSB Bootscripts

On 05/14/2011 04:37 PM, DJ Lucas wrote: > Everything is covered per this conversation in SVN with the exception of > accounting for missing /run in LightCube OS, but I think it was decided > that it would be added. Also no ip flush (I forgot, but will get it in a > day or two) on down interface, an