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.
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
