1 |
On Sun, 01 Jan 2012 19:24:35 -0500 |
2 |
Michael Orlitzky <michael@××××××××.com> wrote: |
3 |
|
4 |
> On 01/01/2012 07:09 PM, Neil Bothwick wrote: |
5 |
> > On Sun, 01 Jan 2012 18:07:45 -0500, Michael Orlitzky wrote: |
6 |
> > |
7 |
> >> Usually it's because a world update wants to do both trivial |
8 |
> >> version bumps and replace major software at the same time. I can't |
9 |
> >> take a server down for an hour in the middle of the day to update |
10 |
> >> Apache, but I can bump timezone-data, sure. |
11 |
> > |
12 |
> > Why would you need to take it down? All you need to do is restart |
13 |
> > Apache after the update. |
14 |
> > |
15 |
> |
16 |
> I have to test, like, 200 websites to make sure they still work. |
17 |
> Something /always/ breaks. |
18 |
> |
19 |
> Apache was just an example. PHP is the same way: functions get |
20 |
> removed, renamed, or just subtly changed. I can't replace Dovecot |
21 |
> with users logged in. I can't upgrade/restart postgresql while |
22 |
> clients are hitting it. If I'm working remotely, I don't want to |
23 |
> update openvpn, iptables, or even openssh. There's a long list of |
24 |
> packages that I just ain't gonna mess with during the day. |
25 |
|
26 |
|
27 |
You have a production machine delivering valuable services to multiple |
28 |
users. |
29 |
|
30 |
Therefore you must only update *anything* on it during planned |
31 |
maintenance slots. If paying customers are involved then preferably |
32 |
with a second redundant parallel machine to take over the load during |
33 |
that slot. You don't have much of an option about this in the real |
34 |
world, think of it as a constraint that you must simply deal with. |
35 |
|
36 |
Or think about it another way, if the machine was running RHEL, you |
37 |
wouldn't just blindly run yum update in the middle of the working day |
38 |
and expect it to all be just fine. |
39 |
|
40 |
|
41 |
-- |
42 |
Alan McKinnnon |
43 |
alan.mckinnon@×××××.com |