Using the LSB Bootscripts

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


Jeremy Huntwork wrote:
> On 5/8/11 8:46 PM, Bryan Kadzban wrote:
>> 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.
> 
> Well, how many services will there ever be that operate on the same 
> device?

I believe the book has static IP addressing, and DHCP.  There's also
both PPP (for both dial-up modems and cell-phone-network access) and
PPPoE, and I've added WoL to this system, as noted above.  (Obviously
that only works for wired network cards though.  Not modems or wireless
or whatever.)

Wireless I have no idea how to set up using this system, although I was
going to do it at one point.  wpa_supplicant is complicated.  :-)

> If there's much more than what I'm thinking, perhaps you're right and
> it is complicated. In which case I think the underlying methodology
> for bringing up the device needs to be adjusted somehow. Bringing up
> the device by configuration is fine - that's how it should be. When
> taking it down, however, you need to remove any possible configured
> service on it.

Right, but you have no way to know (in the static config, or the DHCP
config, for instance) whether a pppd was running and needs to be killed,
or whether DNS needs to be unregistered (unlikely, but not impossible),
or whether a wireless card needs to be disassociated.

I think it makes sense to require that if an interface needs to have its
method(s) switched, then it needs to be ifdown'ed under the old config,
and ifup'ed under the new config.  That way they can all clean up after
themselves, because they all know what needs to be undone for proper
cleanup.

(Unless I'm missing something here.  :-) )

>> 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.)
> 
> The reason default was chosen was in order to merge other system-wide
> configuration files, such as /etc/default/useradd, for example.
> Either name works for me, really, but the idea was to consolidate.

I can see that logic, I suppose.  But bootscript config (which is what
both /etc/sysconfig/rtc and friends, and /etc/sysconfig/network*, are
today) seems different enough from systemwide defaults for new users, to
warrant a different directory.  Maybe the useradd defaults file should
have been stuck somewhere near /etc/skel or something.  But at least in
my mind, separating the two makes sense.

(Then again, my mind is a scary place.  :-P)

>> It may be possible to do as you describe, but I'm not sure how; I'd
>> like to see how it was done.  :-)
> 
> I'll get the scripts up as soon as I can.

Ah, I see what was done: they test $runlevel, then kill all sshd's in
the case of a reboot or halt.  (This includes killing the script that's
running, but the do-nothing trap installed before the killall and
removed after it, stops it from failing.)

What happens if the machine shuts down with ssh sessions active, without
this?  Do they just hang and eventually time out?  Or do they die when
the NIC gets taken down?  (...Is the kernel that smart?)  Or does
something log all users out earlier?  (What about killall5, run from
sendsignals?  That might be too late though?)

Not sure if I think it's worth this complication, but it depends on the
downside.

-------------- 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/1a29df2c/attachment.sig>


More information about the lfs-dev mailing list