OTRS is an open source service management solution used by many companies around the world. It’s extensibility and ability to integrate with other systems no doubt add to it’s popularity. Written in
perl, this software will run on mostly anything, and it’s low requirement on resources makes it ideal even for a small business to start ticketing, or standardize their internal processes.
In this tutorial we will install OTRS on a Red Hat Enterprise Linux 8. Keep in mind that the steps described below are only apply to version
6.0.14, Community Edition. For example, version 6.0.15 will not work when the below steps are performed on the same environment.
In this tutorial you will learn:
- How to install OTRS from tarball
- How to solve dependencies
- How to configure the environment
- How to run the web installer
- How to login to the service
Software Requirements and Conventions Used
|Category||Requirements, Conventions or Software Version Used|
|System||Red Hat Enterprise Linux 8|
|Other||Privileged access to your Linux system as root or via the
# – requires given linux commands to be executed with root privileges either directly as a root user or by use of
$ – requires given linux commands to be executed as a regular non-privileged user
Otrs installation on Redhat 8 step by step instructions
OTRS, the application in a strict sense, can work with multiple solutions to form the intended service. There are also multiple ways to install it from different type of packages.
In this tutorial we will use the tarball package, and choose to install PostgreSQL for database, and Apache httpd for webserver. OTRS heavily builds on other perl modules, and while some of them are available on RHEL 8 if we have access to the subscription management repositories, there will be many that will not. We can install those after setting up CPAN, what will save us from module hunting (and possibly new dependencies arising).
- To download the package, we’ll need to search the tarball at the OTRS archives, there is no direct link for this version on the home page. After finding the appropriate URL, we’ll enter the
/optdirectory on the target machine, and use
# cd /opt # wget http://ftp.otrs.org/pub/otrs/otrs-6.0.14.tar.bz2
- We extract the archive:
# tar -xvf otrs-6.0.14.tar.bz2
And create a symlink called
/opt/otrsthat points to the now created directory:
# ln -s /opt/otrs-6.0.14 /opt/otrs
- Naturally we’ll need
mod_perlthat enables the webserver to run perl code:
# dnf install procmail httpd mod_perl perl perl-core
- Now comes the tricky part. within the extracted data a perl script is provided, that will check our system for the required modules, and list what is needed for what function, and if we have the given package, or not. We don’t need to satisfy all requirements, it all depends on the planned usage of OTRS.For example, if we plan to use MySQL as backend, we would need
DBD::mysql, but we wouldn’t need
DBD::ODBCto connect to an MS-SQL database. What makes this script really useful is there is explanation provided in the output for every module, so we can decide if we will need the module in our setup, or not. That being said, consider the following output of the script on first run:
# perl /opt/otrs/bin/otrs.CheckModules.pl
This is quite a lot to process, on a lab machine already having some perl modules installed. Our approach here is install everything “required” and “optional – recommended”, as well as the
DBD::Pgmodule, because we will use PostgreSQL as backend. Some of these packages are available to install with
# dnf install "perl(Date::Format)"
The rest can be installed with
cpan install 'DateTime'
This step of solving all needed modules can be quite time-consuming, this is what we could saved from if we would install from pure rpm-based sources.
- We create the user that will be the owner of the
# useradd otrs
And add it to the
apachegroup (which is the group of
apacheuser who owns the webserver) as supplementary group:
# usermod -G apache otrs
So the user’s membership will look like the following:
# id otrs uid=1006(otrs) gid=1006(otrs) groups=1006(otrs),48(apache)
- We need to copy a distributed set of configuration as the main configuration of the application:
# cp /opt/otrs/Kernel/Config.pm.dist /opt/otrs/Kernel/Config.pm
- We append the webserver’s configuration with a file provided by the application by creating a symlink of it into the webserver’s additional configuration directory:
# ln -s /opt/otrs/scripts/apache2-httpd.include.conf /etc/httpd/conf.d/otrs.conf
- We need to check if every httpd module required is loaded:
# apachectl -M | grep -E 'version|deflate|filter|headers' deflate_module (shared) ext_filter_module (shared) filter_module (shared) headers_module (shared) version_module (shared)
- We’ll use another script shipped with the package to set file permissions:
# /opt/otrs/bin/otrs.SetPermissions.pl Setting permissions on /opt/otrs-6.0.14
- We are ready to start the database and the webserver:
# systemctl start postgresql # systemctl start httpd
- To configure the application, we’ll use the web installer provided. We point a browser to the target machine’s hostname or IP address, appended with
/otrs/installer.plto begin the installation. The application is presented by Apache httpd, which serves by default on port
80, so we don’t need to specify a port number. In our case, it will be
We’ll simply press
- We can read the License Agreement, and accept it to proceed.
- We need to choose the type of database to use. We’ll choose PostgreSQL, and leave “Create a new database for OTRS” checked.
- We need to provide the password for the
postgresuser (superuser from PostgreSQL perspective), and the address the database listening on. In our case, the lab machine’s database is listening on it’s (internally) public interface, but this is most likely will be
127.0.0.1, the loopback interface of the machine. One exception could be if we’d like to share the load between two machines, one hosting the database, the other running the webserver with the application. We need to provide an address according to our setup.
After providing the above information, we can press the testing button, and the application will try to connect to the database. If successful, the page is appended, and will look something like the following:
Here the application suggests a database name, a username, and a generated password. We can change any of them as we like.
- The installer should finish shortly with setting up the database.
- Next we can provide some general information, like the admin’s e-mail address and default language. We set CheckMXRecord to “no”, as in our case the lab environment does not have access to the public DNS servers at this point. Otherwise it would be advisable to leave it on “Yes” as it may save us from misspelling the address.
- The mail configuration page appears. We can provide mail servers if we plan on sending mail with OTRS (a common task for a ticketing system), or we can skip this step, it isn’t required to finish installation. We can set it up later.
- The installation is complete. We are presented with a username and generated password, as well as link that will direct us to the login page. We take note of these, as these are the low-level administrative user’s credentials, then continue to the login page.
- We provide the
root@localhostlogin credentials, and log into the application’s web interface.
- We arrive to the dashboard of the application, and we can begin to fill it with content and customize it according to our needs. Our first ticket already waits us, which will be a welcome ticket with some useful links.