OTRS installation on RHEL 8

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

OTRS dashboard first login on RHEL 8 Linux

Software Requirements and Conventions Used

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).

1. 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 /opt directory on the target machine, and use wget:

   # cd /opt
   # wget http://ftp.otrs.org/pub/otrs/otrs-6.0.14.tar.bz2

---

---

2. We extract the archive:

   # tar -xvf otrs-6.0.14.tar.bz2

   And create a symlink called /opt/otrs that points to the now created directory:

   # ln -s /opt/otrs-6.0.14 /opt/otrs

3. Naturally we’ll need perl, httpd, and mod_perl that enables the webserver to run perl code:

   # dnf install procmail httpd mod_perl perl perl-core

4. 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::ODBC to 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 
   

   

   Solving perl module dependencies with otrs.CheckModules.

   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::Pg module, because we will use PostgreSQL as backend. Some of these packages are available to install with dnf:

   # dnf install "perl(Date::Format)"

   The rest can be installed with cpan:

   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.

5. We create the user that will be the owner of the /opt/otrs directory:

   # useradd otrs

   And add it to the apache group (which is the group of apache user 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)

6. 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

7. 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

8. 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)

---

---

9. 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

10. We are ready to start the database and the webserver:

    # systemctl start postgresql
    # systemctl start httpd

11. 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.pl to 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 192.168.1.14/otrs/installer.pl.
    

    OTRS Installer, starting page.

    We’ll simply press Next to continue.

12. We can read the License Agreement, and accept it to proceed.
    

    OTRS License Agreement.
13. We need to choose the type of database to use. We’ll choose PostgreSQL, and leave “Create a new database for OTRS” checked.
    

    Choosing database type.
14. We need to provide the password for the postgres user (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:
    

    Setting up the database.

    Here the application suggests a database name, a username, and a generated password. We can change any of them as we like.

---

---

15. The installer should finish shortly with setting up the database.
    

    Database setup successful.
16. 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.
    

    General information page.
17. 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.
    

    Mail configuration.
18. 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.
    

    Installation finished.
19. We provide the root@localhost login credentials, and log into the application’s web interface.
    

    OTRS Login page.
20. 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.
    

    OTRS dashboard on first login.