[20130202]
|
Managing NetBSD with Ansible, First Steps (Updated)
Background: Plan, Build, Run
I've mused a lot about the transition from
system planning over system setup to system operation recently.
Different kinds of databases may be involved, that serve
different purposes: On the planning end, topics like
version management, license management, life cycle management
and enterprise architecture management come into play.
When this transits into operation, other aspects like
system and network configuration get more important,
while others fade away.
At the end, someone or something has
to make adjustments to systems in order to get them
into service, and keep them there.
This is either done with a lot of manual labor
to keep documentation (CMDB, or whatever serves)
and the systems in sync, or - more likely - documentation
will grow stale quickly and rot away.
With a growing set of hosts, the latter is not an option,
and transparency becomes increasingly important.
This is where system "orchestration" tools like cfengine,
puppet, chef and ansible come into play.
You write a system definition there, and the machine is
configured according to this definition automatically:
Configuration files can be adjusted, accounts created,
software packages installed, services enabled, etc.
System Orchestration Alternatives
Looking at the state of affairs, many people seem to be
fond of Puppet these days. This comes with a pretty long list
of dependencies (and thus complexity to maintain), and
configuration files have to be written in Ruby (which I don't know).
So I chose Ansible as alternative to investigate - it comes with very little overhead
(no separate daemon on neither the central machine nor any
of the configured systems, just using SSH) and its own
"Playbook" language seems easy enough to start with, yet
complete enough to be used in large environments (as the
list of customers listed on the homepage shows).
Packaging Ansible, First Try
My first try to get going with Ansible on NetBSD was to use
the version 0.9 archive available, instead of using a GIT checkout.
The included (GNU) Makefile
tries to determine the version from the git checkout.
Which the archive is not. Using information not available in the archive either.
Checking if the source code was checked out from GIT by looking
if there's a git binary available is not the best idea here,
and so I dropped the ball, cursing the fact that not all
the world is Linux. Sort of.
Looking briefly at a fresh git checkout that this worked there,
but as NetBSD's pkgsrc doesn't support git checkouts (yet, as far
as I know?), I moved back to the 0.9 archive.
Packaging Ansible, Second Try
Leaving out the git-based version games, the next fun was
to get the Python setup script to install the files in the right
place. Having missed much pkgsrc development recently, and not being into
Python either way, this proved unneccessary - Joerg Sonnenberg
pointed me at existing pkgsrc infrastructure for Python
programs, and with them the program was packaged successfully
in no time.
For now, the package is available
on my website,
I'll look into review and import into pkgsrc next.
Ansible on NetBSD - What Works, And What Needs More Work
Modules tested successfully on NetBSD 6:
- ping
- command
- copy
- facter
- group add/delete
- mysql_db add/delete
- user add/delete (without system=true)
Modules tested unsuccessfully on NetBSD 6:
- user add/delete (with system=true)
- service (needs work)
The git version (and the upcoming 1.0 release) also include
a "pkgin" module that can be used to manage packages.
Unfortunately the git-version of the module cannot easily be used
with the 0.9 version, so this has to wait.
Examples: Ansible On NetBSD
Here's an example session with basic operation:
% cat work/ansible/hosts.HF
#127.0.0.1 ansible_python_interpreter=/usr/pkg/bin/python2.7
127.0.0.1
% ansible -i work/ansible/hosts.HF -s all -m ping
127.0.0.1 | success >> {
"changed": false,
"ping": "pong"
}
Here's an example showing creation and deletion of a user account:
% finger testuser
finger: testuser: no such user
% ansible -i work/ansible/hosts.HF -s all -m user -a "name=testuser state=present"
127.0.0.1 | success >> {
"changed": true,
"comment": "",
"createhome": true,
"group": 100,
"home": "/home/testuser",
"name": "testuser",
"shell": "/bin/sh",
"state": "present",
"system": false,
"uid": 1005
}
% finger testuser
Login: testuser Name:
Directory: /home/testuser Shell: /bin/sh
Never logged in.
No Mail.
No Plan.
% ansible -i work/ansible/hosts.HF -s all -m user -a "name=testuser state=absent"
127.0.0.1 | success >> {
"changed": true,
"force": false,
"name": "testuser",
"remove": false,
"state": "absent"
}
% finger testuser
finger: testuser: no such user
So much for a quick start into Ansible. Do you use NetBSD in a large-scale
environment that went beyond manual systemconfiguration?
Write a blog entry or an email to the NetBSD lists,
and let us know!
Update:
A
spanish translation of this article
is available now, thanks to
Maria Ramos from
Webhostinghub.com.
[Tags: ansible, pkgsrc]
|