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… 😉 Read more of this post
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.
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.
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:
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:
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.
env.hosts=["firstname.lastname@example.org","webserver.local"] env.user="hng" env.password="password" env.parallel=True env.skip_bad_hosts=True env.timeout=1 env.warn_only=True
On the first turorial we learned to run commands on remote hosts with Fabric. Now we move on to
transfering files. Transfering new configuration files is usually quite important part of system administration.
Also retrieving log files from the remote machines might be useful.
Let’s assume we’ve made a new ssh_config file with important changes and we want to send it to our
remote hosts. Here’s a task for sending files.
def file_send(localpath,remotepath): put(localpath,remotepath,use_sudo=True)
Run it with:
or if the modified ssh_config is in the directory where you’re running Fabric:
If we’re sending the file to a location that doesn’t need sudo eg. /tmp/, we don’t need the use_sudo=True.
Another example: Read more of this post
This is a guide for installing and using Fabric on Ubuntu.
Fabric is a Python tool and a library for combining Python with SSH.
The tool can be used to execute Python functions from the command line. It’s also
possible to execute shell commands over SSH with Fabric and by combining the Python functions
with the SSH, it’s possible to automate system administration tasks. (fabfile.org)
You can use Fabric as a tool for centralized configuration management. You can run administrative tasks
on all of your machines simultaneously. Fabric is fast and easy to install and start using since there’s
no configuration needed, just install and start adding tasks to your fabfile.
Fabric doesn’t require anything else on the remote systems but a working SSH server. So if you
can control a device with SSH, you can also control it with Fabric. This is why Fabric is such
an easy and nice tool to add to your sysadmin tools. If you prefer Ruby over Python, take a look at a
similiar tool called Capistrano.
In these tutorials I will go through the installation and all the basics you need to start using
Fabric efficietly. Read more of this post