James Carlson wrote: > 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.
Sparse root zones share their RO files w/ the global zone, so those actions could be handled when the global zone boots. The other case is the read-only root/usr situation, which needs work. - Bart -- Bart Smaalders Solaris Kernel Performance barts at cyber.eng.sun.com http://blogs.sun.com/barts
