Using the LSB Bootscripts

Jeremy Huntwork jhuntwork at
Mon May 9 10:15:12 PDT 2011

On 5/9/11 2:53 AM, DJ Lucas wrote:
> The simple solution is to stop networking before applying changes. When

Yes, I know. :) But in practice that becomes an annoyance. Admins used 
to working Fedora/Debian/Ubuntu or others assume that changing the 
config and running 'service network restart' is sufficient.

> service. IPCop has a nice console configuration tool that you might be
> able to look at for this if one is not already in place (sorry, I
> haven't had the time to give LightCube a spin yet). Perhaps Giles could
> chime in here if needed.

LightCube is mostly manually configured at the moment, I haven't had a 
chance to look at IPCop yet either, perhaps soon.

> Also, it looks like Bryan crossed my message while i was writing further
> in the BLFS case. Again, in LightCube OS, you have less variations and
> can conceivably account for them all (or provide a tool to do the job
> correctly).

That is true and we're prepared to fork the code as necessary, but I 
feel like there's a solution hiding here somehwere.

> Maybe add an additional function to make the behavior configurable and
> call that function? It'd make the scripts a tiny bit cleaner as well.

Hmm, that's a thought.

>> * In the ipv4-static service, instead of attempting to remove the IP set
>> in the configuration file, just flush all addresses with 'ip addr flush
>> [dev]'
> I think that it would work as written in your setup, but just in case
> you didn't check, what happens in the event of eth0-1? Again, however,
> BLFS target makes this not easily maintained.

I haven't tried virtual interfaces yet. That's something I should try 
next, thanks for bringing that up.

> Less files to worry about, single source I trust, but it is also less
> specific as to what those files are used for. I'm guessing that rc.local
> is what was (which might have been completely removed since the
> selective booting has been removed). Really they should just be moved to
> the file if LFS keeps the existing layout. I'm not particularly
> partial to the /etc/sysconfig hierarchy, only, as mentioned above, that
> it makes it compatible with instructions currently in the book.

Yeah is better, see my other reply to Bryan.

> Well, I wouldn't jump to that conclusion just yet about merging
> "upstream", but obviously if they diverge too far (as is the case
> currently) it would be a maintenance nightmare, besides, you would need
> to have them in a local repo anyway and LFS is still using Subversion.
> Git would make maintenance merges between the two much easier, but that
> really isn't your responsibility unless you choose to make it so, which
> is currently a manual effort.

Well let's see what happens. It would be nice to find a solution that 
works for both.



More information about the lfs-dev mailing list