Installing DBD::mysql on Strawberry Perl is really easy!

DBD::mysql is the driver for the Perl DBI database interface. Basically, if you want to interact with your MySQL or MariaDB  server from Perl, this is the driver you’d use.

I co-maintain the driver and heard people complaining that it’s difficult to install it on Windows. This post basically explains that it’s not so bad.

It is already installed

First of all, you do know this right? It IS already installed with Strawberry Perl. Strawberry Perl is a very good distribution of Perl for Windows. Many of the nice modules you’d already want are available out of the box. See the list on the website for more details. There’s also ActiveState perl, more on that later.

Nevertheless, installing is easy

If you want to install it because you want a newer version or something like that, it’s pretty easy. Strawberry bundles the MySQL driver in [strawberry]/c/bin and ships with a batch file that acts as if it is mysql_config – this is very convenient.

The only problem is that the current version of DBD::mysql, 4.029, does not properly find it. You’d have to tell it where to look. This will be fixed in the next release of the driver. I already committed the fixes which was basically just deleting old code.

c:\> cpan
cpan> look DBD::mysql
> perl Makefile.PL --mysql_config=c:\strawberry\c\bin\mysql_config.bat
> dmake
> dmake install
> exit
cpan> quit

And that’s it!

Compiling against your own version of the libraries

Unfortunately, this is only really this easy because we compile against the version of the libraries bundled with Strawberry. Compiling against our own libraries, perhaps newer, or from MariaDB or so, is much more difficult at this point in time. Also, if you’d be using ActiveState Perl, you’d be out of luck. And of course, with ActiveState you can ppm install DBD-mysql but this only works if you’re on the current or previous-current perl because otherwise you’re behind a paywall and you’re out of luck.

I’ll be trying to make this easier (and promised it to Mithaldu) and will post more on that later.

As a bonus: RMSB8sZtJOIIAAL6fg

I was on Fosdem today where I met lots of nice people and had some interesting conversations. Here is a photo of RMS who was there handing out GNU slash Linux stickers.

Using an SSL certificate with OTRS

Reasons for using HTTPS with OTRS

… well really, there is NO reason NOT to.browserbar

  • When you’re NOT using HTTPS you’re exposing your password in plain text when logging in. Even if you’d be only using OTRS on your corporate network, can you trust everything and everyone on your network?
  • You’re having data about your customers in OTRS. You should make sure this data is not exposed or leaked; so you should be using HTTPS when accessing OTRS from your web browser.
  • Apart from the encryption; there is also the aspect of MITM-attacks on your web server. If you have a certificate on your web server you can be fairly sure the server you’re looking at, and the password for you’re typing your password into, is actually YOUR server and not some guy using the same hotel wifi poisoning DNS.
  • Even if you would not care about security, using SSL and HTTPS is a pre-requisite for using mod_spdy with Apache, which brings many of the upcoming HTTP/2.0 features to the Apache webserver and modern web browsers such as Google Chrome and Mozilla Firefox. This makes OTRS faster!

Self-signed versus purchased

The ‘easiest’  way is to slap a self-signed certificate on your web server. This will lead to the well known nasty warning signs on your website. This can be perfectly acceptable if your OTRS system is just used by you and your co-worker and no customers log in to it. And after the first login, even the MITM-prevention will work because your web browser would complain if the certificate would change.

You can also purchase a certificate at a vendor such as Verisign. This does money but because the certificate authority is trusted by your web browser, the nasty warnings are gone. And certificates are not so expensive as they used to be, really.

Wildcard certificates, which you can use on many subdomains such as support.example.com, sales.example.com and www.example.com are still pretty pricey at a hundred euros or more per year, and Extended Validation certificates are also still expensive, but a simple certificate for www.example.com and example.com would be not even 10 euros per year at providers as NameCheap (full disclosure: affiliate link. I know this is never going to make any money).

Extended Validation and Organisation Validation levels only differ in the amount of work you have to do to make sure you prove to actually be this company before you can get a certificate, and do not make the encryption any stronger or weaker.

Configuring apache

So you’ve purchased or generated your certificate for your web server, great! Now you’ll have to install it, that will be difficult, right? WRONG! It’s super easy. Let me show you how.

You’d need to activate SSL. On Debian or Ubuntu, it’s pre-installed with Apache and you’d just need to enable it, like this:

sudo a2enmod ssl
sudo a2ensite default-ssl

On CentOS or Red Hat, it would be:

sudo yum install -y mod_ssl

now in the SSL configuration file, /etc/apache2/sites-enabled/default-ssl on Ubuntu/Debian and /etc/httpd/conf.d/ssl.conf on RHEL/CentOS, you’d add this for your purchased certificate:

SSLCertificateFile    /etc/apache2/certs/mydomain.crt
SSLCertificateKeyFile /etc/apache2/certs/mydomain.key
SSLCertificateChainFile /etc/apache2/certs/intermediate-rapidssl.crt

now you simply restart your web server, on Debian/Ubuntu:

sudo service apache2 restart

or on RHEL/CentOS:

sudo service httpd restart

Now you can log in OTRS using the ‘https://’ prefix. It’s THAT easy!

It would still be great if you can forward existing links into http:// URLs that might already exist in notifications and such to https:// – but that’s easy. Just add this to the HTTP virtualhost configuration:

RewriteEngine On
RewriteCond %{HTTPS} off 
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

Verification of your certificate

The people at Qualys SSL Labs have a nice service which allows you to verify if your certificate was set up properly, you can find it here.

Configuring OTRS

In OTRS the configuration change is also quite easy. Just navigate to Admin > SysConfig > Framework > Core and set ‘HttpType’ to https.

httpsThis will make the links in outgoing email notifications contain ‘https’ and it will also set the secure attribute on your login cookies.

Conclusion

With just a couple of minutes of effort you can put a self-signed certificate on your system. If you’d throw in some ten euros you can grab a commercial certificate which increases the user experience. It’s really a no-brainer, and it should be part of every proper OTRS installation! I hope this article helped you setting it up.

PostgreSQL 9.4’s JSONB and perl DBD::Pg

540px-Postgresql_elephant.svgAs you’ll know by now, PostgreSQL 9.4 is out and it is better than ever. The most notable change is the new JSONB data type, where you can store ‘document type’ data in your relational database, basically allowing for supporting many use cases that previously required MongoDB or similar NoSQL solutions.

A couple of functions and operators have been added to support JSONB, one of these is the ? operator which can be used to check if a key exists. This caused a problem for Perl’s DBD::Pg module as it uses the ? character as a bind operator. Since version 3.5.0 and up, you can now escape a ? if you want to use it as an operator instead of a bind parameter. I’ll show briefly how you can leverage this.

Example: the most stupid schema ever

Because so many SQL examples are using books and authors, I’ll throw in the obligatory book table. But this time with JSONB!

Of course this is only an example, but one of the use cases of JSONB is that you can add as many attributes to an object as you want without the need of changing the schema and your database will still be fast. You can also create indexes on JSON attributes if needed.

So in my example we’ll create the most stupid database table layout:

  CREATE TEMPORARY TABLE book (
    title text not null,
    info jsonb
  );

So we’ll store the book title in a column and we’ll create a second column in the JSONB format to store attributes. For instance, let’s insert these values:

INSERT INTO book (title, info) VALUES
    ('Our Uncle',       '{"year": 1985, "category": "novel", "author": "Arnon Grunberg" }'),
    ('The Wild Things', '{"year": 1999, "author": "Dave Eggers"}');

Some SQL queries on the JSONB

This allows us to query on the book. For instance, this would return the author of ‘The Wild Things’:

SELECT info::jsonb->'author' FROM book WHERE title = 'The Wild Things';

But what if we want to get a list of all books that have a category set? This is where the ? operator comes into play. The ? operator can be used to check existence of a key. You can also use it to check if a value is part of a JSON array. But for our example, the query would be like this:

SELECT title FROM book WHERE info::jsonb ? 'category';

Apply that to perl!

Now let’s see what that would look like in perl.
You’ll need DBD::Pg 3.50 or newer to be able to use the \ character to be able to escape the operator. Remember, a regular ‘?’ is use as bind character when using Perl DBI. If you’d use an older version of DBD::Pg you’d still be able to leverage the JSONB features, just not the ? operator!

If you’d use it on a version of DBD::Pg that is prior to 3.5.0, you’d get:

DBD::Pg::db selectall_arrayref failed: called with 1 bind variables when 2 are needed at jsonb.pl line 32.

CPAN Pull Request Challenge for January: DateTime::Format::Epoch

About the challenge

About a week before Christmas I signed up for Neil Bowers 2015 CPAN Pull Request challenge. This is a challenge where each month you’d need to send a pull request to a module that would get assigned to you; and the idea is that you really need to make this one pull request each month. I thought it would be nice to see if I could pull it off.

Continue reading CPAN Pull Request Challenge for January: DateTime::Format::Epoch

Using strong password hashing with OTRS

In the last years we saw several cases of websites getting hacked and having the passwords of their users leaked. This happened for instance at LinkedIn in 2012. The user passwords were not stored in the database in plain text but hashed with SHA-1 and this algorithm is pretty weak nowadays meaning if a hacker would be able to get the password hashes, it’s possible to expose the original passwords.

As a result of this, OTRS added support for hashing passwords for agents and customers using bcrypt starting OTRS 3.3.  Since it depends on an external module, it is not enabled by default! This means that, if you want to preventing the nasty event your systems would be compromised your users’ passwords are out there in the open, you’d better enable it manually. Luckily this is not hard.

Details of the hashing – skip if you want!

As all modern systems, OTRS uses two techniques called ‘salting’ and ‘hashing’ to store passwords. This means that OTRS does not store the users’ password in the database, so the passwords can’t be stolen directly. Instead, it stores the hashed value, and this is supposed to be a one way hash. This means, if your password would be ‘secret123’ (which would obviously be a terrible example of a password) OTRS takes this, along with a random value, the salt, and calculates the hash. It then stores the salt and the hash in the database. Salting is used to prevent a situation where two users with identical passwords would end up having the same hashes and thus preventing the use of pre-constructed rainbow tables. If the user tries to log in, he supplies his password in clear text. After that, the salt is read from the database and together with user input a hash is calculated and this hash is compared with the value in the database. If these are equal, access is allowed.

If the hashing operation is ‘expensive’ enough, i.e. it costs a relative lot of time to perform the hashing, crackers can not easily find out your passwords would they obtain a copy of your database.

If you don’t do anything by default, OTRS uses SHA-256 hashing which is not as bad as MD5, but it’s not industry best practice anymore either. Using special hardware you can calculate SHA-256 hashes pretty fast. bcrypt is really much stronger; especially because OTRS uses a better salting mechanism with bcrypt than what it uses with SHA-256. You don’t need to know any of these implementation details, just follow the simple steps below!

Installing the module

It might just be you already have the needed module installed. Log into your OTRS machine and run bin/otrs.CheckModules.pl

$ perl bin/otrs.CheckModules.pl 
  o Apache2::Reload..................ok (v0.12)
  o Archive::Tar.....................ok (v1.76)
  o Archive::Zip.....................ok (v1.30)
  o Crypt::Eksblowfish::Bcrypt.......ok (v0.008)
  ....

If the Crypt::Eksblowfish::Bcrypt module is installed, the output would look like above. If not, you’d need to install it. You can best do that from your package manager. On Red Hat or CentOS this is as simple as

sudo yum install "perl(Crypt::Eksblowfish::Bcrypt)"

although if you do not yet have the EPEL repository enabled, you should do that first!

sudo yum install epel-release

On Debian or Ubuntu, you would use

sudo apt-get install libcrypt-eksblowfish-perl

Now you can run the bin/otrs.CheckModules.pl script again to verify the installation.

Configuring OTRS

In OTRS, you should change the password hashing mechanism for both customers and agents. For customers, you can simply navigate to Admin > SysConfig > Frontend::Customer::Auth and change the CryptType setting to ‘bcrypt’.

customer-bcrypt

For agents, there is no such convenient configuration setting available and you should modify the Kernel/Config.pm file with a text editor and add this option:

$Self->{'AuthModule::DB::CryptType'} = 'bcrypt';

After this, the changes are effective immediately for newly saved passwords. Passwords that were already set are NOT automatically upgraded.

Verifying the change

If you’d want to make sure the new mechanism works, you can change your password and log out & in in OTRS, then check the log. You’ll see the hashing method used:
bcrypt-log

Since this configuration change does NOT update existing user passwords, it is best to make this change before you take OTRS in production.