Forgive me in advance for saying this, but both of these solutions seem pretty kludgy. Utilizing the legacy rc scripts to push a SMF change after the fact seems to invalidate the utility of SMF. And replacing a whole manifest with something homegrown in order to affect a single dependency change likewise seems to me like throwing out the baby with the bathwater and potentially breaks future manifests which may already include dependency on system-log; potentially a slippery slope.
I understand that I cannot use svccfg in a jumpstart script as the target root doesn't yet have a populated SMF repository. However, my questions something more like; there exists already a way to add a site.xml to the profiles directory of the the target root such that it will be imported on the first real boot and that services that I don't want to run won't ever run and vice versa, so it stands to reason that perhaps there exists a way to likewise make changes to the SMF repository that will be automatically incorporated on first boot. Does such a feature exists? If not why not? Making changes to the manifests as shipped with Solaris' base config would be foolhardy on a deployment of any sort of medium to large scale as you would then have to roll your own sytem of managing these changes which would be wiped any time Sun pushes a new manifest in a patch or upgrade. It says as much directly at the top of the manifests. Am I misunderstanding the situation? Or is this really just a piece of the puzzle which hasn't been fully fleshed out yet? This message posted from opensolaris.org
