Re: Constant up dates, repeated reboots

Hi,

On 15 July 2014 10:52, Worik Stanton <[email protected]> wrote:

> My dissatisfaction with updates was on my VPS which I would like to
> never reboot.  There I do not take that attitude it is there I am
> careful, and there where I should *not* have done do-upgrade without
> taking much more care.
>

Ahh, I thought this was on your laptop.

The server distribution tends to be a little less user friendly than the
desktop distribution - with good reason, it's aimed at a different segment
of the user base. Upgrading software on servers is *hard*. The 'devops'
scene is full of people trying to solve exactly that problem. The best
solution I've seen is:

Don't even try and upgrade the software. Instead, re-deploy your webapps
(or whatever it is you're running there) on top of the new distro on a new
server (or virtual instance or whatever). Test it. If it passes all your
tests, make it 'live' (reconfigure DNS records etc.), and then tear down
the old server. The advantage of this strategy is that if it all breaks,
you can gracefully back out, and your users don't even know that you tried
to do an upgrade.

That's a lot of work, but it's the best way I've seen...


> I still think the balance is wrong in the update system.  For example
> (and without deep thought) I would like to be able to have a choice in
> the update system of marking packages as "do not update".  For example I
> would like updates to my compiler tool-chain but I do not care about my
> PDF reader.  If it breaks I could check if there are updates for it
> available.
>

This is one of those problems that seems simple, but is actually really
really hard. If you update the compiler toolchain, you'll probably be
pulling in new libstdc++, which might contain ABI breakages over the old
library. Now you need to upgrade software that links to that library
(that's a long list).... The list of edge cases like this is really long.
As Robin pointed out, it's technically possible to do this by holding a
package, but unless you're *very* careful you can end up with a totally
broken system very easily.


>
> As for my VPS I am considering taking my crucial software out of package
> management and using source tarballs (like I did back in the day) so I
> do not get surprised like I did.  I think I would only need  four at most.
>

That's a valid strategy, but not one I'd personally recommend. Keeping up
with security updates is a huge task, even for four packages. The Ubuntu &
Debian communities do a huge amount of work to make sure that security
fixes are shipped as quickly as possible - the heartbleed fix is a great
example, where we managed to get all the archives updated with new packages
within 24 hours. Would you be able to track down all the packages that link
to libssl (including... ugh... statically linking to it), and re-build and
re-deploy them in that time? I don't think I could...


>
> I would like it if I had been notified that Apache was going from 2.2 to
> 2.4 and the configuration files were changing, and on reflection I may
> have been, but in all the noise of 100s of packages I missed it.  I have
> been trying to think how this could have been done better by Cannonical,
> and I have some ideas, but I am not in control of that.  I should be in
> control of my own important software - handing over control to
> Cannonical is lazy.  Problem is I am very busy (avoiding work by typing
> here....)
>
>
I should note here that it's not really Canonical, but rather Canonical +
Ubuntu Developers + Debian developers + the wider community. FWIW though, I
agree that it'd be great if there was a nicer way to see what changed
during an upgrade.

However, the documentation exists:

https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes

contains:

Ubuntu 14.04 LTS includes Apache 2.4; this is a major version upgrade from
Apache 2.2 in Ubuntu 12.04 LTS and users should take care to read the upgrade
notes <http://sources.debian.net/src/apache2/2.4.9-1/debian/apache2.NEWS>
included in the packaging and the upstream upgrading
<http://httpd.apache.org/docs/2.4/upgrading.html> documentation.

So the documentation exists, but it's perhaps not very discoverable.


> Still loving the imperfect Ubuntu system.  What is ever perfect?
>

Beer is pretty damn close to perfect, if you ask me. You can drink it, and
you can use it to put out fires. Also, it kills slugs. Actually, it kills
most things if you have enough of it.

Cheers!
-- 
Thomi Richards

_______________________________________________
DunLUG mailing list
[email protected]
http://lists.ethernal.org/listinfo/dunlug
DunLUG Wiki - http://dunlug.kallisti.net.nz/