One thing that I really think is neat with Ansible is that when you need functionality that are not part of the Ansible core (let’s say you need to integrate Ansible with bigip F5 load balancer) you can just turn to Python (or any other language for that matter) to write your own modules that you later can use in the regular playbooks. This is a really neat functionality, you are not tied down to the dsl (such as in the case of Puppet). DSL:s are in my experience very limited and stupid; you would rather want turn to a real general purpose programming language. ...

So what makes a good and helpful command line application? I think these three point are important: easy to use helpful play well with others Bash is commonly used to write command line apps, but I can never shrug of the feeling of shame of writing a bash script with more than 30 lines. That’s why I’m shaking things up here and showing how to use ruby instead. I’ll be using the optparse gem so you need to do a gem install optparse before trying out the shown examples. ...

First let’s set up our build rpm environment by installing the following: [bob@vagrant-centos65 ~]$ sudo yum install -y rpmdevtools rpmlint Then we’ll set up the folder structure with the rpmdev-setuptree command. It will create tbe rpmbuild folder and it’s subfolders as shown below. [bob@vagrant-centos65 ~]$ rpmdev-setuptree [bob@vagrant-centos65 ~]$ tree rpmbuild/ rpmbuild/ ├── BUILD ├── RPMS ├── SOURCES ├── SPECS └── SRPMS In the SPEC folder we create elasticsearch.spec, and in the SOURCES folder we download the tar-file from elasticsearch. ...

Welcome to the first part article on how to build rpm packages. Here I will walk you through how to build a rpm package and how to work with the tools you will need. Let me just first start off with saying that I don’t consider myself an expert at rpm packaging but blogging about a topic forces you to graps the subject you are writing about better. With that being said this first part will cover the bascis like installing rpm tools, the structure of a spec file, macros and lastly a simple rpm build. In part two my ambition is to take the things I wrote about here to package a real world application into an rpm. ...

One thing with Ruby I don’t quite like (and many with me) are the Ruby gems. The one thing thats great with gems is that it’s almost as with CPAN, if you have a problem - there’s a gem for that! But I don’t like the idea of installing libraries system-wide. If installed with sudo it’s a security risk. And my belief is that libraries are supposed to be used by demand when an application needs them. For example Java + maven and Node.js and NPM is a good example of those getting this right. Let’s say you want to share a ruby project, the problem is that person must have the same set of gems installed to be able to run your program, and maybe he’s installing a newer version of that gem that you was testing on. Not good! Fortunately we have Bundler to help us keep track of gems and it’s dependencies that solves this problem. ...

Not long ago Kibana 4 was released and I think it’s a major improvement in relation to the previos version of Kibana. Some changes worth mentioning is that Kibana 4 now runs a node js web server, Express, while Kibana3 was just plain js files that you had to serve in a httpd or nginx. This really is a great improvement! In kibana3 elasticsearch web port 9200 had to be reachable by the client, not an ideal solution as this is something you want to limit as it enables anyone to just do a curl -XDELETE. The workaround was to make a lot of proxy rewrites in the webserver serving kibana - Workable but felt more of a hack than a good solution. Running kibana server side reduces that hassle. ...