Using the LSB Bootscripts

Bryan Kadzban bryan at kadzban.is-a-geek.net
Sun May 8 17:46:49 PDT 2011


Bruce Dubbs wrote:
> Jeremy Huntwork wrote:
> 
>> * Add a param to release any dhclient addresses from a device if it is 
>> running in the ipv4-static service
> 
> Wouldn't this be a BLFS issue?  It's a good idea, but I don't use dhcp 
> myself.  It makes it hard to ssh into the system.

Unless you have DNS, and your DHCP server is set to update it as well.
And your DHCP server is set to prevent its clients from updating DNS
(since that's unreliable, since they don't always do it).  And all your
DHCP clients are configured to send a name in their request.  ...Hmm.

But anyway, this is off the topic of most of this thread.  :-)

>> * 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]'
>> * In the dhclient service, flush any static addresses as well.

This seems like it might be starting to get complicated.  The scripts
may set up more than just IP addresses.  (I have one to set up WoL bits
via ethtool, for instance.)

I don't think there's any way to make all potential service scripts able
to handle switching to and from all the other potential service scripts,
just by starting them.  I don't think that means it's not worth trying
to do this, but we do have to be careful not to imply that this sort of
thing will always work.

>> * Move ifdown and ifup to /sbin
> 
> This should have happened long ago.
> 
>> * Move the equivalent of /etc/sysconfig/network-devices/services to 
>> /lib/services
>> * Move the equivalent of /etc/sysconfig/network-devices to /etc/network
> 
> Agree.  I never liked the directory structure for network startup.

I think it's the way it is for historical reasons (we never made more
than the minimal changes required at each point).

I like not changing it, but only because I'm a bit of a curmudgeon, and
have gotten used to the way it is...

I do think putting the service scripts under a subdirectory /lib is
good, but maybe /lib/network-services or something (to be more explicit)
would be better than plain "services".

>> * Move /etc/sysconfig/rc to /etc/default/rc
>> * Move any remaining /etc/sysconfig files (like modules) to /etc/default
>> * Create an /etc/default/rc.local to house configurations like UTC and 
>> HOSTNAME
> 
> I'm not sure about the name rc.local, but I like the general idea.

I don't like it (not yet anyway :-) ).  I find "sysconfig" to be a *far*
more descriptive name than "default".

(Also I associate "default" with Ubuntu, which does not bring up happy
thoughts.  The reasons are not exactly important, and this is obviously
a personal-opinion thing.  And I now know it's at least a Debian thing,
and might be more widespread.  But the first impression still exists.)

"netconfig" (which is what I think it used to be) isn't correct anymore,
either.  But something in that vein would seem better than a generic
"default" that has no more information in its name.  It's *not* for
defaults, it's for configuration.

>> * Add logic from Fedora to kill client sessions to the sshd init script.
> 
> Again, BLFS, but I agree in principle.  OTOH you may want to keep an ssh 
> session active when restarting sshd.  I suppose this could always be 
> done with an ssh session to a non-standard port, but it warrants a bit 
> more discussion.

The only times I restart sshd, it happens from an ssh session.  I think
this needs to continue working.  You said (later on) that this only
applies to halting the system, but doesn't "reload" just call "stop" and
then "start", and doesn't system-halt just call "stop"?

It may be possible to do as you describe, but I'm not sure how; I'd like
to see how it was done.  :-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20110508/126aa16d/attachment.sig>


More information about the lfs-dev mailing list