How to set up OTRS on Ubuntu

First, little info about OTRS taken from Wikipedia:
OTRS, an initialism for Open-source Ticket Request System, is a free and open-source trouble ticket system software package that a company, organization, or other entity can use to assign tickets to incoming queries and track further communications about them. It is a means of managing incoming inquiries, complaints, support requests, defect reports, and other communications. http://en.wikipedia.org/wiki/OTRS

So my interest in OTRS started couple of months ago. We had been using a very outdated ticketing system in my workplace for years and were thinking of changing to a better one. So as I was working during the summer holidays, I had time to look for an alternative. Found OTRS, set it up on my test server, tested for a few weeks and then migrated it to our production environment. Now we’ve been using OTRS for a month. Works like a charm. Usually if something is not working right in OTRS, it’s only a misconfiguration and easily fixed with the web GUI. Now we were also able to replace an old Windows server with an Ubuntu server. Slowly migrating from Windows to Linux… 😉

Puppet with Windows clients

I was asked if I had configured Windows clients for a Puppet server running on Linux. I have, and I write everything down whenever I make some new configurations. So here’s my notes on configuring Windows Puppet clients for Ubuntu Puppet server. Don’t forget to check the official guides.

Fabfile for Puppet installations

I will try to automate everything I can, so even when configuring one automation system (Puppet), I’m using another one (Fabric) to do it. I’m using this fabfile always when I need to install another Puppet agent or if I need to install a Puppet server. Tested only with Ubuntu.

Test environment:
Ubuntu 12.10
Puppet 2.7.18
Fabric 1.4.2

Nagios email notifications & Puppet

I’ve been writing a bit about my Nagios configuration lately, but there was still at least one important part missing from my Nagios configuration: Email notifications. With email notifications configured there will be an email alert every time one of my nagios hosts or it’s services reaches warning or critical state.

Postfix will be used to send emails and I will include a Puppet module for the configuration as well.

Nagios – NRPE and Windows Hosts

I was using check_nt on my Windows monitoring setup but check_nt is actually quite outdated and limited as Mr Medin the creator of NSClient++ told me. He helpfully advised that I could use check_nrpe instead of check_nt. I’ve done some tests now and got the nrpe working. Also updated my nagios3 and nscp Puppet modules to include nrpe configurations.

Here’s and example of a service that monitors physical memory usage on windows host:

define service {
  use                  generic-service
  check_command        check_nrpe!CheckMEM!MaxWarn=80% MaxCrit=90% ShowAll type=physical
  service_description  Memory usage
  host_name            remote-windows-host
}

Puppet: Nagios3 module

On my previous post I told how I got Windows monitoring working with Nagios. The post included a puppet module for the NSClient, which Nagios uses to communicate with Windows. The most important module in that setup is obviously the actual Nagios3 module. Which manages the Nagios server and all the hosts. I’ve been working on it for couple of days now and although it’s not complete, it works and is already available on our github.

You can find the module here:
https://github.com/awaseroot/awaseroot/blob/master/puppet/modules/nagios3/manifests/init.pp

Monitoring Windows with Nagios

I’m working in a Windows environment at my current job so I will be posting a little bit about Windows related topics in the future but the main focus will of course still stay in Linux. Setting up Nagios on Linux server to monitor Windows machines felt like a good way to introduce some Linux functionality to our Windows network.

Windows monitoring was fairly simple to set up but I did run into some small issues. All the guides and tutorials that I found were so outdated that they weren’t really much of a help. This guide is for the latest Nagios and nsclient versions (at least for now). Puppet module for the NSClient at the end of this post.

How I use Puppet at work

These are my notes for a presentation at my university on how I am using Puppet at work.

Puppet module for /etc/fstab mounts

Puppet has a native module for handling fstab mounts. Here is an example:

class data_mounted {
    mount { "/data":
        device  => "/dev/sdb1",
        fstype  => "ext4",
	ensure  => "mounted",
	options => "defaults",
        atboot  => "true",
    }
}

The “device” directive can take anything what you’d normally put in the first column of /etc/fstab, i.e. if you are mounting by label (which is probably the best way to mount partitions) then instead of “/dev/sdb1” call for “LABEL=data”, where ls -l /dev/disk/by-label/data should point to the actual [and existing] partition, which in my case is /dev/sdb1.

The “fstype” is the actual type of the partition, if you are not sure of the type you can check it with df -T. You can mount linux ext partitions, nfs, samba, 9p etc.

For more on fstab file system types and mount options check http://linux.die.net/man/8/mount

Improved Puppet LAMP module

I have done slight improvements to my old LAMP module. The new one can be found from our Github here. And the blog post about the old one is here.

The module has been tested on Ubuntu 12.04 and Centos 6.2. It might work on Redhat and Debian as well but I haven’t tested those yet. It installs and configures Apache, PHP and MySQL. At it’s present state it works quite fine, but I might still keep improving it.

New Script – Install Puppet on CentOS

As I’m now using Puppet also with CentOS I’d like to share the script I use to install Puppet on my CentOS VM. The script installs Ruby as well since you need it to run Puppet.

At the moment I’ve been using Puppet on CentOS without a puppetmaster so it’s properly tested only as serverless Puppet, but there’s shouldn’t be any problems even if you’re using a puppetmaster. I’m actually combining the use of Fabric and serverless Puppet to do some quick tests on multiple virtual machines but maybe I’ll write a bit about that in another post some day. Anyway, here’s the script:

Subsys lock problem with CentOS 6.2 and Apache

While I was improving my LAMP module I ran in to a problem with Apache 2.2.15 on CentOS 6.2.
Apache wasn’t working with my new module so I decided to install it normally via yum and see what’s going on.
Got it installed just fine with:
yum install httpd

Ran sudo service httpd restart.
All went fine.

But now when I checked status:

service httpd status
httpd dead but subsys locked

Fabric – Wrappers and more error handling

I wrote about Fabric’s error handling in this post and there task execution errors were handled like this:

env.warn_only=True

def cmd(cmd):
    if run(cmd).failed:
        sudo(cmd)

What if the task is a bit more complex and has multilple parts that can go wrong? You might want to abort the execution and do some kind of rollback action.

The task could be aborted by just using env.warn_only=False but then then the task would be aborted before we can do any rollback actions.

Without a wrapper it could be done like this:

Puppet: User Management and /home over NFS

I was looking for a way to automate user configuration management on 20 Linux machines that I have been administering for several months now. In my setup I want to see following:

• add a user once, have him/her on as many machines as you define
• share users’ home directories over the network

There are many ways to have it done. I wanted to see how this can be achieved with Puppet for several reasons, mainly, because I want to have as much config management under the same hood as possible. And I am just starting with Puppet, so comments are welcome.

To implement the user management setup I need three modules:

• users – will define users, their passwords, ssh-keys (optional), default shells etc
• nfs_server – will share /home directory over NFS
• nfs_client – will mount the shared /home directory as /home

In this demo I have three machines, all running Debian Squeeze:

• puppet.mydomain.com – is the puppet master
• node1.mydomain.com – NFS server, will share /home over the network
• node2.mydomain.com – NFS client, will mount /home from node1

Automating WLAN connection & logon

Slightly easier topic today 🙂

A while ago I had to set up an Ubuntu machine so that after a reboot it would automatically log in to Gnome and connect to WLAN with the correct wlan key. There’s propably many ways of doing this and it might be quite easy to do with GUI but here’s how to do it from the command line.

WLAN key configuration

For setting the wlan key we need to modify the Network Manager configuration.
The configuration files for all your known connections are here:
/etc/NetworkManager/system-connections/
You need to add the key to the appropriate config. In my case it was Auto Wlan212. Sudo is needed for editing the file. There’s a lot of settings you can play with but the section for the wlan key is under
[802-11-wireless-security].
Before I modified anything these two lines were there already:

Script for adding multiple Vagrant boxes

I’ve been using Vagrant for a while now to test new configurations with simple virtual machines. Usually it’s just a single VM that I’m using but now I wanted to do some tests on more than one machine at the same time.

So I was looking for a way to easily create multiple identical virtual machines with Vagrant but couldn’t find a good solution so I made this small script to do it for me. If you know a better way, could you leave a comment and then we can both laugh at this script. I have also included a guide for controlling these new VMs with Fabric.

The script copies a packaged vagrant box as many times as you define and adds them to vagrant. Then adds the new virtual boxes to the Vagrantfile config. These new vagrant machines have hostonly static IP network setting but you can change it to bridged in the script if you want IPs from DHCP. The hostonly means that the machines can only be accessed from the host machine that’s running vagrant.

If you want to use multiple vagrant boxes without the script, here are the steps:
Create a single Vagrant box. Guide
Package it. Guide
Copy the package.box file. You need a copy for each virtual box. Guide 😉
Add the new box copies to vagrant. Guide
Add new config to Vagrantfile for each new box. Guide
Start the boxes with ‘vagrant up’

And here’s the guide for using my script:

Setting up a Github project

So I felt like setting up Github repository for awaseroot. Git is a version control system and with Github you can share your git project/repository online. We use Github as a place to share all our awaseroot material. There’s many good tutorials available (for example: http://help.github.com/win-set-up-git/) but here’s the steps I took one by one. Replace awaseroot with whatever you want.

Ubuntu 12.04
Git version 1.7.9.5

The goal is to publish this:

Like this:

Puppet module for LAMP installation

We are using Puppet in the course I spoke of before and we’re creating our own Puppet modules. Here’s what I came up with. A module that installs a LAMP server( LAMP = Linux Apache MySQL PHP) in two different ways to two different nodes. The lamp module has slightly more features than the easylamp. For example it changes the mysql password which is missing from the easylamp module. The modules might not be very sophisticated as these are some of the first Puppet modules I’ve ever made. Have to start somewhere!

UPDATE 6.10.2012: I have made improvements to the LAMP module and there’s a new blog post about it here:
https://awaseroot.wordpress.com/2012/10/06/improved-puppet-lamp-module/

Puppetmaster = Ubuntu 12.04
Puppet agents = Ubuntu 11.10
Puppet version 2.7.11

Modules and manifests

manifests/site.pp

node default {}

node 'bubuntu.elisa' {
    include lamp
}

node 'hubuntu.elisa' {
    include easylamp
}

Ubuntu Release Upgrade – Fully automatic non-interactive upgrade

Ubuntu 12.04 LTS has been released and it’s time to upgrade! The do-release-upgrade is the recommended way and don’t worry! I will use it. The problem is this: do-release-upgrade asks a lot of questions during the install but I have to upgrade multiple machines and I don’t feel like answering those same questions on each machine. So how to automate this?
EASY!

There’s a way to answer those questions in advance and in a single command. You can pipe some of the answers with echo and then use DEBIAN_FRONTEND=noninteractice for the rest of them. No preseeding needed at all. With this command you can automate a release upgrade completely.

Remember to take backups in case something goes wrong.

Fabric tutorial 3 – Settings and roles

In this tutorial I’m going to concentrate on various different settings you can use in your fabfile.
These settings can be added to your environmental variables, as decorators or inside the tasks. With roles
we can define which machines are for example servers and which are workstations.

I hope you’ve also read previous tutorials 1 & 2:
https://awaseroot.wordpress.com/2012/04/23/fabric-tutorial-1-take-command-of-your-network/
https://awaseroot.wordpress.com/2012/04/25/fabric-tutorial-2-file-transfer-error-handling/

Environmental variables

Your default settings should be in the environmental variables right in the beginning of your fabfile.
These are the settings that are used in all of your tasks unless you define it otherwise. These
are the settings that we’ll modify in our tasks later. We have used these in the previous tutorials.

fabfile.py

env.hosts=["simo@10.10.10.10","webserver.local"]
env.user="hng"
env.password="password"
env.parallel=True
env.skip_bad_hosts=True
env.timeout=1
env.warn_only=True