DESIGNING OF REQUEST TRACKER FOR CLOUD

RESOURCES AND INTRANET

By: Tanmay Jhunjhunwala (IIT Delhi)

Under The Guidance of: Dr. SHAKTI MISHRA (Assistant Professor) IDRBT, Hyderabad

Acknowledgement Any accomplishment requires the effort of many people and there are no exceptions. The report being submitted today is a result of collective effort. Although the report has been solely prepared by me with the purpose of fulfilling the requirements of the institute IDRBT; there are innumerous helping hands behind it who have guided me on my way. I wish to express my profound gratitude to my Guide Dr.Shakti Mishra for giving me opportunity to do this project in the Institute for Development and Research in Banking Technology. The supervision and support that she gave truly help the progression and smoothness of the internship program. The co-operation is much indeed appreciated.

Project would have been nothing without the enthusiasm and imagination from our teaching assistants at IDRBT, Mr. Santosh Kumar, Mr.Sashi and Ms.Gayatri Hari Priyanka.

Last but not least I would like to thank other trainees at IDRBT for nurturing my confidence.

Tanmay Jhunjhunwala

Certificate

This is to certify that Mr. Tanmay Jhunjhunwala, pursuing Integrated Mtech course at Indian Institute of Technology, Delhi in Mathematics and Computing has undertaken a project as an intern at IDRBT, Hyderabad from May 13, 2013 to July 12, 2013. He was assigned the project “Designing of Request Tracker for Cloud Resources and Intranet” under my guidance.

I wish him all the best for all his endeavors.

(Dr. Shakti Mishra)

Project Guide Assistant Professor

IDRBT, Hyderabad

Contents

1. Introduction ...................................................................................................... 5

2. Project Description .......................................................................................... 6

2.1 Project Workflow………………………………………………7 2.2 List of Open-source Projects…….…………………………….8

3. OTRS-Introduction .......................................................................................... 9

3.1 Basic Features………………………………………………...11 3.2 Components Involved………...……………………………....11 3.3 The Administrators Panel…………………………………….13

4. Implementation Details .................................................................................. 14

4.1 Hardware Requirements ...…………………………………...14 4.2 Software Requirements…………………………………….…14 4.3 Requirement Specifications…………………………………..15

5. Customization of OTRS for IDRBT .............................................................. 17

5.1 Using existing LDAP directory to authenticate agents……….17 5.2 Adding customers from an active directory…………………..19 5.3 Implementing single-on………………………………………21 5.4 Adding new skins…………………………………………….22 5.5 Changing logos and text on the front end…………………….22

6. Conclusion ..................................................................................................... 23

7. Web References ............................................................................................ 24

Introduction

Request Tracker is a software/application through which one can create, revert and check the tickets (requests or complaints) of users, customers and agents. It has widespread use in institutions, companies, schools, hospitals, NGO’s etc. to track the requests of customers/users and handle them properly and subtly. Users and customers generate tickets and agents handle them, agents can also generate tickets/requests which would be handled by some other agent or admin. Different types of requests coming in need to be handled by different groups of agents. Additionally each request/complaint has a different priority. Thus the tracking application should direct the incoming tickets to the relevant agents, allow them to reply to them and address them in an organized manner. Further request tracker have plethora of additional functionalities like tickets can be moved from agent to another, escalation of tickets if it is not handled on time and many more. These functionalities depends on our requirements whether we want to add them or not and that’s how we can customize and develop a request tracker as per our thirst. Request tracker is deployed over the server and can easily be accessed by internal users as well as external customers. Of course, this is only a short preview of the possibilities and features of trouble ticket systems. But if your company has to attend to a high volume of customer requests through emails and phone calls, and if different service representatives need to respond at different times, a request tracking system can be of great assistance. It can help streamline work flow processes, add efficiencies, and improve your overall productivity. A ticket system helps you to flexibly structure your Support or Help Desk environment. Communications between customers and service staff become more transparent. The net result is an increase in service effectiveness. And no doubt, satisfied customers will translate into better financial results for your company.

Chapter 1 Project Description

Different organizations and institutes have different hierarchy and management system; hence the priorities, hierarchy and queues are varied. Our project goal was to design and develop a request tracker for the IDRBT institute with all the requirements infused in it. Request Tracker serves mainly three purposes here i.e. for cloud resources and virtualization as well as for the local intranet requests. IDRBT have its own cloud setup, so many clients mainly government and semi government banks requests for cloud services and resources. Virtualization related requests such as request for VM images also become a big domain of requests. Local intranet requests mainly take care of all the requests with in an institute like HR related requests, electricity or hardware problem, or any other request employees and people of the institute are facing. Hence three main classifications of queues and agents have to be executed. If one doesn’t have an automated and organized system to handle this myriad number of requests it will cause deadlocks and splurge a lot of resources. Thus a need of request tracker was very much needed by the institute to handle these requests. SRS was developed with the help of senior technology expert here at the institute and all the requirements were carried out to be delivered till the end of our project. Finally, an open source application OTRS was selected. OTRS is one of the most widely used tracker systems. This open source code was modified to meet the needs and requirements of IDRBT and was tailored so that it is completely ready to be integrated into the existing web portal of IDRBT and used by agents and users.

1.1. Project Workflow

It was decided that first an open-source request tracker application will be chosen and then modified. This serves mainly two purposes:

a) There is no need to build the basic functionalities and GUI. b) Modification of these open-source applications is manageable and we can customize

them as per our requirements.

The next step was to decide on an open-source project that could serve the needs and requirements; keeping in mind its popularity, support group, usage, amendments and many other attributes.

Finally OTRS – An open-source project on request tracker with a wide integration of all useful functions was chosen. Its complete description is followed further.

Further the requirements (SRS) given by IDRBT and additional features were added into the OTRS application.

The last step was of setting OTRS up on a local-server.

1.2. List of Open-source Projects

There are many “open-source request tracker “projects available written in almost all languages like Perl, python, C, C#, java, PHP, ASP.NET, etc. List is exhaustive, but few popular ones are depicted below:

Open-source Description

aDefHelpDesk - An open source based on ASP.NET.

Asset Tracker- Can create multiple asset databases containing any information to be tracked. Some examples: putting entire IT infrastructure into the database, or for a building manager, putting all the facilities equipment in the database.

Big Help- A help desk portal built with Ruby on Rails.

Bugzilla - A Perl based software bug tracking system which can also be used for help desk support. Used by the Mozilla Foundation, creators of FireFox.

Google Apps Help Desk Workflow-

A simple script for giving any Google Apps account a help desk workflow.

Information Resource Manager-

IRM is a PHP based help desk and asset tracker designed for IT departments.

jHelpdesk- A Java/JSP based open source corporate help desk system.

OTRS A trouble ticket system to track telephone call and emails. Designed to allow support, sales, pre-sales, billing, internal IT, and helpdesk to operate in one system. OTRS is open sourced under the A-GPL and is written in Perlscript.

Trac

Minimalistic web based project management and bug tracking tool. Trac also includes wiki functionality. It is written in Python language.

After considering many pros and cons, OTRS was selected. The underlying reasons and its features are discussed in the next chapter.

Chapter 2 OTRS-Introduction

2.1. Basic Features:

• Web interface: Easy and initial handling with any modern web browser, even with mobile phones or other mobile computers.

• A web interface to administer the system via the web is available. • A web interface to handle customer requests by employees/agents via the web is

integrated. • A web interface for customers is available to write new tickets, check the state and

answer existing tickets and search through their own tickets. • The web interface can be customized with different themes; own themes can be

integrated. • Support for many languages. • The appearance of output templates can be customized (dtl). • Mails from and into the system can contain multiple attachments.

2.2. Components involved in OTRS

Mail interface: • Support for mail attachments (MIME support). • Automatic conversion of HTML into plain text messages (increased security for sensitive

content and enables faster searching). • Mail can be filtered with the X-OTRS headers of the system or via mail addresses, e.g.

for spam messages. • PGP support, creation and import of own keys, signing and encrypting outgoing mail,

signed and encrypted messages can be displayed. • Support for viewing and encrypting S/MIME messages, handling of S/MIME certificates. • Auto answers for customers, configurable for every queue. • Email notifications for agents about new tickets, follow-ups or unlocked tickets. • Follow-ups by references or In-Reply-To header entries.

Tickets:

• Any complaint/request generates its own unique ticket. • Tickets can be locked. • Creation of own auto response templates. • Creation of own auto responders, configurable for every queue. • Ticket history, overview of all events for a ticket (changes of ticket states, replies, notes,

etc.).

• Print view for tickets. • Adding own (internal or external) notes to a ticket (text and attachments). • Ticket zooming. • Access control lists for tickets can be defined. • Forwarding or bouncing tickets to other mail addresses. • Transferring tickets between queues. • Setting or changing the priority of a ticket. • The working time for every ticket can be counted. • Up-coming tasks for a ticket can be defined (pending features). • Bulk actions on tickets are possible. • Automatic and timed actions on tickets are possible with the "GenericAgent".

Administrator: • Can make/remove agents/users and edit their rights. • Can make groups/queues/salutation etc and link them to users/agents. • Can change rights and access areas of agents. • Has access to all ticket information and history.

Agents:

• Limited rights. (Can be admin also) • Job is to address all tickets coming to the system. • Have access only to tickets/queues which are relevant to them. • Can change status of tickets, move tickets among queues etc.

Users:

• Can login using user login portal. • They can generate tickets, track them, edit them etc. • They can choose which queue should their ticket go to and request follow up on previous

closed tickets. • Can be put into groups so that it is easier to give them access to specific queues. • Can belong to a company and thereby can see tickets from different users of the same

company.

Queues: • All the incoming tickets can be organized into different queues. • Different agents have access to specific queues they are concerned with. • Users can be given permission to send tickets to particular queues. • Tickets can be moved among queues by agents who have permission to do so. • There can be sub-queues within queues for another level of filtering.

2.3. The Administrator’s Panel

All the customizations, settings for agents, customers, queues etc and other customizations of the OTRS interface are done using the administrator’s panel. Screenshot of the panel is shown below.

Figure 1: The Admin Panel

Responses: • We can have standard responses. • Responses can be linked to specific queues. This helps in having standard response for all

tickets. • Attachments can be defined separately. • Multiple attachments can be associated with the same response and vice versa. • Before being sent we can edit responses. • There is option of sending automatic responses. For example a mail saying your request

has been recorded for each ticket.

System:

• OTRS runs on many operating systems (Linux, Solaris, AIX, FreeBSD, OpenBSD, Mac OS 10.x, Microsoft Windows).

• ASP support (active service providing). • Linking several objects is possible, e.g. tickets and FAQ entries. • Integration of external back-ends for the customer data, e.g. via AD, eDirectory or

OpenLDAP. • Setting up an own ticket identifier, e.g. Call#, Ticket# or Request#. • The integration of your own ticket counter is possible. • Support of several database systems for the central OTRS back-end, e.g. MySQL,

PostgreSQL, Oracle, MSSQL). • Framework to create stats. • utf-8 support for the front- and back-end. • Authentication for customers via database, LDAP, HTTPAuth or Radius. • Support of user accounts, user groups, and roles. • Support of different access levels for several systems components or queues. • Integration of standard answer texts. • Support of sub queues. • Different salutations and signatures can be defined for every queue. • Email notifications for admins. • Information on updates via mail or the web interface. • Escalation for tickets. • Support for different time zones. • Simple integration of own add-ons or applications with the OTRS API. • Simple creation of own front-ends, e.g. for X11, console.

Chapter 3 Implementation Details

3.1. Hardware Requirements:

OTRS can be installed on many different operating systems. OTRS can run on linux and on other unix derivates (e.g. OpenBSD or FreeBSD). You can also run it on Microsoft Windows. OTRS does not have excessive hardware requirements. We recommend using a machine with at least a 2 GHz Xeon or comparable CPU, 2 GB RAM, and a 160 GB hard drive for a small setup. To run OTRS, you'll also need to use a web server and a database server. Apart from that, you should install perl and/or install some additional perl modules on the OTRS machine. The web server and Perl must be installed on the same machine as OTRS. The database back-end may be installed locally or on another host. For the web server using the Apache HTTP Server is recommended, because its module mod_perl greatly improves the performance of OTRS. Apart from that, OTRS should run on any web server that can execute Perl scripts. OTRS can be deployed on different databases. There is choice between MySQL, PostgreSQL, Oracle, or Microsoft SQL Server. Using MySQL has the advantage that the database and some system settings can be configured during the installation, through a web front-end. For Perl, it is recommended to use at least version 5.8.8 or higher. Some additional modules which can be installed either with the Perl shell and CPAN, or via the package manager of the operating system (rpm, yast, apt-get) are also needed according to the usage.

3.2. Software Requirements:

1. Perl support a. Perl 5.8.8 or higher

2. Web server support a. Apache2 + mod_perl2 or higher (recommended, mod_perl is really fast!) b. Webserver with CGI support (CGI is not recommended) c. Microsoft Internet Information Server (IIS) 6 or higher

3. Database support a. MySQL 5.0 or higher b. PostgreSQL 7.0 or higher (8.2 or higher recommended) c. Oracle 10g or higher d. Microsoft SQL Server 2005 or higher

4. Web browser support

a. Internet Explorer 8.0 or higher (agent interface) b. Internet Explorer 7.0 or higher (customer interface) c. Mozilla Firefox 3.6 or higher d. Google Chrome e. Opera 10 or higher

3.3. Requirement Specifications (SRS)

• Tickets can be created, updated, reverted and escalated as per the need of users, agents and admin. • Tickets should be routed to queues based on ticket type and queue chosen.

• Request/Tickets are generated for mainly three macro-purpose :

• Local Intranet use (In Institute) a) HRM related requests. b) Infrastructure related ………etc.

• Cloud Resources a) Requests for VM’s, servers, bandwidth, storage space, backup disks

…..etc. b) Payments request.

• Virtualization a) Requests for virtual images.

(Bases on these requests, formation of queues<<>>roles, agents<<>>queues and agents<<>>roles depends)

• Requests can be generated by the users through the OTRS portal or by sending a mail also. So, whenever a request through mail is sent; a reverted mail should be send to the user-id (automatically without any agent or admin interface) and also updating the ticket in user’s account in OTRS portal (if exists).

• Queues Functionalities : • Separate queues for three main classifications. • More sub queues under three main queues. • Agents can move request to any of the sub-queues (if possible).

• Agents Functionalities :

• Agents must be exclusively as per queues. Agents <<>>Queues must be defined properly and no overlapping must be there for three main classification.

• Agents<<>>groups must be defined within a main category. • Escalation of requests/tickets as per the hierarchy of agents described in the OTRS

system in compliance with the institute hierarchy; from time to time (if unchecked by one agent) and user can see the status of escalation of his ticket.

• System should support at least 3 level of escalation. • Escalation should go as an SMS/Email alert. • Contact details of escalation points should be maintained.

• Integration with LDAP/Active Directory. There would also be users accessing

through user id and password.

• OTRS should be replaced with IDRBT. Look and feel should also be reflecting IDRBT internet site.

• System must support Queue Managers. Agents of one queue could be queue manager for other queues. Agents can be users and vice versa raising tickets.

Chapter 4 Customization of OTRS for IDRBT

OTRS has almost all the features of a well-developed request tracker. However before setting it up and using it in IDRBT, we had to come some modifications in the code in order to customize it for its use here and to ensure easy adaptation and integration into the existing web services in IDRBT. Some of the features added are:

1) Using existing LDAP directory to authenticate agents. 2) Adding customers from an active directory 3) Implementing single-on. 4) Adding new skins resembling IDRBT’s existing web interface. 5) Changing logos and text on the front end.

These have been described in detail, along with the changes/additions required in the code in the following sections:

4.1. Using LDAP directory to authenticate agents

If we have a LDAP directory where all the agent data is stored, we can use it to authenticate the agents in OTRS. This can be achieved easily by using a LDAP Perl module (available easily on the internet) and requires certain additions in the Perl code. Adding this feature has many advantages: ADVANTAGES:

• There is no need to add each agent individually using the OTRS interface. • Agents can use their existing username and password on OTRS and don’t have to

choose a new username and password. • The LDAP module being used (described below) has only read-access to the LDAP

tree, thus the data cannot be edited through the OTRS interface and thus remains protected.

• This also facilitates implementing single-on (which is useful when many different portals need to accessed simultaneously).

IMPLEMENTATION:

First we need to ensure that LDAP libraries are installed on the server (for details refer to http://doc.otrs.org/3.1/en/html/manual-installation-of-otrs.html). Then we need to edit the Config.pm file (path: /ours/Kernel/Config.pm). Add the following piece of code in the space provided for changes by users.

PERL CODE:

# (Make sure Net::LDAP is installed!) $Self->{'AuthModule'} = 'Kernel::System::Auth::LDAP'; $Self->{'AuthModule::LDAP::Host'} = 'ldap.example.com'; $Self->{'AuthModule::LDAP::BaseDN'} = 'dc=example,dc=com'; $Self->{'AuthModule::LDAP::UID'} = 'uid'; # Check if the user is allowed to auth in a posixGroup # (e. g. user needs to be in a group xyz to use otrs) $Self->{'AuthModule::LDAP::GroupDN'} = 'cn=otrsallow,ou=posixGroups,dc=example,dc=com'; $Self->{'AuthModule::LDAP::AccessAttr'} = 'memberUid'; # for ldap posixGroups objectclass (just uid) # $Self->{'AuthModule::LDAP::UserAttr'} = 'UID'; # for non ldap posixGroups objectclass (with full user dn) # $Self->{'AuthModule::LDAP::UserAttr'} = 'DN'; # The following is valid but would only be necessary if the # anonymous user do NOT have permission to read from the LDAP tree $Self->{'AuthModule::LDAP::SearchUserDN'} = ''; $Self->{'AuthModule::LDAP::SearchUserPw'} = ''; # in case you want to add always one filter to each ldap query, use # this option. e. g. AlwaysFilter => '(mail=*)' or AlwaysFilter => '(objectclass=user)' $Self->{'AuthModule::LDAP::AlwaysFilter'} = ''; # in case you want to add a suffix to each login name, then # you can use this option. e. g. user just want to use user but # in your ldap directory exists user@domain. $Self->{'AuthModule::LDAP::UserSuffix'} = '@domain.com'; # Net::LDAP new params (if needed - for more info see perldoc Net::LDAP) $Self->{'AuthModule::LDAP::Params'} = { port => 389, timeout => 120, async => 0, version => 3, };

4.2. Adding customers from an active directory

Instead of adding username, password and all other details of each customer one by one to OTRS, we can populate the customer database along with login details by using information from existing active directory (LDAP directory). This uses the same perl module for LDAP which we used while authenticating agents and requires some more additions to the perl code. ADVANTAGES:

• Customers do not need to go through the process of registering and entering all their information on OTRS

• Authenticity of the customer information is guaranteed as the details are filled using existing data.

• The LDAP module being used has only read-access to the LDAP tree, thus the customers cannot edit it using the OTRS interface.

• Additionally it also has all the advantages mentioned in agent authentication section.

IMPLEMENTATION:

If LDAP is already being used to authenticate agents then there is no need to download any module otherwise perl module for LDAP needs to be installed on the server (for details refer to http://doc.otrs.org/3.1/en/html/manual-installation-of-otrs.html). After ensuring that this module is available the Config.pm file (path: /otrs/Kernel/Config.pm) needs to be edited. Add the following piece of code in the space provided for changes by users.

PERL CODE

# (make sure Net::LDAP is installed!) $Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::LDAP'; $Self->{'Customer::AuthModule::LDAP::Host'} = 'ldap.example.com'; $Self->{'Customer::AuthModule::LDAP::BaseDN'} = 'dc=example,dc=com'; $Self->{'Customer::AuthModule::LDAP::UID'} = 'uid'; # Check if the user is allowed to auth in a posixGroup # (e. g. user needs to be in a group xyz to use otrs) $Self->{'Customer::AuthModule::LDAP::GroupDN'} = 'cn=otrsallow,ou=posixGroups,dc=example,dc=com'; $Self->{'Customer::AuthModule::LDAP::AccessAttr'} = 'memberUid'; # for ldap posixGroups objectclass (just uid) $Self->{'Customer::AuthModule::LDAP::UserAttr'} = 'UID'; # for non ldap posixGroups objectclass (full user dn) #$Self->{'Customer::AuthModule::LDAP::UserAttr'} = 'DN'; # The following is valid but would only be necessary if the # anonymous user does NOT have permission to read from the LDAP tree $Self->{'Customer::AuthModule::LDAP::SearchUserDN'} = '';

$Self->{'Customer::AuthModule::LDAP::SearchUserPw'} = ''; # in case you want to add always one filter to each ldap query, use # this option. e. g. AlwaysFilter => '(mail=*)' or AlwaysFilter => '(objectclass=user)' $Self->{'Customer::AuthModule::LDAP::AlwaysFilter'} = ''; # in case you want to add a suffix to each customer login name, then # you can use this option. e. g. user just want to use user but # in your ldap directory exists user@domain. $Self->{'Customer::AuthModule::LDAP::UserSuffix'} = '@domain.com'; # Net::LDAP new params (if needed - for more info see perldoc Net::LDAP) $Self->{'Customer::AuthModule::LDAP::Params'} = { port => 389, timeout => 120, async => 0, version => 3, };

4.3. Implementing Single Sign-on

Single sign-on (SSO) is a property of access control of multiple related, but independent software systems. With this property a user logs in once and gains access to all systems without being prompted to log in again at each of them. Conversely, Single sign-off is the property whereby a single action of signing out terminates access to multiple software systems. Thus implementing SSO in OTRS can be of great help if we want to merge many internal portals together and don’t want agents to be signing in and out of all of them independently.

ADVANTAGES:

• The biggest advantage is that it saves the hassle of logging in and out again and again as we navigate from one portal to another.

• It also saves the agents the effort of remembering multiple usernames and passwords. • Can be useful in saving the effort of registering each user in each platform

independently.

IMPLEMENTATION:

Implementing single-on in OTRS is quite a simple task. We need to use the HTTPBasicAuth module with OTRS. This module can be easily downloaded from perl libraries (for details refer to http://doc.otrs.org/3.1/en/html/manual-installation-of-otrs.html). Once we have this module small additions need to be made in the Config file (path: /otrs/Kernel/Config.pm).

PERL CODE:

#This is the configuration for an apache auth. backend. It enables you to have a single #login through apache http-basic-auth $Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::HTTPBasicAuth'; # Also we need the following config settings as fallback, if user isn't login through #apache. $Self->{CustomerPanelLoginURL} = 'http://host.example.com/not-authorised-for-otrs.html'; $Self->{CustomerPanelLogoutURL} = 'http://host.example.com/thanks-for-using-otrs.html';

4.4. Adding new skins to change the frontend

In order to use OTRS in IDRBT the presence of many features is definitely most important but with that it should also have the look and feel of IDRBT so that it can merge well with the existing web portals of IDRBT. Thus it is very important and essential to make and use customized skins (defining colors, styles, font, font size etc) in OTRS.

STEPS:

First we need to understand how OTRS loads its skins (By loads I mean puts tags to the HTML content which cause the CSS files to be loaded by the browser). All skins in OTRS are in /var/httpd/htdocs/skins/$SKIN_TYPE/$SKIN_NAME. There is one predefined skin called default that loads if no other skin is defined. Further there are two types of skins in this location:

• Agent skins: Each agent has the choice was choosing which skins he wants to wear. • Customer skins: All customers use the same predefined skin.

In OTRS always the default skin is loaded first and if the agent has chosen some other skin then it will load after that. Thus we need to keep few things in mind:

• While designing custom themes the names of each file needs to be same as its name in the default skin folder.

• While defining a new theme it is not required to redefine each file. We only need to define those features that we want to change and rest will be picked up from the default skin.

• However we need to be careful that we overwrite all the rules we want to change and don’t miss any by chance.

EXAMPLE:

As an example I have explained how to change the default background color of the OTRS agent interface from white to grey:

• First we need to create a new folder for this skin (say “custom”). This will be placed in the folder /var/httpd/htdocs/skins/Agent.

• Now we need to place a new CSS file in this directory while will define the “custom” skin’s appearance. It has to be called Core.Default.css to keep its name same as one of the files in the “default” skin.

• Now this code needs to be written in the CSS file: body { background-color: #d0d0d0 }

• Finally we need to activate this new skin from the administrator’s area of OTRS. (Alternatively we can also run the script /bin/otrs.RebuildConfig.pl)

4.5. Changing the logos to company logo Even after changing the look and skin of OTRS, it is important to remove the default logos of OTRS and use logos of IDRBT in their place. This process is very simple. All logos being used in OTRS are saved in /var/httpd/htdocs/skins/Agent/default/img and /var/httpd/htdocs/skins/Customer/default/img. Thus we need to replace these by logos of IDRBT or delete them so that they don’t show up in the user frontend. Screenshots of customer and agent login pages after putting up the logo of IDRBT are shown on the next page.

CUSTOMER and AGENT LOGIN PAGE

Figure 1: Customer login page

Figure 2: Agent Login Page

Figure 2: Customer login page

Figure 3: Agent Login Page

Conclusion

OTRS application in all has more than 9000 files comprising of Perl modules, CSS, html files. Going through these files again and again for changing a particular code for a particular requirement is the toughest part, although managed to change a lot code for our benefit. Forking an open source project is always a difficult task. Finally, in this project a single interface for local intranet as well as cloud purposes and virtualization has been developed as per the requirements of IDRBT and deployed it on a server in IDRBT (still in testing phase not available to outside users/customers). Thus all the requests or complaints regarding cloud resources, virtualization and all the internal requests will be handled in an organized way. Now users will have the freedom to choose which kind of request they want to post. Customers with in a company have privileges to see each other request. Also the requests will reach the concerned person/agent in a regulated manner as agent and queues roles are well defined, this will reduce a lot of time of customers and thus agents can handle the requests effectively and timely. Patent digital signatures, PGP certificates and S/MIME certificates from the institute are added to the OTRS application thus strengthening the security issues. Full testing against all the security breaches still remains a task to fulfill.

Web References (as accessed on 12th July 2013)

1. http://doc.otrs.org/3.2/en/html/ 2. http://www.opensourcehelpdesklist.com/ 3. http://www.otrs.com/en/ 4. http://en.wikipedia.org/wiki/Request_Tracker 5. http://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol 6. http://www.openldap.org/ 7. http://doc.otrs.org/3.0/en/html/auth-backends.html 8. doc.otrs.org/3.0/en/html/auth-backends.html 9. http://www.tutorialspoint.com/perl/ 10. http://learn.perl.org/tutorials/ 11. https://en.wikipedia.org/wiki/Single_sign-on 12. https://developers.google.com/google-apps/sso/saml_reference_implementation 13. https://github.com/OTRS/otrs