David Bustos writes:
> I think you should target your solution at a post-enhanced profiles
> repository, and then look for a sufficiently-reasonable-for-least-work
> stopgap until then. Say by having inetd-upgrade only migrate inetd.conf
> when no migrated services are detected? Then only the user who undoes
> all of the migrations is injured, which seems pretty extreme anyway.
After some thought and lengthy experimentation, here's what I came up
with: I'm checking for the 'hash' property in inetd during the
inetd-upgrade service start method:
svcprop -qp hash svc:/network/inetd:default
This property is created by inetconv to keep track of changes in
inetd.conf, and doesn't exist in the seed repository. If that command
above succeeds, then it means we've run the import at least once, and
we need to avoid trying to enable services ("inetconv -e") based on
existing inetd.conf entries.
I'm going to run a few more tests to be sure, but I think I've got it
now.
The only problem is that this solution leaves others out in the cold.
If there's someone else (such as SUNWdtdmr) wheeling and dealing in
converted inetd services, they may well face similar problems, and the
above trick won't help.
--
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
