Skip to Content

A bunch of new Liferay hooks and portlets

I published my projects page about a month ago and have been busy publishing a bunch of new portlets and hooks to Liferay 6.1 CE GA2 I hope to add all of them to Liferay marketplace once it opens to developers.  Just to mention few highlights 

Photo Carousel Portlet

This portlet displays images from a selected folder from Documents and Media using the Alloy UI Carousel component. There's several options you can adjust like the speed or whether to include images from subfolders and how many to show.

Liferay Akismet Portlet

This portlet provides Akismet spam checking capabilities to blog comment and message board posts. It's still a working progress but the basic checking is already there.

Social Comments Portlet

This pretty simple portlet adds Disqus and Livefyre commenting as option to Liferay comments. You can enabled them all or you can just enable one. The settings are done per site so each of your Liferay sites can have different settings. You can try it out by commenting below using Disqus. I created this portlet because not everyone wants to create a new account even though they can use Facebook to speed it up. It also adds pretty nice social sharing and moderation features that are lacking from Liferay blog comments.

These are just a few things I have coming and they all demonstrate how powerful Liferay's hooks are and how easy it is to add new features. Next features I'm planning to release are Gravatar avatar support, tags and categories in feeds and improved sitemap.xml support. The latter two are already in use on this site.

Hope you enjoy these plugins and I look forward to your feedback.

Installing MariaDB on Ubuntu

I've been using MariaDB for some time now and it's perfect replacement for MySQL especially with the latest news on Oracle's move to hinder MySQL developer community despite it's promise to EU. Now is a perfect time to ditch MySQL and move to something that's backed by the original authors of MySQL and that something is MariaDB.

1. First pick your Ubuntu version repository mirror close to you from MariaDB downloads page. Once you've picked up your mirror then add them to /etc/apt/source.list.d/mariadb.list. I'm still running 10.04 so here's what I put in my mariadb.list:

# MariaDB repository list - created 2012-07-04 18:04 UTC
# http://downloads.mariadb.org/mariadb/repositories/
deb http://ftp.heanet.ie/mirrors/mariadb/repo/5.5/ubuntu lucid main
deb-src http://ftp.heanet.ie/mirrors/mariadb/repo/5.5/ubuntu lucid main

2. Next you'll need to import the signing key

sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 0xcbcb082a1bb943db

3. Update

aptitude update

4. Install

aptitude install mariadb-server-5.5

Now you have MariaDB 5.5 installed and you can configure it exactly like you would configure MySQL.

Tips for securing your Liferay installation

There's few security related things that I see people constantly doing wrong. The very first thing is assuming Liferay bundle with it's default settings is secure for production. It is far from secure. Don't get me wrong this doesn't mean that Liferay isn't secure it just means that shouldn't deploy Liferay with it's default settings and assume it's secure. So let's go over some things you should consider.

Default admin user

Everyone knows the default admin user test@liferay.com and some attacks have taken advantage knowing this user and even it's userid which is predictable. What I would suggest is not only to change the email address and screenname of this user but actually create a completely new admin user and remove this user.  

Portal instance web id

The default company web id is liferay.com and it goes without saying you should change it unless you are actually deploying liferay.com. You can do this simply by setting company.default.web.id property in your portal-ext.properties. This must be done before you start your portal and let it generate the database.

Encryption algorithm

By default Liferay is configured to use 56bit DES encryption algorithm. I believe this legacy is due to US encryption export laws. The problem with 56bit DES is that it was cracked back in the 90s and is not considered secure encryption anymore. Liferay encrypts certaing things with this like your password in Remember Me cookie. If someone get's a hold of that cookie they can crack your password. I would recommend using at least 128bit AES. To do that you'll just need to set following properties before starting your portal against a clean database.

company.encryption.algorithm=AES
company.encryption.key.size=128

Password hashing

Recently there has been a lot of sites that have their passwords being compromised because they weren't using salt with their password hash. Liferay by default uses SHA-1 to hash your password. That hash is a one way algorithm that doesn't allow reversing the password from the hash but if someone gets a hold of your password hash it's still possible to crack with brute force or by using rainbow tables. Rainbow tables are precalculated hashes that allow very easily and fast find unsalted passwords. Salt is something we add to the password before hashing it and it's preferrable unique of each password so that even if two users have the same password their hash is different. Liferay comes with SSHA algorithm that salts the password before calculating the SHA-1 hash from it. You can enable it by setting following in your portal-ext.properties

password.encryption.algorithm=SSHA

Unused SSO hooks

The default Liferay bundle comes with all SSO hooks included even thought they are not all enabled it's a good idea to remove any hooks your are not using. There's a property called auto.login.hooks and you should remove all hooks your are not using. Also remember to disable their associated filters. 

Unused Remote APIs

Liferay has several different remote APIs such as JSON, JSONWS, Web service, Atom, WebDAV, Sharepoint etc. You should go through them and disable everything your site is not using. Please note that some Liferay builtin portlets rely on some of these APIs. All the APIs are accessible under /api URL.

Mixed HTTP and HTTPS

Everyone should by now know about Firesheep a firefox extension that allows an attacker to sniff a wifi network they are connected to and hijack a users authenticated session. This attack can compromise any website that doesn't use all authenticated traffic over https. If you use https for just part of the site and your users can access rest of the site as authenticated user over http then your are vulnerable to Firesheep attack. This is especially bad with Liferay if you are using the default encryption and you use Remember me functionality because then the attacker could even compromise your password and use it login to any system where you use the same password. I'm sad to say that even Liferay.com is vulnerable to this attack. 

Shared Secrets

Don't forget to change any shared secrets. The auth.token.shared.secret has a default value that you want to change so that no-one can try to exploit it. This tip came from Jelmer who has found many vulnerabilities in Liferay.  Another one you don't want to overlook is auth.mac.shared.key which has default value of blank. That one is relevant if you auth.mac.allow set to true.

This is not an exhaustive list but this should make your Liferay installation much more secure than it is by default. For more tips on what to configure before going to production check out Liferay whitepapers. You should especially read the deployment checklist. If you can think of any other things that should be on this list comment them or tweet them to me @koivimik

Update: Added shared secret tip from Jelmer 

Monitoring Liferay with Nagios, Jolokia and JMX4Perl

 

How do I monitor Liferay? That's a question I've heard a lot lately. Well the standard way of getting some information about the application is by using JMX. The downside of JMX is that it's a Java only standard and the only remote connection is by using RMI which doesn't really sit well with non Java monitoring software like very popular Nagios. Another hurdle might be that your network admin might not be inclined to open up RMI access to the jvm. 

There's a nice agent called Jolokia that can provide a http bridge to JMX. You can install it as java agent in pretty much any java app or deploy it as a webapp. With Jolokia installed you can query any MBeans for their values using a simple http GET and get the data as JSON objects. JMX4Perl is a perl module and scripts that provide a easy way to run those queries through Jolokia. One of those scripts is check_jmx4perl which can be used in nagios service checks.

Okay so now we know that we are going to need Nagios, Jolokia and JMX4Perl to monitor the Liferay JVM but what should we monitor? Well that depends on what information you are interested in but at minimum I would monitor ajp or http thread usage as well as heap utilization. Just by monitoring those values you'll know when your JVM is becomes unresponsive and can also get some early warning that there's issues for example heap usage goes over warning threashold and never returns to normal or keeps constantly going over the threshold which could indicate they you don't have enough heap allocated.

I'm going to assume that you have  nagios installed and configured and I will only go through how to install Jolokia and configure some checks for threads and heap. So let's start by installing JMX4Perl. 

Installing JMX4Perl is pretty simple with cpan. You just launch cpan command line client and install it like this:

cpan> install JMX::Jmx4Perl

Next you'll need to download Jolokia and deploy the jolokia.war to your app server. For this example I'm going to assume that you are using Tomcat 7. Once you've deployed Jolokia it's usually good idea to restrict who can query it. For this example we are just going to restrict it to a certain IP address (the Nagios server) and limit it to read operations only. Since I don't like modifying the war we are going to tell Jolokia where to find the policy file through a context parameter. Create a jolokia.xml in tomcat/conf/Catalina/localhost with following content:

<Context path="/jolokia">
        <Parameter name="policyLocation" value="file:///etc/jolokia/jolokia-access.xml" />
</Context>

That tells Jolokia to look for the policy file jolokia-access.xml from /etc/jolokia/jolokia-access.xml. This is great when you are running multiple tomcats in the same server and want them to share the jolokia policy file.

Now go ahead and create the jolokia-access.xml in /etc/jolokia

<?xml version="1.0" encoding="utf-8"?>
<restrict>
        <remote>
                <host>[YOUR NAGIOS SERVER IP]</host>
        </remote>
        <http>
                <method>get</method>
                <method>post</method>
        </http>
        <commands>
                <command>read</command>
        </commands>
</restrict>

Next we need to create configuration for jmx4perl. In /etc/jmx4perl/jmx4perl.cfg we are going to include some preconfigured checks extend them. Tomcat 7 you need to add quotes around the thread pool name. We also need to set warning and critical levels for alerts. You'll also need to add a Server for each tomcat you want to monitor.

# Default definitions
include default/memory.cfg
include default/tomcat.cfg

# ==========================
# Check definitions

<Check tc7_connector_threads>
	Use = relative_base($1,$2)
	Label = Connector $0 : $BASE
	Value = Catalina:name="$0",type=ThreadPool/currentThreadCount
	Base = Catalina:name="$0",type=ThreadPool/maxThreads
	Critical 95
	Warning 90
</Check>

<Check j4p_memory_heap>
	Use memory_heap
	Critical 95
	Warning 90
</Check>

<Server tomcat>
	Url http://MY_TOMCAT_HOSTNAME:8080/jolokia
</Server>

Then in /etc/nagios3/commands.cfg we'll need to add a check command for jmx4perl and we'll use the check_jmx4perl script to do that.

define command {
	command_name    check_j4p_cmd
	command_line    /usr/local/bin/check_jmx4perl --unknown-is-critical --config /etc/jmx4perl/jmx4perl.cfg --server $ARG1$ --check $ARG2$ $ARG3$
}

Then we need to define a service to monitor in /etc/nagios3/conf.d/host-MY_TOMCAT_HOSTNAME.cfg

define service {
	use generic-service
	host_name MY_TOMCAT_HOSTNAME
	service_description Tomcat Heap Memory
	check_command check_j4p_cmd!tomcat!j4p_memory_heap!x
}

define service {
	use generic-service
	host_name MY_TOMCAT_HOSTNAME
	service_description Tomcat AJP Threads
	check_command check_j4p_cmd!tomcat!tc7_connector_threads!ajp-bio-8009
}

The check above is for your tomcat heap and the other one is for Tomcat 7 AJP threads.

Now you should all the pieces to implement your own monitoring using Nagios, Jolokia and JMX4Perl. You should also remember that you can apply this to any JEE application not just Liferay.

Configuring c3p0 connection pool for Liferay on Tomcat

There's several ways you could configure a connection pool for Liferay on Tomcat but the way I'm going to show is the JEE way and the only one I consider correct.

The first thing is to copy or move the c3p0.jar from webapps/ROOT/WEB-INF/lib/ to lib/. Also make sure you have your dabase driver there. In this example it would be mysql.jar. 

Then we need to tell Liferay that you want to use a connection pool from JNDI and this you can do by adding following line to your portal-ext.properties which can be placed in Liferay Home directory (the directory above tomcat).

jdbc.default.jndi.name=jdbc/LiferayPool

Add following snippet to conf/server.xml inside GlobalNamingResources. Adjust the pool size and idle time and connection test period according to your environment. They are particularly important when you have a firewall between your Liferay and database or when the database server drops connections after certain idle period.

<Resource
    name="jdbc/LiferayPool"
    auth="Container"
    type="com.mchange.v2.c3p0.ComboPooledDataSource"
    factory="org.apache.naming.factory.BeanFactory"
    driverClass="com.mysql.jdbc.Driver"
    jdbcUrl="jdbc:mysql://localhost/lportaluseUnicode=true&amp;characterEncoding=UTF-8&amp;useFastDateParsing=false"
    user="lportal"
    password="test"
    minPoolSize="10"
    maxPoolSize="20"
    maxIdleTime="600"
    preferredTestQuery="select 1 from dual"
    idleConnectionTestPeriod="180"
    numHelperThreads="5"
    maxStatementsPerConnection="100"
/>

Now we need to link the jdbc/LiferayPool name defined in portal-ext.properties to the jdbc/LiferayPool defined in server.xml and this definition goes to conf/Catalina/localhost/ROOT.xml

<ResourceLink name="jdbc/LiferayPool" global="jdbc/LiferayPool" type="javax.sql.DataSource"/>

Now we are done and you can start your tomcat with the new connection pool. Note you can follow similar process to configure MailSession from JNDI.

Showing 1 - 5 of 41 results.
Items per Page 5
of 9

7.95e/mo hosting for Liferay