| 1 |
On Monday 02 Jan 2012 10:06:39 Alan McKinnon wrote: |
| 2 |
> On Sun, 01 Jan 2012 19:24:35 -0500 |
| 3 |
> |
| 4 |
> Michael Orlitzky <michael@××××××××.com> wrote: |
| 5 |
> > On 01/01/2012 07:09 PM, Neil Bothwick wrote: |
| 6 |
> > > On Sun, 01 Jan 2012 18:07:45 -0500, Michael Orlitzky wrote: |
| 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 |
> > I have to test, like, 200 websites to make sure they still work. |
| 16 |
> > Something /always/ breaks. |
| 17 |
> > |
| 18 |
> > Apache was just an example. PHP is the same way: functions get |
| 19 |
> > removed, renamed, or just subtly changed. I can't replace Dovecot |
| 20 |
> > with users logged in. I can't upgrade/restart postgresql while |
| 21 |
> > clients are hitting it. If I'm working remotely, I don't want to |
| 22 |
> > update openvpn, iptables, or even openssh. There's a long list of |
| 23 |
> > packages that I just ain't gonna mess with during the day. |
| 24 |
> |
| 25 |
> You have a production machine delivering valuable services to multiple |
| 26 |
> users. |
| 27 |
> |
| 28 |
> Therefore you must only update *anything* on it during planned |
| 29 |
> maintenance slots. If paying customers are involved then preferably |
| 30 |
> with a second redundant parallel machine to take over the load during |
| 31 |
> that slot. You don't have much of an option about this in the real |
| 32 |
> world, think of it as a constraint that you must simply deal with. |
| 33 |
> |
| 34 |
> Or think about it another way, if the machine was running RHEL, you |
| 35 |
> wouldn't just blindly run yum update in the middle of the working day |
| 36 |
> and expect it to all be just fine. |
| 37 |
|
| 38 |
+1 |
| 39 |
|
| 40 |
Even on binary distros I would be apprehensive to update/upgrade a production |
| 41 |
machine, unless I have run the updates on the test box first. Even so, because |
| 42 |
I do not have the luxury of identical hardware some times the odd thing may |
| 43 |
break, but it is a very rare occurrence. With everything running on VMs these |
| 44 |
days (although not yet my case) this is becoming less of a problem I would |
| 45 |
think. |
| 46 |
-- |
| 47 |
Regards, |
| 48 |
Mick |
Archives