Using the LSB Bootscripts

DJ Lucas dj at linuxfromscratch.org
Sun May 8 23:53:30 PDT 2011


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.




More information about the lfs-dev mailing list