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 < koen.vanda...@rwo.vlaanderen.be> 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:* archesproject@googlegroups.com <archesproject@googlegroups.com> > namens Adam Cox <mr.adam...@gmail.com> > *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 archesproject@googlegroups.com. To unsubscribe, > send email to archesproject+unsubscr...@googlegroups.com. 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 archesproject+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > > -- > -- To post, send email to archesproject@googlegroups.com. To unsubscribe, > send email to archesproject+unsubscr...@googlegroups.com. 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 archesproject+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- -- To post, send email to archesproject@googlegroups.com. To unsubscribe, send email to archesproject+unsubscr...@googlegroups.com. 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 archesproject+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
