Category: Open Source


OTRS custom fields revisited : Dynamic Fields

Filed under: Open Source, work — Leave a comment
February 14, 2013

In a previous blog post titled ‘OTRS custom “Additional ITSM Fields”’ I wrote on how to extend OTRS to better suit an organisations particular needs. Michiel Beijen from the OTRS team pointed out that the method presented there is outdated in v3.1, and suggested the use of Dynamic Fields. I’ve finally had the opportunity to follow up on Michiel’s advise in a recent project I was involved with. This article will explore the configuration process for using Dynamic Fields as well as some tips and tricks learnt along the way. Throughout the article, I will give examples from my particular OTRS use case scenario.

In this use case scenario OTRS was already installed as your typical helpdesk system. We now wanted to extend OTRS to also work as a bug tracker. Since OTRS was already installed and used, we wanted to converge on this system as much as possible. OTRS has all the capabilities of a software bug tracker, with queues for each dev team, time accounted fields for tracking time and effort spent, and each ticket representing a bug that needed solving. However, out of the box we need extra fields describing “categories” – where each ticket/bug can be categorized according to field such as security, usability, and so on. This is where dynamic fields come into play. Using OTRS it is possible to create a custom field – text, multiple choice, etc – that is also nonviolently searchable.

The procedure to define a new dynamic field is:

  • Login to the admin interface (using root@localhost by default)
  • Follow the documentation located here: http://doc.otrs.org/3.1/en/html/dynamicfields-configuration.html#dynamicfields-configuration-add. For example, in my case, creating a new “category” dynamic field involved:
    • Admin > Ticket Settings > Dynamic Fields
    • Since I want this new dynamic field to apply to the whole ticket, I selected “dropdown” from under “Ticket” on the left hand menu, rather than from “article”, which would have applied the dynamic field to a particular entry within the ticket
    • Modify the field to your needs. Make a special note of the “name” since you will be referencing it later. In my example, I chose the name arbitrarily to be “CloudLinkCategories”
  • That’s about it, however there are a few tips. Add the dynamic field to the following:
      • sysconfig > tickets > Frontend::Agent::ViewSearch

The above will allow you to have dynamic field as searchable attribute in the agent search function (update: apparently in v3.2 this is included by default)

search

      • sysconfig > tickets > Frontend::Agent::ViewZoom

The above will allow the dynamic field to have it appear in ticket details on right hand side of the agent view, along with all the other default ticket properties

zoom

      • sysconfig > tickets > Frontend::Agent::ViewFreeFields

The above will allow an agent to edit the dynamic field by clicking on the “Free Fields” entry in the menu bar

freefield

      • sysconfig > tickets > Frontend::Agent::TicketOverview

The above will make the dynamic field appear in ticket table overview

In each of the above sections, you will see an entry containing “DynamicField”, where under “Key” you can enter the “name” of the Dynamic Field you created earlier

As a final note, you can use the dynamic fields in the OTRS statistics module, which is handy for graphing the amount of time spent on each category over a given time period.

About these ads
Tags: , ,
Comment

Web MeetMe : Conferencing in FreePBX

Filed under: Linux, Open Source, Ubuntu, work — Leave a comment
November 30, 2012

The company I work for currently uses TrixBox as their VoIP server. It’s an excellent piece of software but being no longer supported, the decision was taken to upgrade to the later and more active FreePBX. Since they are both built around the asterisk core, I figured this upgrade wouldn’t be too much of a problem. In fact it wasnt, most of the features in TrixBox I got working in FreePBX with no effort.

There was one stumbling block: conferencing. In TrixBox, users used to dynamically create conferences on the fly using WebMeetMe. In TrixBox, installation and activation of WebMeetMe was as simple as downloading and activating the appropriate module. Alas, in FreePBX the excellent WebMeetMe is not pre-installed (why??). So the installation is a bit more involving though ultimately works just as well :)

I am taking the opportunity to document exactly what I’ve done to get this working:

1. Download latest version of FreePBX

2. Install FreePBX as per usual procedures. Create a couple of SIP extensions and make sure they work before proceeding. Pleny of documentation on the ‘net if you get stuck here

3. Download the latest version of WebMeetMe

Note: For any of the below to work you need to ensure that FreePBX is setup to use the meetme module rather than the newer “confbridge”. This is done via:

FreePBX > Settings > Advanced Setting and ensure that Conference Room App is set to “app_meetme“

3

4. The README within the tarball downloaded from 3 has some good install notes, however I found Mark In the Dark’s install notes to be much clearer and helpful. So, I followed the steps outlined here:

http://www.markinthedark.nl/news/ubuntu-linux-unix/75-install-web-meetme-402-for-freeppbx-28-with-asterisk-18-on-centos-55.html

5. Once the above procedure was done, visiting the page http://%5Bmy-ip-address%5D/web-meetme/meetme_control.php returned a HTTP 500 error. Checking the /var/log/httpd/error logs I saw a corresponding entry similar to:

PHP Parse error:  syntax error, unexpected $end in /var/www/html/web-meetme/lib/defines.php on line 145

To resolve the above, open the file defines.php, scroll to the bottom, and change the last three lines from this:

<?
}

?>

To this:

<?php
}

?>

6. If, like me, you decided on using MYSQL for authentication rather than LDAP, I again ran into an HTTP 500 error when attempting to logon. The error was:

PHP Fatal error:  Call to undefined function authsql() in /var/www/html/web-meetme/lib/functions.php on line 73

To resolve this, copy the contents of:

/var/www/html/web-meetme/lib/sqldb.php 

into:

/var/www/html/web-meetme/lib/functions.php

The above should allow you to login and schedule calls using web meet me. That said, I found documentation on how to setup an extension which callers could use to dial into WebMeetMe woefully lacking. Here’s what I did:

1. Add a custom extension

> SSH into the box, and edit the file: /etc/asterisk/extensions_custom.conf

> Add the following to the file:

[conferences]
include => ext-meetme; in [ext-meetme] contest are stored all the conferences created in FreePBX
exten => s,1,Answer
exten => s,n,Wait(1)
exten => s,n,Playback(welcome); Insert your welcome recording
exten => s,n,Goto(STARTMEETME,1)

2. Add custom destination
This step is needed to make the FreePBX GUI aware of the custom extension we define above, and make it available as a choice within the GUI. Within FreePBX: [admin > custom destination] and use:

Custom Destination: conferences,s,1
Description: conftest

1

At this stage, you have an extension you can use. In our case we needed the webmeetme to be dialed into from both an external number and an internal one.

For external callers

  • FreePBX > Connectivity > Inbound Routes. Select the appropriate DID, ex 21123456, and set the destination as a custom destination and select conftest from the pull-down menu (or whatever you entered in step 2 above)

For Internal callers

  • FreePBX > Applications> Misc Applications. Enter in a description, a “feature code” (which is the number internal users will dial, example *789, and select the destination to be a custom destination and select conftest from the pull-down menu (or whatever you entered in step 2 above)

2

Tags: , ,
Comment

Traffic shaping using PfSense in bridged mode

Filed under: Open Source, Security — Leave a comment
October 23, 2012

Scenario: We needed an in-line, transparent traffic shaping solution. The solution we chose was pfsense due to it’s easy to use UI and effective QoS. The PfSense had to be placed in bridge mode, on a link that was carrying tagged traffic. It is important that the PfSense did not touch the vlan tagging, it was only to rate-limit the traffic.

The first step was to bridge the two interfaces. We first created allow rules on the firewall to allow all traffic to pass through the pfsense since filtering was not necessary. We then proceeded to bridge the interface via Interfaces > (assign) > bridges and creating a bridge interface containing the two interface in question. No further configuration was needed. PfSense retained the VLAN tagging so the L2 802.1q vlan tags were preserved across the bridge

An IP address was configured on one of the interfaces for management. Two points about configuring an IP address on the Pfsense:

  • It doesnt matter which interface you configure with the IP, the interfaces are bridged
  • The IP must be in the native vlan if you configure it on a physical pfsense interface

We next go on to defining queues for various traffic classes we needed. We decided not to use the wizard since that would introduce several feature we didnt need. The below is done via Firewall > Traffic Shaper.

  • Enable QoS on each interface by clicking on the interface on the left hand side and ticking “Enable/disable discipline and its children“
  • Decide which scheduler type to use. We chose HFSC – this is the scheduler used by several industry firewalls such as Palo Alto.
  • Define the bandwidth available to the interface. In this case, since the firewall was internally placed, we set the bandwidth to 2GB/s
  • Proceed to define child queues by using the “Add new queue” button. How you place the queues (i.e. parent-child relationships) is highly dependent on what you want to achieve. In our case a single “layer” of queues was sufficient. we needed a queue for each customer and an “internal” queue which takes care of internal traffic – i.e. traffic not flowing out to the internet, which should not be rate limited. A couple of points about these queues:
      • You need at least one default queue per interface. This will act as a catchall. A default queue is defined as any other queue, with the difference of selecting the “default queue” option in “scheduler options”

      • It’s always a good idea to enable random early detection in your queues in case they get over-subscribed
      • When dealing with high-bandwidth environments such as the one presented here (internal traffic on a gigabit network) you need to increase the queue limit (this option can be changed per queue). We found a value of 2000 to be sufficient. If left as per default, your queues will not provide the maximum bandwidth you configure for them

      • The most efficient QoS is applied to egress traffic. In order to visualize this, imagine you are the firewall… egress traffic on your WAN interface is what we generally call “uploading” to the internet. Similarly, egress traffic on the LAN is generally called “downloading” from the internet. Keep this in mind when defining queues. If you need to define the same queue on two interfaces (symmetric traffic shaping) simply add a new queue to the interface and ensure you name the queue in exactly the same way as you did on the other interface, for example:

  • Last, apply the queues you just defined. In our case, since we had symmetric traffic shaping we wanted the queues to apply in all directions, whether egressing from one interface or the other. So we defined floating rules via firewall > rules > floating tab.

The rules allow you to classify traffic as any other firewall rule does, so you can limit by subnet, IP, service, protocol, etc… simply define the rule, and under the advanced section make sure to select the correct queue (second fiel – the first field is used for ingress QoS which we didnt use)

The nice thing is that pfsense doesnt limit the maximum number of queues that you define – much better than some commercial solutions out there!!! ;)

Tags: , , , ,
Comment

Adding agentless Windows WMI monitoring to Nagios

Filed under: Linux, Open Source, Scripting, Windows, work — 1 Comment
September 17, 2012

There are a couple of well documented methods to monitor Windows machines from Nagios. The most popular of these seems to be NRPE. This method works very well, but the biggest downside for me was the need to install a client on every machine that needed to be monitored. WMI seemed to be the best bet in being able to remotely monitor windows machines without needing to install an agent on the monitored machine. During my research, I cam across wmic, a bash shell wmi client capable of querying for WMI values remotely.

Installation

Installing WMI was a breeze thanks to a pre-prepared packages in the atomic repository. First we add the repository:

wget -q -O - http://www.atomicorp.com/installers/atomic | sh

Then it’s simply a yum wmic to install the client on a centos machine.

Preparing the target machine

We need to ensure that WMI is installed on the target machine. This also includes making sure the WMI service is started and running. The WMI service has a couple of dependencies, the most important of which is the RPC service, so we must make sure that those services are themselves started. You can view a service’s dependencies from the services console > right click on a service > properties > dependencies tab

Also check for any windows firewalls or other firewalls that will need a rule exception to allow WMI traffic. Have a look at this link for more information

Writing bash scripts using WMIC

This is where most of the work comes in. First, familiarize yourself with the available WMI classes. This basically gives you an indication of what can be monitored through WMI. The best documentation I’ve found to this end is Microsoft’s technet, here:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa394084(v=vs.85).aspx

In a nutshell, the ones I’ve found most useful were:

CPU monitoring: PercentProcessorTime from the Win32_PerfFormattedData_PerfOS_Processor class

Memory monitoring: AvailableMBytes from the Win32_PerfFormattedData_PerfOS_Memory class

Process monitoring: ThreadCount from the Win32_PerfFormattedData_PerfProc_Process class

Service monitoring: Status from the Win32_Service class

The following link will download a tar file that contains sample scripts for each of the above mentioned monitoring scenarios. They include outputting perdata for graphing. I have not include much in the way of documenting the scripts, but they are pretty self explanatory. Just note the variable that are defined in the beginning of each script so you can follow the script’s logic.

Link to scripts

Enjoy :)

Tags: , , ,
Comment

Check_mk, pnp4nagios and mod_gearman

Filed under: centos, Linux, Open Source, work — 8 Comments
August 11, 2012

Ever since i’ve been working with Centreon, I’ve found it to be a relatively stable all-in-one solution. Its all-in-one aspect makes it extremely convenient (for example, graphing is taken care of without any third part modules. Moreover, since Centreon is built on top of nagios / icinga, you get to all the openness, and flexibility of the Nagios core. Using Nagios, it’s possible to monitor pretty much anything.

But, Centreon has a major shortcoming… it’s dependence on a database. Most commonly, this database is MySQL. The database makes things slow once you start monitoring a certain amount of checks. Centreon’s WebUI reads information from the centstatus / centreon_status database. In my case, we’ve been monitoring approximately 3,000 checks. We hit a bottleneck. For some reason, after a nagios restart/reload (say, to implement a new check), it would take ages (about 15 mins) for Centreon WebUI to display all the hosts and services being checked, if it showed them at all. Also, after scheduling an immediate check, it would take about 5-7 minutes for Centreon’s WebUI to get updated.

At first, we thought it was the nagios core, having heard that nagios doesnt scale well. But that’s actually a lie. I installed mod_gearman and nagios easily handled the workload. 3,000 checks from a single server without any problems. Mod_Gearman is a keeper, easy to install, with massive benefits. Until Nagios core includes mod_gearman functionality, it’s always my first performance enhancing install right after nagios. The nagios and mod_gearman combo executed all checks on time.

So next we turned our attention to the database. This turned out to be the bottleneck. No matter what method used to interface between centreon and MySQL, it was taking too long to read/write from the database. I used several methods to try improve performance. We updated to the latest NdoUtils, we tried two alternatives: IdoUtils (from icinga) and Centreon Broker. I tried decreasing the flush queue, tired unix sockets instead of tcp sockets, tried tweaking mysql itself… Still no joy.

So, it seems the best way is to completely ditch the database. Mathias Kettner came up with a brilliant solution of reading the current state of checks from the nagios core: check_mk livestatus. His solution is simple to implement, extremely fast and scalable, and easy to interface with. It seems the natural way to go. Unfortunately, this means ditching centreon until they decide to implement livestatus functionality. They seem to be (unwisely) ignoring the request to implement it:

http://forge.centreon.com/issues/2402

Case made against centreon, so what to use to replace it? There is a myriad of open source tool combinations that seem to work. I wanted a scalable, fast and all-in-one solution similar to centreon. This is what I went for:

- Core: nagios and mod_gearman. This combination worked wonders for me. It’s fast and easy. Nagios’ community base makes it easy to troubleshoot. Nagios’ API makes it easy to script any monitoring check.

- GUI: check_mk multisite. Built on his aforementioned Livestatus. Fast, lightweight, and easy to use, this GUI is exactly what I was looking for. It also provides configuration of nagios. Multisite also makes it easy to integrate multiple sites into a single dashboard.

- Graphing: pnp4nagios. This tool uses rrdtool (same as centreon). The other main contender was nagiosgraph, but pnp4nagios won out for two big, main reasons:

* it integrates really well with multisite. Multisite allows pnp4nagios graphs to be integrated seamlessly within it’s GUI

* it integrates with mod_gearman. Yep, it does… meaning perfdata from nagios gets parsed quickly… again, it’s fast and scalable. Since I already use mod_gearman for the performance benefits it gives to nagios, it’s a no-brainer to include mod_gearman as a perfdata processor.

Note: kudos to the developers of these tools. The tight and seamless integration between the different tools is amazing, and the advantages of each tool blend together to make an amazing single product.

Here’s the techie part of this article… I had some difficulty getting pnp4nagios to integrate with mod_gearman. It’s only due to lack of clear documentation, so i’ll try explain what worked for me.

- I installed mod_gearman via the repositories provided here:

https://labs.consol.de/repo/

- I followed the usual instructions for integrating mod_gearman into nagios, adding the following lines into nagios.cfg:

event_broker_options=-1
broker_module=/usr/lib/mod_gearman/mod_gearman.o config=/etc/mod_gearman/mod_gearman_worker.conf

- I setup pnp4nagios w/ mod_gearman as per instructions here:

http://docs.pnp4nagios.org/pnp-0.6/config#gearman_mode

However, I needed to make the following changes before it would work:

1. I checked the mod_gearman_neb.conf file and saw the following interesting option (and changed it from the default no to yes):

# defines if the module should distribute perfdata
# to gearman.
# Note: processing of perfdata is not part of
# mod_gearman. You will need additional worker for
# handling performance data. For example: pnp4nagios
# Performance data is just written to the gearman
# queue.
# Default: no
perfdata=yes

2. I changed the default nagios.cfg configuration to point to this file instead:

event_broker_options=-1
broker_module=/usr/lib/mod_gearman/mod_gearman.o config=/etc/mod_gearman/mod_gearman_neb.conf

That did it :) checkout the screenshot’s from Multisite’s site:

http://mathias-kettner.de/bilder/1276533368.png

Tags: ,
Comment
Follow

Get every new post delivered to your Inbox.

Join 89 other followers

%d bloggers like this: