Re: Updating: RHel 5.x baseline and tailored updates or intermediate baselines

Hi,

Why do you feel the need to fix a baseline?

If you are going to do that then I would assume satellite will be the easiest way to manage this....but of course that costs and its not that great.........but it probably allows you to do what you want....ie have rolling baselines...

So we have the base RH channel, then a testing channel and a prod channel....testing is 2 to 4 weeks behind RH base and prod about the same behind testing....but I doubt its of huge value as its a lot of work to maintain this.....on the other side of the coin however RH's quality isnt 100% perfect....ie they have minor screw ups.....so way up the time to have such a regime v the time to fix major issues......

regards 

Steven Jones

Technical Specialist - Linux RHCE

Victoria University, Wellington, NZ

0064 4 463 6272

________________________________________
From: [email protected] [[email protected]] on behalf of David Lee [[email protected]]
Sent: Monday, 23 April 2012 10:30 p.m.
To: [email protected]
Subject: [rhn-users] Updating: RHel 5.x baseline and tailored updates or intermediate baselines

Preliminary question: is this list still actually active?

The main question...

We need to decide a philosophy of RHEL installation and updating to
achieve stability and uniformity across a group of machines.

The main question is about the baseline we should use for system
deployment.  (In other words, to be able to say "This is what we roll
out and maintain consistently across the machines.")


The two main options for establishing our baseline seem to be:

1.  Pick some arbitrary, but fixed, point in time to generate a frozen
local repo based on the RHN repo at that time;

2.  Use an official RHEL 5.x release.

In favour of the first (our point-in-time, from RHN) is that the
baseline will (at the point of freezing) be reasonably up-to-date; i.e.
notional minimisation of both bugs and integration instability.

In favour of the second (official 5.x) is that such releases will have
undergone more thorough integration testing.  (Put the other way:
arbitrary point-in-time snapshots have a slightly higher risk of
creeping instabilities, as bugfixes etc. have the potential to introduce
new problems, including unforeseen interactions with other areas.)


Whichever we choose, we'll need to supplement this with a means to
introduce (again from RHN) targeted, specific bugfixes for specific
problems (e.g. security fixes) but I believe that is more or less
independent of where we make the baseline for our systems.

So advice (or pointers to papers offering advice) on where to place the
baseline (RHN or ISO) would be welcome.

If there is a more appropriate forum for this question, let me know.


--
: David Lee
: ECMWF (Data Handling System)
: Shinfield Park
: Reading  RG2 9AX
: Berkshire
:
: tel:    +44-118-9499 362
: email:  [email protected]

_______________________________________________
rhn-users mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/rhn-users