On 9/30/07, Peter Tribble <peter.tribble at gmail.com> wrote: > While there exists an OpenSolaris install strategy, that strategy > explicitly does not encompass packaging and patching, for which a > separate strategy is needed. > > Development of such a strategy is sorely needed. Especially given > current concerns over where packaging is headed. We should be asking: > > - What are the future needs that the package/patch system needs to > address?
Multiple installation databases per machine. 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. 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, etc. can be scooped up and moved to the next machine without anything that resembles a re-install. 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. > - What are the shortcomings of the current system? Somehow Sendmail and/or Apache keep finding their way into kernel patches. Given that these tend to have remotely exploitable problems with a frequency much higher than the kernel, such co-dependencies need to be avoided. This may not be an issue for packaging/patching, but it is not clear to me where it needs to be addressed. I've never compiled a version of Sendmail or Apache that said "you are on revision 23 of the kernel patch, you really need to be on revision 24 to get this critical security patch." > Some of my initial thoughts which aren't at this point broken down into > the structure above: Very good stuff. I don't have time to address any that I have thoughts on right now, but will try to find some time to get to them soon. -- Mike Gerdts http://mgerdts.blogspot.com/
