You are here

From download to production system

It has to be said, but unless you are a guru in Java, Spring, Tomcat, Oracle/MySQL and a number of other open source technologies, deploying Alfresco as a production system is no trivial matter. I should preface this article by saying that our production system runs on a headless install of Linux. I shall raise my head above the parapet for an instant to comment that this is not the easiest environment to do things in.

In saying that, the installation and configuration has come on in leaps and bounds since the early days of Alfresco. In the dim and distant past, configuration was achieved by hand editing XML files. This was no easy task and involved picking your way through hundreds of lines of bean configurations to try and find the correct variable. They moved on to the use of property files which made things so much easier.

We’ve come even further these days with Alfresco now providing a JMX interface to some of the most common configuration options. The technobods at Alfresco in their wisdom also included the ability to change these options without having to restart the server. In the past this has been the biggest holdup as waiting for a server restart could be tedious at best. When considering a production system, this is less than ideal.

Alfresco now comes with a built in MySQL database, so getting it up and running is relatively easy…assuming of course you don’t want to integrate it with anything. In addition, to get the full fat goodness of Alfresco Share, a number of other components need to be installed which can be problematic. I should add that a number of these problems are solved via the Windows installer, but for those of us on Linux distros, they are headaches.
 

Integration

Oracle

Oracle is the DB of choice with our DBA firmly believing that everything from the first mission to Mars to world peace becoming possible through its goodness. From a humble sysadmin’s point of view, it has its own problems. A common gotcha is that Alfresco requires the Oracle jdbc driver to be installed before it will talk to the DB. It’s easily resolved by retrieving it from whatever installation of Oracle you are running and placing it in the lib directory of your Tomcat server (sorry, haven’t a clue about WebSphere, JBoss, etc).
 

ImageMagick and SWFTools

These little open source libraries are what make the thumbnailing and document previews possible in Alfresco Share. Whilst it is possible to run without them, you lose a major selling point to users by not including it. We run Alfresco on a 64bit Centos system and it would seem that SWFTools requires the latest version to accomplish this. Add into that a myriad of extra libraries that are required and you have a pretty complex installation with lots of strange error messages that are no use to man nor beast.
 

Authentication

One of the benefits of Alfresco is that it has a multitude of access points. The most common of which are CIFS (think shared drives) and the web. Unfortunately, whilst it is possible to run Alfresco via the web interface allow both local and ldap logins, the same can not be said for the shared drive access (a failing of CIFS rather than Alfresco it should be said). Alfresco allows different authentication systems to be chained and for the web, each is tried in turn until a match is found. With CIFS, the first is tried and if that doesn’t work, game over!
 

Users and Groups

Alfresco has the ability to synchronise itself with an external LDAP directory. Whilst I have always been able to pull in Users, I’ve never managed to get the groups synchronised. The closest I’ve come is being able to get the group names, but they in turn are not populated with users. There is also a slight gotcha in that if you are not very careful, your users are recreated each time there is a synchronisation. This can cause problems in Share where the user is then denied access. 
 

Firewalls

We run an environment where everything is denied by default. So it can be a bit of a dark art trying to figure out exactly what ports should be opened. Sometimes the error messages generated by this can be easily diagnosed, others can send you round the world and back before realising it is a firewall issue.
 

Backup

This is perhaps one of the more confusing areas in Alfresco. It would seem to me, for an Enterprise Level solution, they don’t make it easy. Alfresco seems to recommend a cold backup as being the best solution. Whilst this may be the case, it isn’t an option for a production system that is being used 24hrs a day. When planning a hot backup schedule you have to ensure that the lucene indexes directory is not backed up. Instead Alfresco provides a nice helper routine that backs these up once a day in a different directory. It means if you have to restore your indexes will always be out of date, but restoring stale indexes is much faster than rebuilding them from scratch, especially if you have a very large repository.

You then have the backup of the database and filesystem. Whilst a database backup can take a point in time snapshot, a filesystem backup cannot (at least not with our systems). Therefore you have to ensure your filesystem backup is never ahead of your database backup.
 

SSL

Many people will want to protect their web interface using some kind of SSL certificate. Unfortunately trying to get this working seems to be a bit of a hit or a miss. I have managed in the past to get it working in Tomcat, but with no automatic redirect to a secure connection. I eventually had to give in and install apache httpd to handle the http/https redirects and certs and proxy through to Tomcat in the backend. This in itself does pose some problems with Share in that the flash uploader it notoriously flaky when uploading via https. Things seem to be stable with our install at the moment, but I’m just waiting for the day when the phone calls start flooding in after some random update of Flash. For those still using Internet Explorer 6, you may also have trouble downloading files from the Alfresco Explorer over https. This seems to be because of the way IE6 handles secure downloads, rather than a failing of Alfresco. Thankfully it is an issue that seems to have been resolved by later versions of IE.
 

Conclusion

Whilst I have listed a fair number of problems and gotchas that I have experienced with Alfresco, many will have been because of my lack of knowledge of the underlying technologies. I can’t pass by without saying that the Alfresco support agreement has be invaluable in solving these issues. Once you actually have it up and running, it offers up a world of potential to revolutionise your company into one that actually uses their data and not only stores it.

Tags: