hubertf's NetBSD Blog
Send interesting links to hubert at feyrer dot de!
 
[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: , ]


Disclaimer: All opinion expressed here is purely my own. No responsibility is taken for anything.

Access count: 35108576
Copyright (c) Hubert Feyrer