FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu User

 
 
LinkBack Thread Tools
 
Old 12-08-2010, 11:46 AM
Nils Kassube
 
Default updates on production machines

Matt Johnson wrote:
> I've been following the forums for a little while and there seem to
> be quite a few 'show-stoppers' that arise when folks update their
> machines (remaining in the same release).

> Are these issues pretty rare?

I would think these issues are quite rare. On this list you only see
those who stunbled upon problems. But you don't see all the others who
had no problems. They have better things to do than tell everybody that
the update worked.

It is similar to a hotline that helps people with alcohol problems. If
you listen to those calls you might think that everybody is an
alcoholic. In reality there are many people without alcohol problems but
they won't call that hotline.

Now I don't want to say that there are no issues, but they are surely
not as frequent as it seems to be from reading this list.

> How do people protect against issues
> caused by updating packages?

In the last years there was only one security problem I remember which
demanded rapid action. Everything else could wait a few hours. Therefore
I usually only install updates when I have time to troubleshoot possible
issues. OTOH, I'm running Kubuntu on my private machines at home, not on
machines which are used for business work. So this may not be an option
for you.


Nils

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 12-08-2010, 01:37 PM
Tom H
 
Default updates on production machines

On Wed, Dec 8, 2010 at 6:51 AM, Matt Johnson <johnsonmlw@yahoo.com> wrote:
>
> I've been following the forums for a little while and there seem to be quite a
> few 'show-stoppers' that arise when folks update their machines (remaining in
> the same release). I think I've been blasť about applying updates nightly.
> Reading the issues raised, I'm (perhaps appropriately) anxious about applying
> any updates on production machines I've got here. I've probably got the wrong
> end of the stick.
>
> Are these issues pretty rare? How do people protect against issues caused by
> updating packages?
>
> * Full back up / restore (in which case I'd modify my behaviour to only apply
> updates when I could protect the time required to perform a full restore)
>
> * Some sort of dry run or easy way to roll back?

At the very least, test in a VM before deploying.

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 12-08-2010, 02:19 PM
"Cybe R. Wizard"
 
Default updates on production machines

On Wed, 8 Dec 2010 09:37:45 -0500
Tom H <tomh0665@gmail.com> wrote:

> On Wed, Dec 8, 2010 at 6:51 AM, Matt Johnson <johnsonmlw@yahoo.com>
> wrote:
> >
> > I've been following the forums for a little while and there seem to
> > be quite a few 'show-stoppers' that arise when folks update their
> > machines (remaining in the same release). I think I've been blasť
> > about applying updates nightly. Reading the issues raised, I'm
> > (perhaps appropriately) anxious about applying any updates on
> > production machines I've got here. I've probably got the wrong end
> > of the stick.
> >
> > Are these issues pretty rare? How do people protect against issues
> > caused by updating packages?
> >
> > * Full back up / restore (in which case I'd modify my behaviour to
> > only apply updates when I could protect the time required to
> > perform a full restore)
> >
> > * Some sort of dry run or easy way to roll back?
>
> At the very least, test in a VM before deploying.
>
That doesn't always mean anything as the VM will likely have different
'hardware' than the real machine. For instance, I can't test/use the
nvidia software in a VM because the default virtual hardware isn't
nvidia.

Cybe R. Wizard
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
Ed Howdershelt (Author)

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 12-08-2010, 02:30 PM
Tom H
 
Default updates on production machines

On Wed, Dec 8, 2010 at 10:19 AM, Cybe R. Wizard
<cyber_wizard@mindspring.com> wrote:
> On Wed, 8 Dec 2010 09:37:45 -0500
> Tom H <tomh0665@gmail.com> wrote:
>
>> On Wed, Dec 8, 2010 at 6:51 AM, Matt Johnson <johnsonmlw@yahoo.com>
>> wrote:
>> >
>> > I've been following the forums for a little while and there seem to
>> > be quite a few 'show-stoppers' that arise when folks update their
>> > machines (remaining in the same release). I think I've been blasť
>> > about applying updates nightly. Reading the issues raised, I'm
>> > (perhaps appropriately) anxious about applying any updates on
>> > production machines I've got here. I've probably got the wrong end
>> > of the stick.
>> >
>> > Are these issues pretty rare? How do people protect against issues
>> > caused by updating packages?
>> >
>> > * Full back up / restore (in which case I'd modify my behaviour to
>> > only apply updates when I could protect the time required to
>> > perform a full restore)
>> >
>> > * Some sort of dry run or easy way to roll back?
>>
>> At the very least, test in a VM before deploying.
>>
> That doesn't always mean anything as the VM will likely have different
> 'hardware' than the real machine. *For instance, I can't test/use the
> nvidia software in a VM because the default virtual hardware isn't
> nvidia.

That's why I said "at the very least".

For X-less servers, VMs are good enough - no need to test amd/nvidia
or compositing.

Anyway, in our environment, updates are tested on dedicated test
boxes, rolled out to dev then uat then prod - and it's not necessarily
fool-proof.

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 12-08-2010, 02:41 PM
Kent Borg
 
Default updates on production machines

Tom H wrote:
> At the very least, test in a VM before deploying.

Funny you should say that...

A few weeks ago I had my kvm VMs all go bad after a regular update.
None of them would launch. I had to Google around for awhile before I
discovered I needed to add a image file format specification to the XML
files that defined the VMs, and then I needed to Google around more to
find out the exact syntax of the change.

Scary!


The real solution is to have a complete testbed that tries hard to
completely duplicate your production systems--except not dealing with
real transactions, and run all updates through there first. But one
doesn't always get so elaborate, and even when one does, one should
still have a way to roll back.

It got me thinking and I came up with this geeky two-part solution:

1. Use git to keep track of changes in /etc.

2. Before doing an update that worries me, make a snapshot of the
/var/cache/apt/archives directory. If I have the old .deb files I
should be able to reinstall them. I might have to hack around with dpkg
for a few minutes, but I should be able to make it work again.

To do the snapshot I use hardlinks:

# cd /var/cache/apt
# mkdir archives-20101208
# cd archives-20101208
# ln ../archives/*.deb .

The files will only be stored once but there will be two directory
entries point to them. (The day all the directory entries point to a
given file are deleted, the file data itself will finally be deleted.)

One thing to worry about is whether the cache might be cleaned before
you make your snapshot. The apt-get man page says that "apt-get clean"
and "apt-get autoclean" will delete files, as will dselect (not
installed on my computer at the moment). I don't know that the GUIs
don't also mess with the cache. Anything labeled "cache" should not be
relied upon without great thought. To be real thorough one should
probably snapshot .deb files after each backup, when there has been
little chance for cache entries to have been lost.

Doing snapshots with something like LVM is another possibility. Once
btrfs has good userland support, it would be very useful for these things.


-kb


--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 

Thread Tools




All times are GMT. The time now is 05:59 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org