osTicket and OTRS - a comparison

While I have been a fan of OTRS for many years and like the interface, reporting and usability of it, I recently chanced across osTicket (from the TV series Mr Robot). It looked interesting and a client I have wants an internal ticket management system (they had also seen it). After a bit of to and fro, they agreed to some research time and I set up osTicket.

My usual server OS is Ubuntu's latest LTS. In this case, 16.04LTS. The problem is, it ships with PHP7, and osTicket doesn't play nicely with that. There is a good tutorial over on Chubbable that's worth checking out: https://chubbable.com/osticket-install-guide/2#ubuntu-based

Have a look at that if you want to install it - it's pretty straightforward.

So my impression of osTicket is that its pretty good. The interface is reasonable intuitive and I've set it up at home to manage the stuff I'm going (but mostly just to play with it). There is a client interface and an agent interface. The Agent interface gives you access to tickets and tasks. Tickets are the top level action, tasks are a part of tickets. In this way, some basic project management can be applied. Here are a few different views that are available:

osTicket Dashboard

osTicket Task view - got some work to do on NFS No Limits!

osTicket Tickets

You can see in the Tickets there is an NFS No Limits ticket. Under the tasks panel, you can see I've broken this down further into the things I need to do with that Ticket. I imagine with multiple agents, the tasks could be spread around.

So why not migrate to osTicket? The ability to capture time in osTicket seems to be hideously complicated to implement. Perhaps I need to do more research into that, but in OTRS its pretty straightforward. For a company just interested in getting things done, then the time capture isn't so important, but for us - its a big part of the job being completed. Reporting is still something I need to investigate. The reporting in OTRS is great (once you get your head around it) so I'll be interested to play with osTicket a bit more and see how it goes. Stay tuned for more updates...!

OTRS and HTTPS

Following the recent upgrade of OTRS on our servers to the latest version, I went one step further and decided to deploy https to wrap it all up. There is no significantly important data shared or entered in our OTRS configuration, but I think it a worthwhile exercise to put encryption in place. I've only really touched on SSL once or twice before with server configurations, and I started out by looking for a cheap certificate. The thing is, this is a commercial application of the system and I didn't want to use a non-profit or education SSL cert for something that is part of our money making enterprise.

Enter "Let's Encrypt". I read about this somewhere - probably one of the many *almost* spam newsletter type emails I get during the week from a vendor. A Google search brought up a DigitalOcean write up on how to apply this to the particular version of Linux I'm running.

I'm just going to say that I love the DigitalOcean walk through's. They're clear and easy to follow. I tend to have bits of extra complexity in my installs, but I'm usually able to extrapolate from the D/O information to get want I want. Here is the link to the walk through that I used:

https://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let-s-encrypt-on-ubuntu-14-04

Get around it - it's great. So now we have an encrypted OTRS site and it works well.

Apart from just having an encrypted site, we have also noticed a pleasing uptick in the responsiveness of the site and a removal of an ongoing issue we were having access it from external. When my techs would try to connect to the page from outside the office and then enter data into it, they would have to continuously re-authenticate. This was completely unusable and also one of those problems I just never seemed to have time to get around to fixing. Now, with https:// in front of the address, this problem has disappeared! The site responsiveness isn't to be ignored - no matter where it's being accessed from, the page is significantly faster, a fact which pleases all of us.

To summarise - spend the time and get the encryption happening for OTRS - it's worth it!

OTRS Upgrade Notes

First things first, we need to download the latest and that’s usually from the public FTP site on OTRS’ site. Here is a good place to start: https://www.otrs.com/download-open-source-help-desk-software-otrs-free/ I always grab the source .tar.gz file and usually with this command:

# wget -c http://ftp.otrs.org/pub/otrs/otrs-5.0.13.tar.gz (for the latest one anyway – which at time of writing I 5.0.13)

The upgrade direction is here: http://otrs.github.io/doc/manual/admin/5.0/en/html/upgrading.html and I want this to be my summarized version of this for ease of use both for myself and for you, gentle reader.

I have a script that starts off the upgrade process with some of the basic stuff (note – run this as root):

#!/bin/bash

service cron stop

service apache2 stop

service postfix stop

NOW=`date +%F`

mkdir /root/backup/$NOW

BDIR=/root/backup/$NOW

cp -R /opt/otrs/Kernel/Config.pm $BDIR

cp -R /opt/otrs/Kernel/Config/GenericAgent.pm $BDIR

cp -R /opt/otrs/Kernel/Config/Files/ZZZAuto.pm $BDIR

cp -R /opt/otrs/var/ $BDIR

/opt/otrs/scripts/backup.pl -d $BDIR

Now what this does is to stop the services in Step 1 of the upgrade documentation.

Then we set the “date” variable and create a backup folder for it and instantiate a variable to make the script shorter – the “BDIR” variable.

Now I simply step through the guide and backup what I need to in Step 2 and then run a full backup into the backup directory with the backup.pl -d $BDIR command.

Now it’s time for the command line work to begin. I typically download the source file into an OTRS folder in my root home directory (yes I do this all as root) so I will run:

# tar -zxf otrs-5.0.13.tar.gz

Once the tarball is extracted I copy the resultant directory to the /opt/ folder:

# cp -R otrs-5.0.13 /opt/

In the directory are all the other OTRS installs I’ve done but haven’t cleaned up. An ls of the /opt/ directory usually looks like this:

root@otrs:/opt# ls

otrs        otrs-4.0.11  otrs-5.0.1   otrs-5.0.13

otrs-4.0.1  otrs-4.0.7   otrs-5.0.10  otrs-5.0.5

root@otrs:/opt#

The bolded otrs is a logical link. I delete that:

# rm otrs

And create a new one:

# ln -s /opt/otrs-5.0.13 otrs

We need to copy stuff back now and I have a bit of a script that will do it:

#!/bin/bash

BDIR=/root/backup/`date +%F`

cp -R $BDIR/Config.pm /opt/otrs/Kernel/

cp -R $BDIR/ZZZAuto.pm /opt/otrs/Kernel/Config/Files/

It copies back the files we need to and moves us through Step 4.

Now to set permissions on the new OTRS directory:

# /opt/otrs/bin/otrs.SetPermissions.pl –web-group=www-data (for Ubuntu)

And this sorts out the permissions. I also find it very useful to change the ownership of files at a more macro level too, so I will also run:

# chown -R otrs:www-data /opt/otrs*

# chmod -R g+w /opt/otrs*

This has solved some issues in the past and seems like a handy thing to do.

Step 4 is finished and Step 5 has us checking Perl modules out:

# /opt/otrs/bin/otrs.CheckModules.pl

We can skip to Step 7 now and we have to change to the OTRS user:

# su otrs

As OTRS, Step 7 gets us to refresh the config cache and then delete the other caches:

$ /opt/otrs/bin/otrs.Console.pl Maint::Config::Rebuild

$ /opt/otrs/bin/otrs.Console.pl Maint::Cache::Delete

Annoyingly we have to change back to root and restart services. I just CTRL-D out of otrs and then run:

# services apache2 start

# services cron start

# services postfix start

And then su back to OTRS

# su otrs

$

Step 12 – restart the OTRS Daemon (as otrs – don’t forget!)

$ /opt/otrs/bin/otrs.Daemon.pl start

And then Step 13 which updates cron for the OTRS user:

$ cd /opt/otrs/var/cron

$ for foo in *.dist; do cp $foo `basename $foo .dist`; done

$ /opt/otrs/bin/Cron.sh start

And that’s it for the command line stuff.

Log into the website and go to Admin and then Package Manager. I usually find that at least three packages need to be either re-installed or updated. While these are not right, the website will run terribly slowly. Fixing the problem here will give you back some performance and set it on the right track.

That’s pretty much it. Done!

OTRS 5 Review and Thoughts

Recently I upgraded our several years old OTRS install to version 5. The upgrade procedure is exactly like all the others have been. It was straightforward and I actually found that the documentation was better this time around than it has been in the past. After backing up, upgrading and testing, I like, mostly, what I see. There are a couple of things that are a bit annoying though.

When closing a ticket, the previous version would automatically put in subject in the closure note. Likewise, in the Owner Update note it doesn't do it either. So each time, I have to update it. Not a problem if you're only getting a few notes every now and then, but we are changing and closing tickets in some large numbers at times.

Also, I have about 50 statistics generated monthly via a script I run. The syntax for doing this.

From: /opt/otrs/bin/otrs.GenerateStats.pl -n number -blah blah etc

To: /opt/otrs/bin/otrs.Console.pl Maint::Stats::Generate --number number etc

(from: https://otrs.github.io/doc/manual/admin/stable/en/html/statistics-module.html#stats-managing-the-module)

I like the speed of the updated system and the cosmetic changes are nice too. The menus have changed slightly and they are more dynamic with drop downs. The layout is a bit nicer too but generally the speed of the system is better.

Upgrade to version 5 if you have the chance - seems to be a winner!

OTRS 5 Review

I've been using OTRS for about 10 years now, starting when I was doing desktop / server support at uni. Since then it's changed a lot in the way it looks, but fundamentally it has remained the same. The great things about OTRS are:

• creating / modifying / updating and closing tickets is easy
• the interface is relatively straightforward
• creation of tickets from emails is easy
• reporting is straightforward
• open source and robust

Since the early versions it's ticked all these boxes and I was very interested to see what OTRS 5 was going to bring. The interface is still the same, updated here and there with a prettier graph showing closed / opened tickets but generally the same. Fonts are still nice and readable and its good for what it does.

We use it for our clients that have a maintenance agreement with us. We have them create tickets that we then update and put minutes against. OTRS has never had a parts component and we have always used a secondary system for that. It does a good job too of keeping tickets together - I can't recommend using the master/slave system enough. Merging tickets has always worked flawlessly too.

The upgrade process is well documented and relatively straightforward. Just be aware of what user you are accessing the system as when you're doing it - sometimes you need to be root and other times it's important to be the OTRS user. All in all, it took about 45 minutes with backups, testing and checking before I let the boys go wild on it.

So while the interface is prettier there are a couple of things that annoy me right off the bat. When I add a note I now have to put something in the title - before it would simply put "Note" in there. Likewise for closing a ticket or changing ownership - this one extra step is annoying because I do it so frequently. Also, we have queues that are underneath a top level queue and that needs to be manually expanded out each time now instead of it sitting out like it always has. Minor annoyances it's true, but annoyances nonetheless.

I suspect most of the changes in the system are in the back end and I'm noticing that it is running more smoothly. We are using a fairly archaic IBM server to host it on an Ubuntu Linux Server platform with about 10K tickets give or take. MySQL is our database of choice and the backups run at around 1 GB in size. Thus far it has all been good. I'm looking forward to seeing how it travels over the next few weeks. I have noticed that the iPhone package is no longer supported - apparently the interface scales with the mobile platform - we will test this further. 

Enjoy :-)

OTRS Restore Procedure and backup script

As I note in my previous post, I managed to kill my OTRS install and as usual had to trawl around the net to remember how to restore it. In a nutshell:

# mysql -u root -p
msyql> drop database otrs;
mysql> create database otrs;
mysql> ext
# /opt/otrs/scripts/restore.pl -d path_to_backup /opt/otrs

You did back up right?

Nightly I run a script with the following in it:

otrs_backup.sh


#!/bin/bash
# Variables below - change these to suit
NOW=$(date +"%Y-%m-%d_%H-%M") # this gets the correct file name for OTRS backup
LOCAL=/root/backup # a local directory for OTRS to backup to
REMOTE="user@backupserver:~/backup/OTRS/" # remote backup dir - nfs share, ftp or cifs
/opt/otrs/scripts/backup.pl -d $LOCAL # OTRS internal backup (files and DB)
tar -cf $LOCAL/$NOW.tar $LOCAL/$NOW # creates a file from the OTRS backup folder - more efficient to copy over a network
gzip $LOCAL/$NOW.tar
rm -rf $LOCAL/$NOW # tidy up
scp -r $LOCAL/$NOW.tar.gz $REMOTE # scp to remote directory

You may wish to run this from crontab after copying otrs_backup.sh to /usr/local/bin:

0 20 * * * /usr/local/bin/otrs_backup.sh

This will run at 10pm each night - theoretically you could run it more frequently. OTRS databases will a lot of attachments get quite large though so be mindful of that (I have a couple I manage that are 1GB and are only 5 months old)

Enjoy

Upgrading OTRS 3.1 to 3.2.1

After noting that our OTRS (www.otrs.org) was complaining about a major release update pending I took the plunge this morning and set about upgrading it. Initially I ran through the normal upgrade procedure and couldn't log on. Oops. Maybe I need to pay more attention here? Turns out there are quite a few caveats about this upgrade, and I'm hoping that what I note here will assist you - especially the database upgrade stuff. That was a bit of a surprise!

Initially I ran my normal otrs_pre_upgrade.sh script which stops services and backs everything up. That script looks like this:

#!/bin/bash
service cron stop
service apache2 stop
NOW=`date +%F`mkdir /root/backup/$NOW
BDIR=/root/backup/$NOW
cp -R /opt/otrs/Kernel/Config.pm $BDIR
cp -R /opt/otrs/Kernel/Config/GenericAgent.pm $BDIR
cp -R /opt/otrs/Kernel/Config/Files/ZZZAuto.pm $BDIR
cp -R /opt/otrs/var/ $BDIR
/opt/otrs/scripts/backup.pl -d $BDIR

Usually I then ln -s otrs-new otrs and run my upgrade script - but something failed along the way. Here is what I found:

Firstly, there are a lot more PERL modules required in 3.2 - these three caught me out:

• YAML::XS
• DBD::ODBC
• JSON::XS

I added them using aptitude - my OTRS install is on Ubuntu 12.04 LTS (www.ubuntu.com) - easy enough to do and then checked the modules again. If you are following the UPGRADING documentation, you should run:

• /opt/otrs/bin/otrs.CheckModules.pl

This will tell you what modules you require. I didn't bother with the Oracle or PostgreSQL modules as I'm not using those databases, nor am I interested in the Encode::HanExtra (no Chinese characters). 

Secondly there are database changes to be made. MySQL uses INNODB as the default storage engine. I've never even thought about this before - OTRS had always just run happily without asking me fancy questions about this sort of thing. Now in 9 of the UPGRADING document I had to apply database changes, including changing the default storage engine from INNODB to MyISAM.

Fortunately I stumbled across some nice scripts to do this at Techusers.net - here they are tailored to suit OTRS:

Step 1. Get all the table names from OTRS (you'll have to put in your password and you might have to change root to something more site applicable):

mysql -u root -p -e "SHOW TABLES IN otrs;" | tail -n +2 | xargs -I '{}' echo "ALTER TABLE {} ENGINE=INNODB;" > alter_table.sql

Step 2. Updating all the tables in one go (same as above - password + username update)

perl -p -i -e 's/(search_[a-z_]+ ENGINE=)INNODB/\1MYISAM/g' alter_table.sql 

Step 3. Applying the change to your SQL Database:

mysql -u root -p otrs < alter_table.sql 

Much thanks and kudos to the writers at www.techusers.net - this saved me from doing each table by hand! The search_profile table refused to change from INNODB to MyISAM but when I checked the dbupgrade scripts, this particular table isn't mentioned. It did not seem to affect the overall upgrade.

The rest of the upgrade went fairly smoothly. It's important to note, however, that you must go to Admin -> Packages -> Update Online Repository and then upgrade your packages to get better speed from your OTRS install. I found that after I did this, I restarted the apache service (service apache2 restart) and OTRS began humming along quite nicely. I'm still exploring the new features. Enjoy

Restoring OTRS on an Ubuntu Server

Some time ago I relocated our OTRS server from a failing server to a virtual machine under Microsoft Hyper-V. While the change to a virtual machine ran smoothly and I used the details in a previous post to set it up, after a month I noticed some strange errors creeping in to the installation - the nightly log emails had inconsistencies in them. Fortunately I was able to run a full backup of the OTRS installation using the built in backup tool and very shortly thereafter the server fell in a heap. Rebooting it caused a complete failure of the virtual disk. Now, how the hell something like that happens is beyond me. It was like the virtual disk dropped a head or something.... Ridiculous I know, but the fsck I ran basically told me the disk had failed and corruptions crept in to everything on the disk. Realising that I was fighting a bad fight, I decided to create a new virtual machine and transfer the data back across.

The recovery procedure, described here: http://doc.otrs.org/3.0/en/html/restore.html doesn't really cover everything that needs to happen. Here is a short breakdown of the notes that I made while I was running the recovery process:

• make sure you set the MySQL (or whatever database you use) password to be the same.
• in fact, make sure you match up all the passwords where possible.
• Install OTRS first using the Ubuntu install method - which is well described here: http://wiki.otrs.org/index.php?title=Installation_on_Ubuntu_Lucid_Lynx_(10.4) 
• make sure you run all the right commands, including the cron ones (which I initially forgot - oops!)
• Run the restore as per the link above and then restart apache and cron.
• Test your installation and see how it goes.

Since this error, I've written a very simple script that runs the backup and scp's it across to another server I have. This in turn is backed up to my FreeNAS box, hopefully protecting my useful data. Here is the script:

---------------------------------------------------------------------------------------------------

#!/bin/bash

NOW=$(date +"%Y-%m-%d_%H-%M")

/opt/otrs/scripts/backup.pl -d /home/user/backup

scp -r /home/user/backup/$NOW user@server:/home/user/backup/OTRS/

---------------------------------------------------------------------------------------------------

The $NOW variable is configured to match the output of the OTRS backup.pl script and then I simply scp it across to my server. It's date organised and works pretty nicely. rsync might be a nicer way to do it, but this virtual machine only provides OTRS and nothing else so I'll keep it simple. 

If you can use any of this then please do.

AB out.