Re: [gentoo-user] another old box to update

[Stefan G. Weichinger]

On 08.01.2015 00:02, Alan McKinnon wrote:
> On 07/01/2015 22:30, Stefan G. Weichinger wrote:
>> Am 07.01.2015 um 20:06 schrieb Tomas Mozes:
>>
>>> Strange, I only have successful stories with upgrading old gentoo
>>> machines. If you have a machine which you update regularly then you know
>>> all the issues during the time and so upgrading "per partes" leads to no
>>> surprises but the same challenges you've handled before. But yes, it
>>> takes time.
>>>
>>> Moreover, if you use configuration management like Ansible, you can even
>>> automatically merge changes when applications ship new configuration.
>>
>> Thanks for that posting, it reminds me of some bigger issue I wanted to
>> discuss here for quite a while now.
>>
>> Over the years I am now responsible for dozens of servers and VMs
>> running gentoo linux ... and I wonder how to efficiently keep track of them.
>>
>> I learned my first steps with puppet and use it in a basic setup for my
>> own machines in my LAN. It seems to work better for many identical
>> servers, let's say in a hosting environment.
>>
>> The servers at my customers are somehow similar but not identical:
>>
>> different setups for services ... different update-cycles (which have to
>> be synchronized and shortened as we have seen in this thread!) ...
>>
>> I look for a way of tracking all these systems:
>>
>> a) central database/repo with all the systems and how to access them:
>>
>> 	* unique system id
>> 	* what IP, port, ssh-key, etc etc
>>
>> I use git for local tracking of /etc on most of my systems in the last
>> years, but I did never really come up with a clever way how to
>> centralize dozens of separate git-repos ... one repo per server pushed
>> to one central git-home on of my inhouse servers?
>>
>> b) in addition tracking of let's say "rules" or "services":
>>
>> 	* which server runs e.g. apache? So if there is a new security warning
>> out there for apache ... ask system "which servers/customers would need
>> that update?"
>>
>> etc etc
>>
>> c) when was my last access to that server? Have I looked into it lately?
>>
>> (or more business-oriented:)
>> Do I even have to / does the customer pay for that?)
>> This should lead to some SLA-kind-of-thing, yes ... a bit off-topic for now.
>>
>> -
>>
>> Puppet is more oriented to push configs out to systems.
>>
>> Maybe a combination would apply ... puppet for building the basement,
>> having stuff generalized (this path, that password/ssh-key ....)
>>
>> and some other components to track what has been done over time.
>>
>> I run OTRS  ( http://en.wikipedia.org/wiki/OTRS ) for my daily work and
>> looked into their module "ITSM" (
>> https://www.otrs.com/homepage/software/otrsitsm-features/ ) lately ...
>> it allows to create "configuration items" (think: ITIL) etc, so far I
>> think this is a bit of overkill and not really fitting the size of my
>> business.
>>
>> I'd love to keep it simple and CLI-oriented:
>>
>> Gentoo allows to define (nearly?) everything via text-files, combined
>> with the cleverness of git (and maybe puppet) this should give me a way of
>>
>> a) easily deploy new systems with configs according to some standards:
>> 	I want these packages/users/paths/files ...
>>
>> b) track these systems: what boxes am I responsible for, what is out
>> there and failing? ;-) (not talking monitoring here ... just what are my
>> active systems out there)
>>
>> from there I should slowly get into defining new contracts with my
>> clients including regular checks each 3 or 6 months ... what has to be
>> done, are there any bigger updates to do (think udev, baselayout ...)
>> and tell them if is possible to update the box within a few hours in
>> parallel to normal work or if we need a bigger maintenance window.
>>
>> ---
>>
>> I am sure there are many other gentoo-users out there with similar
>> challenges to face. And I am looking forward to your thoughts,
>> experiences and recommendations!
>
>
> In my opinion, ansible almost always beats puppet.
>
> Puppet is a) complex b) built to be able to deal with vast enterprise
> setups and c) has a definition language I never could wrap my brains
> around. It always felt to me like puppet was never a good fit for my needs.
>
> Then ansible hit the scene. Now ansible is designed to do what sysadmins
> do anyway, to do it in mostly the same way, and to do it in an automated
> fashion. It fits nicely into my brain and I can read a playbook at a
> glance to know what it does.
>
> Ansible deploys stuff and makes it like how you want it to be. It is
> equally good at managing 1000 identical machines as 100 mostly the same
> ones, or 20 totally different ones. How it manages this miracle is not
> easy to explain, so I urge you to give it a test drive. Fool around with
> a bunch of VMs to get a feel of how it works. A tip: keep it simple, and
> use roles everywhere.
>
> Ansible works nicely with other tools like vagrant and docker which
> build and deploy your base images. Once you have a base machine with
> sshd running and an administrative login account, ansible takes over an
> manages the rest. It works really well.

played around with ansible today and managed to get this working:

http://blog.jameskyle.org/2014/08/automated-stage3-gentoo-install-using-ansible/

I even forked his repo and added a load of features to my newly built
gentoo-systems (systemd, git, german locale, chrony ...). Nice.

I still have to come up with a proper directory tree ... the docs at

http://docs.ansible.com/playbooks_best_practices.html

show a tree that seems a bit huge for my needs.

One of my next goals: get all my local hosts into it and see how to
manage them.


----

aside from that back to the original topic of this thread:

The "old box" booted instantly today ... cool.

Stefan