That's some very nice advice Koen!

Director of Web Development - Farallon Geographics, Inc. - 971.227.3173

On Tue, Sep 22, 2015 at 2:57 AM, Van Daele, Koen <
[email protected]> wrote:

> Hi Adam,
>
> A few tips:
>
>  * Stick with an Ubuntu LTS until the next one comes along.
>  * Most of the updates that happen during an Ubuntu LTS cycle are
> bug-fixes and security fixes. I have never seen them deliver backwards
> incompatible features or fixes. So, running apt-get update and apt-get
> upgrade is fine. Think we generally use aptitude instead of apt-get but I
> forget why that is at the moment.
>  * As long as you stay within a certain Ubuntu release, your dependencies
> (eg. python and postgres) will stay at the same major versions and only
> receive fixes. Going to a newer Ubuntu release runs the risk of getting you
> a newer Python version. I believe for Ubuntu 16.04 they want to make Python
> 3.5 the default Python. Last time I checked Arches wasn't py3 compatible
> (might have changed).
>  * I would not run apt-get dist-upgrade on a production server. And
> certainly not to go from 14.04 to eg. 14.10. I have done this for desktops,
> but never for servers. Something always seems to break somewhere.
>  * ​When there's a new LTS and we're satisfied it's stable (after a few
> months), we basically wipe the server and reinstall from scratch.
> To make this an easy task (and because we load-balance), we script
> everything. We use fabric (http://www.fabfile.org/) for this, but you
> could do the same with something like Ansible, Chef, Puppet, ... Our
> fabfile has a set of tasks that update stuff, configure apache, build
> packages and configuration files and deploy the results. So, once we have
> wiped a server it's generally a matter of reinstalling Ubuntu, running fab
> <env> update_ubuntu and fab <env> deploy. We keeps these fab files in
> version control as well and they server as excellent documentation on how
> to set up a certain application.
>  * Bear in mind that scripting makes it easy to reinstall, but it also
> makes it easy to blow things to bits. We have a development, test and
> production environment. Needless to say, we always test the scripts before
> executing them in production.
>  * On more thing, we have quite a large datacenter at our disposal, with a
> lot of virtualised servers. We never run database servers on webservers.
> Upgrading a database is always a tricky thing and might require dumping
> your entire database and reload (generally when upgrading major postgres
> versions). Same thing for elasticsearch, we also run those as separate
> clusters. Setting up everything on different machine is a lot more work,
> but it does offer nice possibilities when scheduling maintenance.
>
> Let me know if you have any further questions.
>
> Cheers,
> Koen
>
>
>
> ------------------------------
> *Van:* [email protected] <[email protected]>
> namens Adam Cox <[email protected]>
> *Verzonden:* maandag 21 september 2015 16:59
> *Aan:* Arches Project
> *Onderwerp:* [Arches] help with long-term Ubuntu 14.04 server maintenance?
>
> Hello all, I'm wondering if anyone could help suggest the best way to
> handle a server that is only being used for arches, when it comes to
> package updates/upgrades?
>
> I only know the very basics of using apt-get update and apt-get upgrade,
> and apt-get dist-upgrade.  I don't want any of the Arches dependencies to
> be upgraded, but I do need to be able to get current security updates and
> make sure things keep running smoothly.
>
> I'll look into these suggestions
> http://askubuntu.com/questions/194/how-can-i-install-just-security-updates-from-the-command-line,
> but would be interested to know if anyone has experience with maintaining a
> server over a long period of time.
>
> Adam
>
> --
> -- To post, send email to [email protected]. To unsubscribe,
> send email to [email protected]. For more
> information, visit https://groups.google.com/d/forum/archesproject?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Arches Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>
> --
> -- To post, send email to [email protected]. To unsubscribe,
> send email to [email protected]. For more
> information, visit https://groups.google.com/d/forum/archesproject?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Arches Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- To post, send email to [email protected]. To unsubscribe, send 
email to [email protected]. For more information, 
visit https://groups.google.com/d/forum/archesproject?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Arches Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to