Using the LSB Bootscripts
jhuntwork at lightcubesolutions.com
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
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
> 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 rc.site (which might have been completely removed since the
> selective booting has been removed). Really they should just be moved to
> the rc.site 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 rc.site 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