Haines Brown <hai...@histomat.net> wrote: > On Thu, Sep 18, 2014 at 07:50:10PM +0200, Sven Hartge wrote: >> softwatt <softw...@gmx.com> wrote:
>> This leads to a newish trend in systems administration, facilitated >> by widespread use of virtualisation or container techniques: never >> upgrade a system to a new release, just "spawn" a new and fresh >> installed one and copy your data/application/whatever over. >> >> Combined with tools like Puppet/Chef/Ansible this provides you with a >> reproducible and always "factory fresh" operating system without the >> cobwebs of years of past upgrades in the basement. >> >> But I digress. > Sven, please digress. Just what do you mean by "spawn"? I normally > reinstall the operating system on a refreshed HD with a Debian > Installer each time there is an upgrade. Then I copy over my custom > directories (such as /usr/local/share) and copy the configurations in > /home/ and /etc/. How does this differ from your "spawn"? "spawn" was meant as a kind of wildcard expression for "create a fresh system with the tool of your choice". One could clone a pre-made VM and then use Puppet/Chef/... to customize it. Or use a pre-seeded installer or something like FAI to install a fresh system from scratch and then use Puppet/etc. Or utilize docker.io to create a lightweight container with the application overlay of your choice and needs. Or even, as you do, reinstall from scratch on real hardware and customize this by copying over needed configuration and data. I personally right now like the "pre-seeded installer + puppet" way to create new virtual systems on VMware vSphere. I tried the built-in clone feature of vSphere but found that this only really works great with Windows-based VMs. Linux-VMs need to many manual adjustments after cloning that I am as fast if I just create a new VM and let the pre-seeded installer do its thing. And by doing so I can be sure there are no hidden UUIDs (like dbus or systemd create) left over. Old VMs are still upgraded to a new release using the classic "apt-get update; apt-get dist-upgrade" way. Because every VM here is only dedicated to one and only one job, each VM has only minimal changes to its default configuration, allowing easy and swift dist-upgrades. This all are of course procedures grown over time. If I were to start over right now I would me more strict in the direction of creating and managing Debian systems, maybe automate way more using puppet than right now or even creating a automated local MaaS-cloud using OpenStack. My private systems on the other hand are from the stone age. This system I am typing this mail on was installed back in 2000 with Slink, promptly updated to Frozen Unstable Potato and kept at Unstable ever since (leading to fun bugs like #631245), upgrading it at least once a day, sometimes even more often. (Yes, I like to dance on the bleeding edge.) Of course it does use modern hardware and not the 486DX4/100 it was installed on back then. It is kind of a sport and challenge for me to never reinstall my private systems, always migrate the data either using rsync or if ever possible pvmove for LVM. But because of this I already now any kinks and problems a new release may have and are thus able to upgrade my production servers without big problems, because odds are, I already had those problems on my own systems during the development phase of the next release. Hm. Sorry, I am rambling again. What was the topic again? :) Grüße, Sven. -- Sigmentation fault. Core dumped. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5b0hvqu76...@mids.svenhartge.de
