loading conf files to a memory image dynamically

Can anyone help with some boot time "mod" configuration issues I'm having? I have a FreeBSD 8.3 image on about xx machines with a common image file created from "tinybsd" which is booted as a root memory disk.

The generic mfsroot.gz file and the /boot directory is on the root partition on a disk at boot time.

I have a /rc.d/load_config file in that generic image, which at boot time (REQUIRE root, BEFORE hostid_save,
hostname, FILESYSTEMS, <and a bunch of network related items>):
A) mounts mfid0d
B) loops through a config.conf file copying files from the physical config disk (mfid0d) to the
appropriate files locations such as /etc/ntp.conf, and /etc/resolv.conf, and most importantly
/etc/rc.conf on the memory disk
C) umounts the mfid0d drive
C) Set _rc_conf_loaded=false
D) load_rc_conf 'xxx'

The idea is that at boot time, the generic image starts to boot, copies at the last instant all the required variable configuration files, flags that the rc.conf file is not loaded, then has the system reload the rc.conf file and continues on the boot process. Thus keeping a generic image with a separate configuration partition.

The issue I see is that the rc process spawns off sub-shells to run each of the /etc/rc.d files. So even though I brought to the root file system a new rc.conf file, and flagged that the rc.conf has not been read, the parent shell still has already read and saved into memory the variables from rc.conf.

Can anyone think of a way to "load" a bunch of config files into the root memory file system at boot time so I can maintain a generic boot image across multiple machines, in multiple locations?

I do not want to "write" the config files to the mfsroot.gz file.

I also tried making /etc/rc.d/load_config become /etc/rc.d/load_config.sh which use to run it in the parent shell instead of spawning off, but in 8.3 it ignores that as an "old-style" which is no longer supported.

Thanks

Ken
 
While I could think of other ways, I think the most efficient solution is/would be to comment out DEPRECATED, or whatever trigger causes the "old-style" message, and prevention. Then you could continue, as you have in the past with your load_config.sh file. :)

--chris
 
Back
Top