In this post I will show how to create a simple approval queue in Request Tracker 3.8.

The General queue will be used as the approval queue.

Here are the different entities (groups) we will create:

• Submitters: they can submit new tickets only to the General Queue.
• Approvers: they can approve tickets (move them from the general queue to another queue)

I will also show how to add a new dashlet ("RT at a glance") containing all the tickets the user created ("My issues").

Permissions and Rights

In preferences, make sure the General queue is the default queue.

Create your other queues as needed.

First, we'll allow all requestors (person who created/initiated a new ticket) to see all tickets they created and also be able to reply to them. In Configuration > Global > Group rights, for the Requestors group add the following rights:

• ShowTicket
• ReplyTicket

Submitters

In Configuration > Groups > Create, create a group called "Submitters".

To allow the submitters to create new tickets to the general queue, go to Configuration > Queues open the General queue, click on Group Rights (top menu), add the following rights to the "Submitters" group:

• SeeQueue
• ShowTicket
• CreateTicket

For the submitters to be able to see their tickets (which they created) after they have been moved to another queue, they need some READ rights on all other queues. Go to Configuration > Queues, for each queue, add the following Group Rights to the Submitters group:

• SeeQueue
• ShowTicket

Approvers

In Configuration > Groups > Create, create a group called "Approvers".

We need to allow the Approvers to see and create tickets in every queue, go to Configuration > Queues and for each queue click on Group Rights (top menu), add the following rights to the "Approvers" group:

• SeeQueue
• ShowTicket
• CreateTicket

Now they need to be able to modify tickets that are in the General Queue, go to Configuration > Queues > General click on Group Rights (top menu), add the following rights to the "Approvers" group:

• SeeQueue
• ShowTicket
• CreateTicket
• ModifyTicket

Dashlet for "My Issues"

Now we allow the privileged users to use saved searches and dashboards: in Configuration > Global > Group Rights, find the "Privileged" group and add the following rights:

• LoadSavedSearch
• ModifyOwnDashboard
• ShowSavedSearches
• SubscribeDashboard

In Tickets go to Advanced (top menu), copy and paste the following query in the first textfield:

(Creator = '__CurrentUser__')

Click on Edit Search (top menu), tweak the search as necessary. When done, save it as an RT's system saved search (in the dashlet called "Saved searches"). Pick a name ("My Issues" for example).

Then we need to the change the default RT at a glance, go to Configuration > Global > RT at a glance

In RT at a glance: body, on the left column select your saved search ("My Issues") and click the right arrow. Then in the right column, you can move your dashlet up and down.

Conclusion

Now you can add new users and assign them to the Submitters group or the Approvers group, or even both.
Submitters can create new tickets and still see them if they are moved to another queue or changed ownership.
Approvers can move tickets from the General queue to other queues.
Every privileged user should now see the "My issues" dashlet on their dashboard.

Of course, I am giving the strict minimum amount of rights necessary to achieve this, but you are free to add more rights (e.g. add the Watch right, or ReplyTicket right to Approvers) if you need them

Apache2 offers this feature through its mod_expires module. Note that this module is usually disabled by default, meaning your visitors would download all the files over again each time they change the page.

• First, to activate mod_expires, type this in a terminal:

  sudo a2enmod expires

• Then, we need to tell Apache2 which files can have an expire header. You can add this in your vhost configuration or your main apache2 configuration file you want it to apply to every vhost:

  ExpiresActive On
  ExpiresByType image/gif "access plus 7 days"
  ExpiresByType image/jpeg "access plus 7 days"
  ExpiresByType image/png "access plus 7 days"
  ExpiresByType image/x-icon "access plus 3 months"
  ExpiresByType image/ico "access plus 3 months"
  ExpiresByType text/css "access plus 2 days"

• Remember to restart Apache2:

  sudo service apache2 restart

• You can look at the headers sent by your webserver using HEAD (on a linux machine) like so:

  HEAD http://www.codealpha.net/wp-content/themes/notso_freshe/images/header.gif

Click here to participate and help to create a Q&A site for Ubuntu!

Introduction

This tutorial is mainly oriented to Ubuntu, but can also be applied to other distributions such as Debian.

The minimum requirements for SNI to work are Apache 2.2.12 (or higher) with OpenSSL 0.9.8g (or higher).

Make sure you already have your website(s) set up and running (non-SSL of course!) and listening on another port than 443 as we will use this port for SSL.

Installation of packages

We need to activate the Apache2 SSL module in order to serve websites over SSL:

sudo a2enmod ssl

Also, the ssl-cert package will allow us to create certificates in a few keystrokes:

sudo apt-get install ssl-cert

If you don't have ssl-cert available in your distribution's package manager, you can find it here: http://packages.debian.org/sid/ssl-cert

Creating certificates

We will now create a self-signed SSL certificate.

When using make-ssl-cert, both the certificate and the private key are generated and stored within the same file. The generated *.crt file needs to be kept somewhere safe on your disk, it is a good practice to move it to /etc/ssl/privateand use chmod 600 and chown root:root. It should be readable by root only!

sudo make-ssl-cert /usr/share/ssl-cert/ssleay.cnf \
/etc/ssl/private/mydomain.crt

It should ask you for a hostname, enter the exact domain name of the website (e.g. if you want to use https://www.myexampledomain.com then put www.myexampledomain.comas
hostname).

Enabling name-based SSL virtual hosts

Apache2 needs to know that our virtual hosts using SSL will be matched using a name-based matching rule (instead of IP-based) and also that it needs to listen for SSL connections on port 443.

Open the Apache2 ports config file, located at /etc/apache2/ports.conf and add:

NameVirtualHost *:443

It should look similar to this:

NameVirtualHost *:80
NameVirtualHost *:443
 
Listen 80
 
<IfModule mod_ssl.c>
    Listen 443
</IfModule>

Make surethere is Listen 443 somewhere in this file, in order to tell Apache2 to listen on this specific port for SSL connections.

Creating the virtual hosts configuration file

Important Note:
Note that not all browsers support SNI. For those without SNI support they will be redirected to the first SSL vhost defined (which is usually the first alphabetically in the /sites-enabled/ folder) in
the Apache2 configuration.
Also, it is good to know that in their browser, they will see the domain name that they typed in instead of the actual vhost's domain name, as a consequence the certificate will not be validated as it will not match the domain shown in their browser. As an alternative you can use SSLStrictSNIVHostCheck, see note below.

The best thing to do is to copy the normal configuration file of your website (with normal http:// access) and add the SSL directives.

First, make a copy:

sudo cp /etc/apache2/sites-available/{mywebsite.conf,mywebsite_ssl.conf}

Then open the mywebsite_ssl.conf file, and add/modify the bold parts:

<VirtualHost *:443>
 ServerName www.myexampledomain.com 
 
 SSLEngine On
 SSLCertificateFile /etc/ssl/private/myexampledomain.crt 
 
 DocumentRoot /var/www/myexampledomain
</VirtualHost>

Explanation:

“*:443” along with ServerName define this configuration as a name-based virtual host.

“SSLEngine On” enables SSL for this virtual host.

“SSLCertificateFile”points to the certificate we created earlier.

Note:
Using SSLStrictSNIVHostCheckit will refuse non SNI capable browsers to access any website on your server using SSL.
This directive sets
whether a non SNI client is allowed to access a name based virtual host. If set to on in the non default name based virtual host, non SNI clients are not allowed to access this particular virtual host. If set
to on in the default name based virtual host, non SNI clients are not allowed to access any name based virtual host belonging to this IP / port combination. (http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#SSLStrictSNIVHostCheck)

Enabling the virtual host

We need to enable the virtual host, this is an important step which is often forgotten:

sudo a2ensite mywebsite_ssl.conf

Testing

Restart Apache2:

sudo service apache2 restart

This is time for a test, visit your website over SSL, make sure you prepend https:// to your domain name (for example https://www.myexampledomain.com)

Troubleshooting

If you cannot see your website using https you can dig into the Apache2 logs (located at /var/log/apache2/error.log) and search for [error] or [warn].

Also be certain to have activated/enabled all of the virtual hosts you want by typing sudo a2ensite yourdomain.conf and then reload or restart Apache2.

If you get a “ssl_error_rx_record_too_long” error, it can mean either SSL is not activated properly for this virtual host (check that there is SSLEngine On in your vhost config) or the virtual host configuration is not enabled
(“sudo a2ensite vhostconfigfile”).

Notes

If you already have your own certificates, you will want to use both SSLCertificateKeyFileand SSLCertificateFilein the virtual host configuration file because certificate issuers usually give
you two different files (one containing a private key and the other one containing the certificate).

It is important to be aware that some browsers do not support SNI and will not be able to access your virtual hosts.

Some browsers in mobile devices might not support SNI so be certain that your default SSL virtual host can provide some help or support to those users, like for example offering the option to switch back to regular non-SSL connection.

If you wish to just backup all the users and privileges other than root and debian-sys-maint, you can use this command:

mysqldump -nt -uroot -p -w"User NOT LIKE 'root' AND User NOT LIKE 'debian%'" mysql user db > users_privs.sql

Here's an explanation of each of the options:

• -nt: Do not add "drop table" and "create table".
• -uroot -p: Connect as root and ask for a password
• -w...: Add a "WHERE" condition to each query. We exclude everything related to root and debian-sys-maint.
• mysql user db: Dump the user and db tables from the mysql database.
• > users_privs.sql: Store the sql dump into the users_privs.sql file.