On 10/1/07, Mike Gerdts <mgerdts at gmail.com> wrote: > On 9/30/07, Peter Tribble <peter.tribble at gmail.com> wrote: > > - What are the future needs that the package/patch system needs to > > address? > > Multiple installation databases per machine.
Good point. This has been discussed a time or two, but I don't recall that we really came to any conclusions. It's worth exploring in more detail. Now, do they *have* to be using the same system? Is the same software and tools for systems and applications necessary? > I would really like to > see a mechanism that allows the system administrator to maintain tight > control over the OS packages & patches while delegating the > application packages & patches to an application admin. Delegation: does this imply that the systems administrator create a sandbox for the application admin to work in? Packages: would the exact same package be expected to work in both cases? (Yes, I know that some software doesn't make sense in an application context.) Or would you expect different packaging for the system and application versions? Currently, unprivileged users can't use the svr4 package tools at all. If they could, is simple relocation (using -R) adequate? And if not, what else needs to be in place? > The > application package database and installation hierarchy is likely > managed by a non-root user and operations performed by non-root users > don't get root-like privileges. That is, root may be required to > create and set permissions on some directories initially but then > application software administration is not done by a sysadmin yet good > tools are available for managing application packages. When the > server is replaced (or replicated for HA/DR), the application database > and related files, services, If we're going to delegate packaging, and SMF is the way that services are managed, then that implies SMF delegation and a separate SMF repository too. > etc. can be scooped up and moved to the > next machine without anything that resembles a re-install. This starts to sound like a software virtual machine. Why not go the whole hog and use a virtual machine or zone? > Think of > it kinda like flash archive for the application packages only. The > number of such installation databases should not be limited to just > two. Best practices should be established but not strictly enforced > indicating how dependencies are handled between packaging databases. Dependencies is where it gets really interesting. The notion of dependency implies that the environments are aware of each other, so the application environments need to be explicitly delegated, or have to register themselves in some way. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
