I'm working on a fix for CR 6392582. The problem is that our class
action script (i.inetdconf) causes inetconv to run in scenarios where
it shouldn't. In short, the fix is to trust the state of the
repository on upgrade from s10+ to reflect the administrator's intent
and not allow stale inetd.conf data to override.
In order to do this, I need to detect inside the class action script
whether the alternate root being modified ($BASEDIR) represents a
system that has already been upgraded to SMF. It turns out that the
existence of $BASEDIR/etc/svc/repository.db itself doesn't do that,
because it gets created by the upgrade package-install process --
before any actual import takes place.
My plan (right now) is to use this check:
[ -h $BASEDIR/etc/svc/repository-boot ]
This works, and seems to be a fairly solid indication that the system
has booted at least once under SMF, but it seems a touch slimy to be
depending on an implementation detail in this way, even in SUNWcsr.
Any hints or suggestions for better ways to handle this? (I don't
mind doing a bit of work for it, but I'm not going to rototill the
universe ...)
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
