From: John N. <jo...@mo...> - 2004-04-21 23:54:37
|
ch...@to... wrote: >there should be plenty of ways to handle this in init scripts. >someone on this list once refered me to hprofile >http://hprofile.sourceforge.net/ >but it is a bit complex and has features that would not easily work with >all distro's > > That's not a bad idea. Beyond the distribution problems, though, doesn't it still just modify the file system? That makes it unsuitable for anything that occurs before the root file system is remounted into read-write mode (such as, for example, checking the root file system). >with the fstab problem solved networking would be the only other thing >that I can think of off hand. I'll try to give this some thought >how about some ideas of other things that might need changed. > > I also have dual samba configurations and dual /etc/modules.conf files (so my networking still works); I also just read a post earlier about getting sound to work from xmms under colinux. I'm not sure, but that might also involve some dynamic changes when moving from hosted to native mode. I can imagine a few other uses as well. >How about a "coetc" image that could be mounted on etc? a pre init script >could do this without an fstab entry. Just throwing an idea out there I >havn't completely thought it through yet. > I had the same thought not long after my last post (a certain epithet about "great minds" occurs to me right now... :-)).... although I have also not yet fully thought it through, some ideas did occur to me: * I agree that it needs to be done before init loads; otherwise little things like loading the correct inittab won't work. * This makes it rather dangerous to switch configuration sets after a boot. All kinds of things could suddently stop working. * It is unnecessary to devote partitions to this, since we can just use image files with a loopback. * It is probably best to keep these image files within the linux file space. The most sensible place to keep them is on the root file system, but obviously not within the /etc directory thereon. * To really be reasonable, there would need to be more than one of these: one for each configuration set (at present, we might as well call them the "hosted" and "native" sets). * It might even be possible to compress the images (any good compressed file systems available?) * It will make adding new startup daemons a real pain, since you'd have to duplicate the scripts and configs to the other versions of /etc. So this might be a typical startup sequence: 1. Because of boot parameters telling the kernel to do so, the kernel executes a pre-init script. 2. That script makes a decision as to what hardware environment it is running in (using environmental variables as with how linux currently differentiates user environments, presence of a cobd driver loaded in the kernel space, ...., whatever, the method here is not really important). 3. The script mounts the appropriate image onto /etc as read-only (you can't mount it read-write so long as the root file system is read-only, since the image is actually just a file). 4. Once the preinit script has returned, the kernel starts init. 5. Everything else proceeds normally until the root partition is remounted read-write. 6. Immediately after the root fs is remounted, the /etc mount is also remounted read-write. This is important since the /etc/mtab file (and others) gets modified pretty quickly, and we'd best be modifying the correct one! (An alternative would be to make all files that change into symlinks, perhaps onto somewhere in /var, but then we'd have to be sure that /var is already mounted, so some more elegant thinking would need to go into that one.) 7. The system boots up, completely unaware that an entirely different configuration is possible. Since each configuration is nicely encapsulated as an image file, all of the configuration elements are nicely separated, which makes commiting errors less likely. Still, we need to find out whether we can mount image files that early in the bootup process (because that's a real show-stopper if we can't), and the redundancy of configurations could sometimes be annoying (unless we could find some miraculous way to share *some* of the configurations between the two sets). Further, there is the headache of duplicating scripts and other settings whenever something new is installed (or, conversely, removing them whenever something is uninstalled). Owing to the difficulties I just mentioned, I'd say this idea is just begging for its own configuration management software (which would take care of the redundant install/uninstall stuff for each of the config sets, as well as managing changes between the two, etc). |