Hi,
Snv_151a, x86
I put some customizations into default.xml so some extra services are
disabled.
I confirmed that AI ould generate /etc/svc/profile/site.xml->sc_profile.xml
with all the customizations I put.
The problem is that the changes do not take effect. Well, they do but only
for a brief period.
This is what is happening:
1. AI properly creates site.xml
2. during the very first boot from a localdisk after AI networked
installation finished, system-early-manifest-import is run
(/lib/svc/method/manifest-import)
It will import all the manifests and apply generix.xml, platform.xml
and the site.xml
3. later in the boot process system-manifest-import is run (again
/lib/svc/method/manifest-import)
Although SVCCFG_CHECKHASH=1 for some reason it actually applies
generic.xml again (I mean it takes effect) undoing my customizations in
site.xml
The site.xml won't be applied again as it was removed by
system/install/config service.
There are couple of problems here:
I. why manifest-import ends up really applying generic.xml
despite SVCCFG_CHECKHASH=1? Looks like a bug...
If I manually disable some services now and reboot, both
early-manifest-import and manifest-import won't really apply generic.xml -
good.
It only happens during the first boot.
II. I'm not entirely sure that system/install/config should
just blindly remove site.xml. It does check if it is a symbolink link, but
it doesn't even check where it points to.
Then shouldn't SVCCFG_CHECKHASH=1 protect here anyway?
(I haven't looked at the code yet...)
I guess the problem might be not with disabled/enabled
services but with extra properties for install/config (create a user, etc.).
Perhaps AI customizations should really go to
/etc/svc/profile/site/AI_site.xml? I'm worried here if a sysadmin would put
its own site.xml (as a symlink) as part of a "finish script".
I commented out the removal of site.xml in system/install/config and it
doesn't really solve the problem. I end-up with all the customizations,
which is fine, but sometimes some services which should be disabled
according to site.xml manage to run their start methods between generic.xml
is applied and site.xml is applied which caused some transient errors. But
they shouldn't have even try to start in the first place. It's all down to
timing nevertheless it happened couple of times.
I think that the main problem is I. The II. Is more of a concern than a
problem and it makes things unnecessarily more complex than needed.
--
Robert Milkowski
http://milek.blogspot.com
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
