On 05/08/2011 06:25 PM, Jeremy Huntwork wrote: > Hello, > > So we've been using the LSB bootscripts for some time now on LightCube > OS, with very little modification (we added dhclient service and the > random bootscript to the default install), and it's behaved wonderfully. > > There have been a few things that we noticed that we felt needed to > change, namely: > > * ifdown uses the configured service script to remove addresses from the > interface. This becomes a problem when a user changes the configuration > before running the script to restart networking.
The simple solution is to stop networking before applying changes. When performing manual configuration, I would have thought this obvious, but I've been using LFS for a very long time and this might not be the case for users of other distros. I don't know how you have LightCube's UI doing the changes, but rather than apply changes and then restarting, the logical order is to write a temp file, stop the interface, replace the interface configuration file with the temp file, and then start the 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. That doesn't mean that there isn't room for improvement, just never really thought much about it as I thought above was the obvious method. There was one caveat with one of the dhcp clients (I believe it was dhclient, but I'm not absolutely positive on that), in that if the daemon receives SIGTERM, all interfaces using that dhcp client were dropped. There is some logic to that effect in the current service scripts. Sorry, fuzzy memory, but I'll try and look at it on Wed night. Also, it looks like Bryan crossed my message while i was writing further down, but I agree with him on this. It would be impossible to catch all variations in the BLFS configuration, whereas in LightCube OS, you have a well defined group of programs that will be used, and a well defined target audience. Anything non-standard falls to the user. While it is the same is true in BLFS, we have to pretty much expect to see "non-standard" configurations, and catering to only a few will undoubtedly lead to some corner case where the added functionality has to be disabled. Given the above, I think that the need to stop the interface before any reconfiguration is not an unrealistic expectation 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). > Two possible scenarios here. One, the static service tries to remove the > configured IP address from the device (which has changed and will thus > fail) and adds the new IP. The result is two static IP addresses on the > device. The second scenario is if you change the service, say from dhcp > to static. The static will not kill the dhcp client when it restarts, > and you could have two addresses again. Similarly, the dhcp client will > not remove static addresses already assigned to the device before > launching itself. > * When using in production systems, the heavy use of 'read Enter' on > script errors, especially in generic cases, make it difficult to manage > remote machines that have encountered an error on boot or halt/reboot. 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. > * The sshd script (from BLFS) when halting doesn't kill user sshd > sessions. It just stops the daemon. This results in frozen terminals > until the session times out. > * The organization of files feels like it could be improved and made > easier. For example, the ifdown and ifup scripts seem better placed in > /sbin. > That I like, probably should have been done a long time ago. > All of the above has led me to modify the scripts for LightCube's use > and make the following changes: > > * Add a param to release any dhclient addresses from a device if it is > running in the ipv4-static service We'd need to extend this far too much in BLFS (See Bryan's message) > * 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. > * In the dhclient service, flush any static addresses as well. Same issues as above for BLFS's target. > * Move ifdown and ifup to /sbin Absolutely. > * Move the equivalent of /etc/sysconfig/network-devices/services to > /lib/services > * Move the equivalent of /etc/sysconfig/network-devices to /etc/network > * Move /etc/sysconfig/rc to /etc/default/rc > * Move any remaining /etc/sysconfig files (like modules) to /etc/default The currently layout is to be compatible with the instructions in the book. > * Create an /etc/default/rc.local to house configurations like UTC and > HOSTNAME 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. > * Add logic from Fedora to kill client sessions to the sshd init script. > This should go into BLFS as well. > There have been a few other minor modifications as well. > > Obviously, with that many changes to the structure of the scripts, I > don't expect them to be merged upstream. I assume I'd have to manage > them myself. 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. > So this raises the question of licensing and/or proper > attribution. From what I can tell, the scripts don't contain any sort of > license. What should be done? > > Thanks, > > JH Bruce covered that one already. Thank you very much for the detailed feedback and suggestions. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
