We setup our environment with OpenPKG so that we have build server where we build binary rpms. These binary rpms are then "promoted" into our alpha repository, tested, then to beta, more testing and finally into production. The repository is accessed over http by all of our client servers. They update based on a script, which basically is using the openpkg build tool command. This provides for stability and ease of updates across our environment. I have a full document that I'm writing up. It's almost finished and when it is I will post it to the list here.
On Thu, 2004-09-02 at 03:10, Thomas Werschlein wrote: > Hello > > I am wondering how experienced openPKG users handle the release pace > openPKG provides - and enforces. If I look at the documentation, I see > that there are 3 openPKG releases per year and security updates are > provided for the last two releases "only". > > Somehow the same picture with the supported platforms: relatively new > versions of distributions (such as Suse 9.0) are already considered > obsolete. > > Don't get me wrong - this is no criticism. I just wonder how you do it > out there (especially for production systems, where you might have an > SLA on the services and only limited maintenance windows). > > - do you always have identical test system hardware available? > - or do you have two openPKG instances on the same host, one > productive and one to test the new release? > - how would you switch from one instance to the other? > - if there is a test system: after successful integration test - do > you mirror it on the production system or do rebuild the upgrade on > the production system? > > Introducing openPKG within our organization would clearly increase the > overall upgrade pace. At the moment, we stick to proven releases of > software and/or distributions as long as possible (of course, security > patches are applied). Clearly, openPKG would change this, which > clearly would be an advantage, if we can handle it effectively. > > Therefore, I would be very glad, if you could > - point me to available documentation I might have missed > - common best practices regarding upgrading openPKG > - tell me shortly how YOU do it > - tell me how you clearly wouldn't do it > > Any hints greatly appreciated. > > Thanks a lot, > > Thomas > > ______________________________________________________________________ > The OpenPKG Project www.openpkg.org > User Communication List [EMAIL PROTECTED] -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu "Only those who attempt the absurd can achieve the impossible."
signature.asc
Description: This is a digitally signed message part
