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 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. Thanks, JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
