David Bustos writes: > Ok, then this is a systemic problem in the current repository that we > aim to address with the enhanced profiles project. With the > customizations separate from the defaults, we should be able to tell > whether the inetd.conf-prescribed services have been migrated into the > repository, even if the user has "customized" them by deleting them. So > 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.
OK; that makes sense. > 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. No migrated services doesn't necessarily mean that migrations were "undone" -- it could also mean that there were no migrations to do in the first case. It's also unclear how to know which migrations were done (the inetd.conf hash, maybe?). I'll try some experiments here and follow-up, but this doesn't sound very promising to me. > > Yes, if we're to allow anyone from outside the ON consolidation to > > pull this trick. The requirement is much lower if we can somehow say > > that all such problem will forever occur only in ON, and we treat it > > as a private matter ... but I don't think that's possible. > > Well I believe the prevailing winds of configuration manipulation > (migration and upgrade) are that it's better for everyone involved to do > the work after boot rather than before. There are many cases where this is implausible. For example, diskless and sparse-root zones have file systems that are read-only from the post-reboot perspective, but that are writable at the time packages are installed. I don't think we have complete freedom to move things out of postinstall and class action scripts and into SMF post-reboot services. > That should ease most problems > since the full functionality of SCF should be available. As such > I think we should avoid investing in upgrade-time configuration > manipulation (a position partly forced by insufficient unbooted- > repository functionality), which unfortunately prompts developers to > scrounge for post-boot hooks since neither SMF nor the packaging system > offer solutions for the common cases. You, on the other hand, have it > better than most, in inetd-upgrade. Odd that I don't feel fortunate. ;-} -- 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
