[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: named failing to restart after updating to RHEL3 U4
- From: Ed Wilts <ewilts ewilts org>
- To: "Discussion of Red Hat Enterprise Linux 3 (Taroon)" <taroon-list redhat com>
- Subject: Re: named failing to restart after updating to RHEL3 U4
- Date: Wed, 22 Dec 2004 09:45:02 -0600
On Wed, Dec 22, 2004 at 09:56:40AM -0500, Josh Kelley wrote:
> >Anytime an update gets released, I
> >put it on a test system first and then try my darndest to see if I can
> >break it. Only after testing do I manually push the updates out to
> >production.
>
> I feel like a novice for asking, but what's the easiest way to do this?
> I know that I should be testing updates before I install them on
> production servers, but I've always felt like the headache of (a)
> keeping a test server with a configuration that's relatively similar to
> my mail server and web server and file servers and everything else and
> (b) figuring out a suite of tests that's reasonably likely to hit
> functionality that might break is great enough that I instead just
> install updates without testing and hope that I can catch whatever
> problems occur before people get too upset. Is there some easy testing
> technique that I'm missing?
There is no easy way. In fact, if anybody tells you that there's an
easy way, they're probably lying.
It all depends on what you use the system for. If your system is
exclusively an anonymous ftp server, testing can be fairly easy.
However, if your system is used interactively by hundreds of users doing
weird and wonderful things, it's unlikely that you'll be able to test
everything. After all, Red Hat does a fair bit of testing themselves
and will hopefully get the obvious stuff. It's all the systems in
between that are the tough ones - some limited testing of the most
critical apps might be okay. Perhaps the testing is done right after
you upgrade (during a change window) and you have a back-out plan.
Many people have no test systems or test plans at all and work just
fine. In most cases, this is not a problem. You may just need to be
able to execute a back-out plan if you need one.
If users "get upset" if things break, then they need to give you funding
for a test system and a test plan. If they don't, then they need to be
told that they're rolling the dice and hope you don't come up with
snake-eyes.
--
Ed Wilts, RHCE
Mounds View, MN, USA
mailto:ewilts ewilts org
Member #1, Red Hat Community Ambassador Program
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]