On 10/5/07, Peter Tribble <peter.tribble at gmail.com> wrote: > On 10/1/07, Mike Gerdts <mgerdts at gmail.com> wrote: > > On 9/30/07, Peter Tribble <peter.tribble at gmail.com> wrote: > 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?
Not 100% requirement, but nice. In the past I used OpenPKG which is RPM based and was fully managed as a non-root user. However, not too many third parties distributed RPM packages to install on Solaris. The same system is desirable for maximum compatibility and ISV support. > > 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? To a certain extent, yes. However It can't operate in a complete vacuum because then you start to have to replace the OS stuff that is missing. Soon you need a sysadmin to maintain the OS stuff... > 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? The same. ISV's should have a set of rules to abide by and stuff just works. If rules are broken, the packaging system should be able to recognize it and not allow it. Debugging tools ala "ppriv -D" should exist to help understand why it is broken. > 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? Relocation works in some cases, but if the third party packages do dependencies right it is broken. There needs to be the cross-installdb notion of dependencies. Further, when you get things like services alternate root gets a bit ugly. > > 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. I think this speaks to the need for packaging to deliver services, not XML files that magically turn into services. Presumably some package or service signing mechanism would be useful so that local admins could sign a package saying that its installation and services approved. That way, it can deal with things like services, users, RBAC, etc. that may be delivered by the package. Package installation would require elevated privileges and application logic would be responsible for ensuring that policy is enforced. > > > 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? But I can't move a zone to a machine with different package, patch, etc. levels. "Update on attach" would help here, but it would be a one-way move. A big reason that I would want this functionality is for the ability to clean up OS issues independently of application issues. For example, if my $20 billion company acquires another $7 billion company, it would be helpful from a server & OS administration standpoint to be able to use the binary guarantee to easily scoop up all of the apps that were running on the old company's images and move them to the corporate standard image + hardware platforms. > > 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. Yup. This is a key area that breaks the simplistic alternate root installation. It also starts to get to the heart of a need for sysadmin signing of application packages to indicate that any elevated privileges, users, files outside of "exclusive directories", etc. are approved. -- Mike Gerdts http://mgerdts.blogspot.com/
