msgbartop
MAC OS X, Linux, Windows and other IT Tips and Tricks
msgbarbottom

23 May 17 Disabling the admin security password confirmation in Jira and Confluence

Introduction:
Although in Jira and Confluence the WebSudo, requesting the confirmation of the administrator’s password, are neat security features if you are working in a company where the chances of someone fiddling around with your computer are high. BUT in a very small company, where this risk is almost none, this feature has proven very annoying for me. So I did some research to disable these features in both Jira and Confluence.

Assumptions:
Jira Version: 7.x
Confluence: 6.x

Methods:

In Jira:

– Edit the file /opt/atlassian/jira/atlassian-jira/WEB-INF/classes/jpm.xml
– Look for the property: jira.websudo.is.disabled and set all is values to true as follows:
.....
<property>
<key>jira.websudo.is.disabled</key>
<default-value>true</default-value>
<type>boolean</type>
<admin-editable>true</admin-editable>
<sysadmin-editable>true</sysadmin-editable>
</property>
......

In Confluence

– Edit the file /opt/atlassian/confluence/bin/setenv.sh
– Close to the end where there is a list of multiple components of the variable
CATALINA_OPTS=....
CATALINA_OPTS=....

– Add the following line after this list but before the line: export CATALINA_OPTS
CATALINA_OPTS="-Dpassword.confirmation.disabled=true ${CATALINA_OPTS}"

———-
Note: After these changes Jira and Confluence need to be restarted as follows:
service jira stop
service confluence stop
service jira start
service confluence start

16 May 17 Hardening the SSL security in Apache, Dovecot and Postfix

Introduction:

After having gotten a report from OpenVAS that my SSL security level of the mail server were medium, I looked for ways to improve this.
I found very good sites which helps me making these improvements:
https://weakdh.org/sysadmin.html
https://wiki.dovecot.org/SSL/DovecotConfiguration
https://bettercrypto.org/static/applied-crypto-hardening.pdf
Based on this site and extending to cover dovecot mail service here is the result:

Hardening Apache:

In /etc/apache2/mods-available/ssl.conf
Change the following parameters as follows:
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!DH+3DES:!RSA+3DES
SSLHonorCipherOrder on

Hardening Dovecot:

Note: you should have openssl >=1.0.0 dovecot >=2.1.x required, better dovecot >=2.2.x because of ECDHE support Dovecot tryies to use PFS by default, so besides the enabled SSL almost no actions are required change the log settings to see the cipher, grep for a login_log_format_elements in dovecot configs and add %k to it
eg:
login_log_format_elements = "user=< %u> method=%m rip=%r lip=%l mpid=%e %c %k"
Configure the allowed ciphers. Server side enforcement works only for dovecot >=2.2.6
In /etc/dovecot/conf.d/ssl.conf
Change some parameters as follows:
ssl_cipher_list = EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4
#only for dovecot >=2.2.6, enforce the server cipher preference
ssl_prefer_server_ciphers = yes
#disable SSLv2 and SSLv3
ssl_protocols = !SSLv2 !SSLv3

Add the following parameter:
ssl_dh_parameters_length = 2048
Delete the file /var/lib/dovecot/ssl-parameters.dat
and restart Dovecot service:
service dovecot restart
Dovecote seeing that the Diffie Hellman parameters are assigned to be 2048 bits long and that its file is just been deleted, will regenerate a new one in the background.

Hardening Postfix

In /etc/postfix/main.cf
Change or add the following configuration parameters:
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_ciphers=high
tls_high_cipherlist=EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA
smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, KRB5-DES, CBC3-SHA
smtpd_tls_dh1024_param_file=/etc/ssl/dh2048.pem

Generate a new Diffie Hellman parameters file as follows:
openssl dhparam -out /etc/ssl/dh2048.pem 2048

24 Feb 17 Whitelisting Hosts in Postfix/Amavis

Introduction:
I have an email server with very strong spam filtering and every now and then it does see the emails that I send from our own networks as SPAM.
In order to bypass the SPAM scanner for those networks without bypassing the virus scanning of Amavis I found these instructions in Internet at:
http://verchick.com/mecham/public_html/spam/bypassing.html#1

Allow clients on my internal network to bypass scanning by using the ‘MYNETS’ policy bank. You can use the built in ‘MYNETS’ policy bank to allow clients included in $mynetworks. Let’s assume you allow all (or most) clients on your internal network to send outbound mail through your spamfilter.
The IP addresses of these clients are included in Postfix’ $mynetworks in main.cf:
mynetworks = 127.0.0.0/8 !192.168.1.1 192.168.1.0/24
In /etc/amavis/conf.d/50-user @mynetworks determines which clients will use the ‘MYNETS’ policy bank:
@mynetworks = qw( 127.0.0.0/8 [::1] [FE80::]/10 [FEC0::]/10
!192.168.1.1 192.168.1.0/24 );

And you would configure the ‘MYNETS’ policy bank as desired:
Also added to /etc/amavis/conf.d/50-user
$policy_bank{'MYNETS'} = { # clients in @mynetworks
bypass_spam_checks_maps => [1], # don't spam-check internal mail
bypass_banned_checks_maps => [1], # don't banned-check internal mail
bypass_header_checks_maps => [1], # don't header-check internal mail
};

When using the “MYNETS’ policy bank, you must use *_send_xforward_command in master.cf which enables forwarding of the client’s IP address to amavisd-new.:
smtp-amavis unix - - n - 2 smtp
-o smtp_data_done_timeout=1200
-o smtp_send_xforward_command=yes
-o disable_dns_lookups=yes
-o max_use=20

(or)
lmtp-amavis unix - - n - 2 lmtp
-o lmtp_data_done_timeout=1200
-o lmtp_send_xforward_command=yes
-o disable_dns_lookups=yes
-o max_use=20

21 Jan 17 Mounting a remote directory using SSHFS in Debian Jessie

Introduction:
If you want to mount a directory on a remote server via Internet NFS can be quite a challenge to protect. A good solution would then be to use SSHFS. Here is a shot Howto for Debian Jessie.

Note: In Wheezy and in Jessie before I did an upgrade to the kernel 3.16.0-4-amd64, the following entry in /etc/fstab was working:
sshfs#root@remote.server.com:/remote_dir /local_dir fuse defaults 0 0
BUT, as soon as upgraded Jessie to the kernel 3.16.0-4-amd64, I could not boot any more and the system went into an emergency mode signalizing that I should give the root password or press Ctrl-D to continue. Ctrl-D brought to nowhere and the system just crashed. It was also suggested that I should give the command ‘journalctl -xb’ to find out what was wrong after I had given the root password. This command gave me the indication that ‘process /bin/plymouth could not be executed’. Well, the message is quite misleading since the error was that the new kernel was no more supporting the above older method of mounting a filesystem using SSHFS in /etc/fstab. Commenting this entry in /etc/fstab allowed me to boot and later to change the entry for a new one that worked which follows.

First install the needed package:
apt-get install sshfs
Then considering the two scenarios:
1 – User mount: Mounting a remote directory belonging to user ‘media’ using SSHFS and the ssh keys. User ‘media’ was configured in both servers to have the same UID.
2 – Root mount: Mounting a remote directory belonging to root using SSHFS and the ssh keys.

Scenario 1:(user mount)

On remote server run the command:
useradd -d /home/media/ -u 2017 -s /bin/bash media
passwd media (give any password, that will need to be deleted later anyway)
mkdir -p /home/media/share1
chown -R media: /home/media/share1

On local server run the commands:
useradd -d /home/media/ -u 2017 -s /bin/bash media
mkdir -p /home/media/share1
chown -R media: /home/media/share1
su - media
ssh-keygen -t rsa (press <Enter> to all questions)
ssh-copy-id media@remote.server.com (enter media user's temporary password of remote server)

Enter in /etc/fstab:
media@remote.server.com:/home/media/share1 /home/media/share1 fuse.sshfs noauto,x-systemd.automount,_netdev,user,idmap=user,follow_symlinks,identityfile=/home/media/.ssh/id_rsa,allow_other,default_permissions,uid=2017,gid=2017 0 0
Back on remote server, disable the user’s password using the command:
passwd -l media
———- End scenario 1 ———–

Scenario 2 (root mount)

ssh-copy-id root@remote.server.com (enter 'root' password of remote server)
Enter in /etc/fstab:
root@remote.server.com:/share2 /share2 fuse.sshfs noauto,x-systemd.automount,_netdev,user,idmap=user,follow_symlinks,identityfile=/root/.ssh/id_rsa,allow_other,default_permissions,uid=0,gid=0 0 0
———- End scenario 2 ———–
Then reboot the system
reboot
After reboot you won’t see yet any mount entry if you give the command ‘mount’. It will only appear after the first attempt to access the mount point in the local server. This mount is governed by systemd. You can’t quite control manually the mounting and unmounting of this new method since it’s controlled by systemd. I’m still looking for ways to manually mount/unmount this systemd controlled mount. Any suggestions is welcome.

19 Jan 17 Installing TeamPass in Debian Jessie

Introduction:
TeamPass is a very good Web application which can store securely Passwords for single person or teams. Here are the steps I used to install it in Debian Jessie. These instructions can also be used with no or minimal changes to install TeamPass in other Debian or Ubuntu systems.
These instruction are partly based on this site:
http://teampass.net/2013-12-31-installation-on-linux-server
and these
http://bourntech.com/blog/install-teampass-on-ubuntu-14-6lts/
https://github.com/nilsteampassnet/TeamPass/

Steps:
Create the user that will be used as owner of the TeamPass htdocs and Apache TeamPass requests processes.
useradd -d /opt/teampass/ -s /bin/false passwords
Prepare the teampass home directories
mkdir -p /var/www/teampass/fcgi/tmp
mkdir /var/www/teampass/logs
mkdir /var/www/teampass/auth
cd /var/www/teampass/
#Get the latest released software:
wget --no-check-certificate https://github.com/nilsteampassnet/TeamPass/archive/master.zip
unzip master.zip

Install the required packages:
apt-get install php5-mcrypt php5-mysqlnd php5-gd openssl apache2-suexec-custom apache2-mpm-prefork libapache2-mod-fcgid libapache2-mod-php5 php5-cgi mariadb-server
In order to allow Apache to modify files inside the TeamPass htdocs we use FCGI/suexec Modules.
a2enmod fcgid
a2enmod suexec
a2enmod ssl

Create the fcgi_wrapper script:
touch /var/www/teampass/fcgi/php-fcgi-starter
mcedit /var/www/teampass/fcgi/php-fcgi-starter

Content:
#!/bin/sh
export PHPRC=/var/www/teampass/fcgi/
export PHP_FCGI_CHILDREN=2
export PHP_FCGI_MAX_REQUESTS=500
exec /usr/bin/php5-cgi

Make it runnable but not for others:
chmod 750 /var/www/teampass/fcgi/php-fcgi-starter
Copy the php.ini from system to /var/www/teampass/fcgi/
cp /etc/php5/apache2/php.ini /var/www/teampass/fcgi/
Adapt the php.init to the site:
mcedit /var/www/teampass/fcgi/php.ini
Add the following 2 lines at the end:
upload_tmp_dir = /var/www/teampass/fcgi/tmp
session.save_path = /var/www/teampass/fcgi/tmp

And look for the configuration: max_execution_time and change its value from 30 to 60. Eg.
max_execution_time = 60
Create the Apache2 configuration:
Content of config file in /etc/apache2/sites-available/teampass.mydomain.com.conf:
# ============ https://teampass.mydomain.com ==================
<virtualhost *:443>
ServerName teampass.mydomain.com
DocumentRoot /var/www/teampass/TeamPass-master
SuexecUserGroup passwords passwords
<directory /var/www/teampass/TeamPass-master>
Options -Indexes +FollowSymLinks +ExecCGI
FCGIWrapper /var/www/teampass/fcgi/php-fcgi-starter .php
AddHandler fcgid-script .php
DirectoryIndex index.php
Require 192.168. granted
AuthType Basic
AuthName "Private area"
AuthUserFile /var/www/teampass/auth/web.auth
Require valid-user
Satisfy all
</directory>
SSLEngine On
SSLCertificateFile /etc/letsencrypt/live/teampass.mydomain.com/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/teampass.mydomain.com/privkey.pem
SSLCACertificateFile /etc/letsencrypt/live/teampass.mydomain.com/chain.pem
ErrorLog /var/www/teampass/logs/error_log
CustomLog /var/www/teampass/logs/access_log combined
</virtualhost>

Create the first layer(BASIC) Authentication credentials for first user:
htpasswd -c /var/www/teampass/auth/web.auth username
Give the whole directory ownership to ‘passwords’ user
chown -R passwords: /var/www/teampass/
NOTE: Before you restart your Apache2 service, make sure the Certificate is been issue and installed in the directory: /etc/letsencrypt/live/teampass.mydomain.com/
You can use the instructions on this link to install LetsEncrypt software:
//tipstricks.itmatrix.eu/?s=letsencrypt&x=0&y=0

Enable Apache’s new configuration:
a2ensite teampass.mydomain.com
Restart Apache to activate it’s new configuration:
service apache2 restart
Prepare the suexec permissions files
echo "/var/www/teampass" >> /etc/apache2/suexec/www-data
echo "/var/www/teampass" > /etc/apache2/suexec/passwords
echo "TeamPass-master" >> /etc/apache2/suexec/passwords

IMPORTANT: We need to make sure that the cgi-script called by suexec is residing under the Server’s DocumentRoot for suexec to be allowed to run, therefore we installed the site under /var/www/teampass(which is located under the Server’s DocumentRoot(/var/www/) NOT meaning the VirtualHost’s DocumentRoot. A symlink is allowed here.

Preparing the MySQL database:

Create the new Database in MySQL:
Follow theses instructions:
1) Connect to mysql as root:
mysql -p -u root
PW: ******

2) Create the DB, user and user access rights:
CREATE DATABASE pwdb CHARACTER SET utf8 COLLATE utf8_bin;
GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP,ALTER,INDEX on pwdb.* TO 'pwuser'@'localhost' IDENTIFIED BY 'password';
flush privileges;

Quit Mysql:
quit;
3) Tip: To confirm if the permissions were granted successfully, log into the DB server with the PWDB DB user(pwuser) and run the command below:
SHOW GRANTS FOR 'pwuser'@'localhost';
4) Quit Mysql:
quit;
Installing TeamPass via the web interface:
In the browser:
https://teampass.mydomain.com/install/install.php
Fill-in the appropriate, paths, MySQL credentials and extra settings and save this configuration.
You are then ready to use TeamPass

19 Jan 17 SSH doesn’t accept my key since upgrade Mac OS X to Sierra

Introduction:
I have two MacBooks. One that still has Mavericks OS X and one that I just upgrade to Sierra OS X.
Since the upgrade I can’t connect via SSH to one of my Linux servers using the RSA/DSA Keys any more.
It always asks for a password. After adding the ‘-v’ option to the ssh command line, to see the handshaking, I noticed the following line:
debug1: Skipping ssh-dss key /Users/michel/.ssh/id_dsa - not in PubkeyAcceptedKeyTypes
After doing some research in Google, it was said that the DSA keys are no more ‘secure’.
In order to make it work again against the same DSA keys it was suggested to do the following which worked:

Note: This solution is not recommended to be used because of the old DSA keys.
Solution:
In MAC edit(or create if not existing) the file ~/.ssh/config and add the following line:
PubkeyAcceptedKeyTypes +ssh-dss

30 Dec 16 pygrub: Unable to find partition containing kernel

Introduction:
Lately after I upgraded many packages in a Xen 4.4 DOMU VM the pygrub could not boot the VM any more.
During the security update, the installed grub2(grup-pc), which never created any problems before with pygrub, got updated and suddenly it did create problems to boot the VM. Here is the error message I got when trying to boot it:
Parsing config from /etc/xen/VM.cfg
libxl: error: libxl_bootloader.c:628:bootloader_finished: bootloader failed - consult logfile /var/log/xen/bootloader.32.log
libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: bootloader [-1] exited with error status 1
libxl: error: libxl_create.c:1024:domcreate_rebuild_done: cannot (re-)build domain: -3
libxl: error: libxl_dom.c:35:libxl__domain_type: unable to get domain type for domid=32
Unable to attach console
libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: console child [0] exited with error status 1

I have another VM whith the same Debian system in it which boots well. After comparing the grub.conf etc. with each other I could not see any differences.
If I launched the pygrub with the image disk of the VM as argument, I am normally presented with the Grub menu and then kicks out with the normal errors. This time I got no menu at all and got the following error message:
/usr/lib/xen-4.4/bin/pygrub /virtual/xen/VM/disk.img
Traceback (most recent call last):
File "/usr/lib/xen-4.4/bin/pygrub", line 839, in
raise RuntimeError, "Unable to find partition containing kernel"
RuntimeError: Unable to find partition containing kernel

After Googeling a bit I found this site which talks about this problem as well although with an LVM volume instead of with a file disk image. But the principle was the same:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745419
So in resume: If pygrub sees somethings else than zeroes in the first 512 bytes of the image disk, it returns with this error: ‘Unable to find partition containing kernel’

Cause:
During the upgrade of grub-pc the package script asked me to specify the boot sector where grub should be installed and I happen to select the proposed one ‘/dev/xvda2’ which was a mistake.

Preventive solution:
I should have left the image partition untouched and continue the upgrade of Grub-PC without grub being written in the boot sector, and then afterwards run the command:
update-grub

Present Solution:
Overwrite the boot sector(512 bytes) of the image file with zeros.

Command:
dd conv=notrunc if=/dev/zero of=/virtual/xen/domains/VM/disk.img bs=512 count=1
Note: I use the option conv=notrunc to make sure the output file will not be truncated to 512 bytes after the overwriting.

Result:
I could then boot the VM well again.

24 Dec 16 Force reboot a remote Linux server

Introduction:
After having tried to do a reboot of a remote Linux server via the command reboot which had no effect, I tried to find a command that would force the server to reboot immediately. I found the commands that do exactly that at:
https://major.io/2009/01/29/linux-emergency-reboot-or-shutdown-with-magic-commands/

Commands:
echo 1 > /proc/sys/kernel/sysrq
echo b > /proc/sysrq-trigger

This is pretty brutal and pretty much the same as pressing the reset button on the server (if equipped). No daemons will be shut down gracefully, no filesystem sync will occur, and you may get the wrath of a fsck (or worse, a non-booting server) upon reboot. BUT when all else fails, this is the next best thing to do.

20 Dec 16 Upgrading Apache2 from Debian Wheezy to Jessie

Introduction:
As I tried to make a full distribution upgrade from Wheezy to Jessie the upgrade of Apache2 didn’t go well at all: dpkg kept coming up with dependencies errors and post-install scripts errors. Unfortunately I don’t have a sample of these errors here. Since I had to dist-upgrade over 30 servers of the same nature I decide to find a solution and here is what I found:

STEPS:
Remove the packages(but not the configurations) that will create problems during the dist-upgrade.
apt-get remove apache2 apache2-mpm-prefork apache2-suexec apache2-utils apache2.2-bin apache2.2-common libapache-mod-security libapache2-mod-fcgid libapache2-mod-php5 libapache2-modsecurity
Add the following default repositories of Jessie in /etc/apt/sources.list
# Debian Jessie
deb http://security.debian.org/ jessie/updates main
deb-src http://security.debian.org/ jessie/updates main
deb http://ftp.at.debian.org/debian/ jessie main contrib non-free
deb-src http://ftp.at.debian.org/debian/ jessie main contrib non-free

apt-get update && apt-get dist-upgrade
apt-get install apache2 apache2-bin apache2-data apache2-mpm-worker apache2-suexec apache2-suexec-pristine apache2-utils libapache2-mod-fcgid libapache2-mod-security2

NOTE: During this upgrade the version of Apache will go from 2.2 to 2.4. This means that some directives of version 2.2 will no more be valid for version 2.4 example:
Depreacted
Oder deny,allow
Should change:
Allow from All >> Require All granted
Deny from All >> Require All denied

etc.
See this special Apache site for more information on upgrading Apache 2.2 to 2.4.
https://httpd.apache.org/docs/2.4/upgrading.html

20 Dec 16 Switch database type from H2 to MySQL in Atlassian Jira

Introduction:

After having tested Jira and decided to keep it for production it is very recommended to change the type of database used by Jira. The default database at delivery time is H2(local file dB) and in this HOW-TO I describe what I had to do to execute that switch under Debian Jessie.

Steps:

References:
https://confluence.atlassian.com/jira062/switching-databases-588581557.html
https://confluence.atlassian.com/adminjiraserver072/connecting-jira-applications-to-mysql-828787562.html
https://confluence.atlassian.com/jira060/connecting-jira-to-mysql-370705252.html

Backup database:
(SprocketWheelIcon)==>>System ==>>(Left menu)Backup System ==>>Filename: HP_JIRA_Backup_1.zip
Results:
eg. /var/atlassian/application-data/jira/export/HP_JIRA_Backup_1.zip

Create the new Database in MySQL:
Follow theses instructions:
1) Connect to mysql as root:
mysql -p -u root
PW: ******

2) Create the DB, user and user access rights:
CREATE DATABASE jiradb CHARACTER SET utf8 COLLATE utf8_bin;
GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP,ALTER,INDEX on jiradb.* TO 'jiradbuser'@'localhost' IDENTIFIED BY '<DBpassword>';
flush privileges;

3) Tip: To confirm if the permissions were granted successfully, log into the DB server with the JIRA DB user and run the command below:
SHOW GRANTS FOR 'jiradbuser'@'localhost';
4) Quit Mysql:
quit;
Stop Mysql server and Jira:
service mysql stop
service jira stop

Delete the innoDB log files
IMPORTANT!! Mke sure you have no other application that uses innoDB format for its databases otherwise that deletion might do data corruption.
rm /var/lib/mysql/ib_logfile?
Edit /etc/mysql/my.cnf and add the following lines:
FOR Mysql 5.5 and below
[mysqld]
...
default_storage_engine=InnoDB
max_allowed_packet=256M
innodb_log_file_size=256M

FOR Mysql 5.6
[mysqld]
...
default_storage_engine=InnoDB
max_allowed_packet=256M
innodb_log_file_size=2G

Remove this if it exists
sql_mode = NO_AUTO_VALUE_ON_ZERO
Start MySQL server:
service mysql start
Install the MySQL JDBC driver to Jira drivers directory
cd /tmp
wget http://dev.mysql.com/get/Downloads/Connector-J/mysql-connector-java-5.1.40.tar.gz
tar fvxz mysql-connector-java-5.1.40.tar.gz
cp mysql-connector-java-5.1.40/mysql-connector-java-5.1.40-bin.jar /opt/atlassian/jira/lib/
# Delete the not needed uncompressed directory
rm -rf mysql-connector-java-5.1.40

Connecting Jira to MySQL database:
Rename the dbconfig.xml file as follows:
Note: this change of filename will force Jira to start the Setup Wizzard if it doesn’t find this file.
mv /var/atlassian/application-data/jira/dbconfig.xml /var/atlassian/application-data/jira/dbconfig.xml.H2
Restart Jira:
Note: It is normally a long process that might take up to a minute before Jira can really be ready to be used.
service jira stop && service jira start && tail -f /var/atlassian/application-data/jira/log/atlassian-jira.log
Watch for errors(like ‘exception…’
When the logs are showing something like below then Jira is ready to be used to continue the migration of the database.
---------------------------------------------------------------------------------
Heap memory : Used: 196 MiB. Committed: 482 MiB. Max: 733 MiB
Non-heap memory : Used: 57 MiB. Committed: 59 MiB. Max: 1264 MiB
---------------------------------------------------------------------------------
TOTAL : Used: 253 MiB. Committed: 541 MiB. Max: 1997 MiB
---------------------------------------------------------------------------------

Connecting Jira to the MySQL database:
– Using the browser go to this Jira site and you will be presented with the Jira setup wizzard.
– Select the Manual Setup
– At database Setup page select: My Own Database and fill in the blanks
– Click on Test Connection to verify the validity of the information
– If all ok, click on Continue button.
– Enter the Company name and Select Private,and give the URL in the ‘Set up application properties’ page
– Select I have a Jira Key and paste the key in the field below the Server ID
– And fill in the following pages etc.

Migrating the database
Importing from older H2 data saved in xml backup (.zip)file
In Terminal:
Move the backup file to the import directory:
mv /var/atlassian/application-data/jira/export/HP_JIRA_Backup_1.zip /var/atlassian/application-data/jira/import/HP_JIRA_Backup_1.zip
In Jira site:
(SprocketWheelIcon)==>> System ==>> (Left menu)Restore System
Enter the filename(without path) of the backup(including the .zip extension)
Click Restore button.
IMPORTANT NOTE: This operation will overwrite all settings(except for the Database connection) which you already entered in the previous Setup Wizzard like your password/user/email/Language etc.. Therefore if this information are not exactly the same, you will have to logout and login again.

The Portfolio for Jira licence might have to be renewed at:
https://www.atlassian.com/purchase/cart

In order to correct the error, that will appear if the FLAG pool-test-while-idle is not set in the file dbconfig.xml, edit the file:
/var/atlassian/application-data/jira/dbconfig.xml and add the following line inside the settings block as follows:
<pool-test-while-idle>true</pool-test-while-idle>
eg.
<jdbc-datasource>
.....
<pool-remove-abandoned-timeout>300</pool-remove-abandoned-timeout>
<pool-test-while-idle>true</pool-test-while-idle>
<pool-test-on-borrow>false</pool-test-on-borrow>
.....
</jdbc-datasource>

Reason: The Set-up wizzard did not set it(inexistant) during its setting up the Database settings and the interface was complaining that it failed a database connection test. I had to make that change manually later and restart Jira.
Restart Jira and watch for errors.
service jira stop && service jira start && tail -f /var/atlassian/application-data/jira/log/atlassian-jira.log

Verifying the logs for errors:

You can check for errors via the Jira interface Log analyzer function in:
(SprocketWheelIcon)==>>System ==>>(Left menu)Support Tools==>>Log analyzer(TAB)==>>Refresh(middle right)