Alfresco - Alfresco Setup for Sysadmins and QA Testers

Published on Jan. 14, 2018, 9:46 a.m.

I have a few conventions on the organization of Alfresco installations to make my job (and life) easier. Since I may be also testing multiple Alfresco installations, I try to setup installs in a particular way so that different versions are easier to find. Also, it helps to have some symbolic links to other areas of Alfresco to help speed things up a bit.

As far as Alfresco installations go, I prefer to have all of them under one root directory called "/alfresco".

$ mkdir /alfresco

For each Alfresco installation, I think it's a good idea to name them according to their versions at the minor version level. Hot fixes can be applied easily with new WARs, so I don't feel it's usually needed to name your Alfresco installation Rather we can simply name it 4.2.8 and apply hot fixes as needed.

With that in mind, I suggest installing your Alfresco's beneath /alfresco like so:

$ cd /alfresco
$ ls


The 5.2.2, 5.2.1 and 4.2.8 are Alfresco enterprise versions while the 201707 refers to an Alfresco Community installation.

There are a few things I like to add as well like special directories and symbolic links to make searching for things a lot easier.

Below is what your standard Alfresco looks like (assuming you're using the package installer):

$ cd 5.2.2
$ ls

alf_data      amps_share  libreoffice            properties.ini  tomcat
alfresco.ico  bin         licenses               README.txt      uninstall   common  scripts         uninstall.dat
amps          java        modules                solr4

First, set up a wars directory with a version for the base install and hot fixes for the installation.

$ mkdir -p wars/5.2.2

For each hot fix, we can do:

$ mkdir wars/
$ mkdir wars/


Your war files may get changed a lot due to customizations, add-ons and module installations. So, it makes sense to copy your wars to the appropriate directory for safe-keeping in case you need to roll back:

$ cp tomcat/webapps/*.war wars/5.2.2/.

Java projects and apps are almost always horrendously nested and Alfresco follows that unfortunate convention as well. So, let's create some links so that we won't be in cd (change directory) hell later on when we need to find something:

$ ln -s tomcat/shared/classes/
$ ln -s tomcat/shared/classes/alfresco/extension
$ ln -s tomcat/shared/classes/alfresco/web-extension
$ ls

alf_data                    amps_share  libreoffice            README.txt  uninstall.dat  bin         licenses               scripts     wars
alfresco.ico                common  solr4       web-extension                 extension   modules                tomcat
amps                        java        properties.ini         uninstall

So you're aware, the extension directory is where you place your overrides for the Alfresco war and the web-extension directory is where you place your overrides for the Share war. I don't like to have to continuously change directory down 3 or 4 steps just to have a look at some settings, so I also create a symbolic link to as well.

I also prefer to have quick access to both Alfresco and Share's files so I can add debugging as needed:

$ ln -s tomcat/webapps/alfresco/WEB-INF/classes/
$ ln -s tomcat/webapps/share/WEB-INF/classes/ 
$ ls

alf_data                    amps_share     libreoffice                postgresql      solr.log  bin            licenses                   properties.ini  tomcat
alfresco.ico        README.txt      uninstall
alfresco.log                common     scripts         uninstall.dat                 extension      share.log       wars
amps                        java           modules                    solr4           web-extension

For startup purposes, I think it's good to clear the logs and then tail the new catalina.out so I can catch anything amiss on startup:

$ vi

Near the top I like to add this:


rm -rf *.log* tomcat/logs/catalina.out # Deletes previously existing log files

# Allow only root execution

And at the end I add this for tailing purposes:

# Restoring SELinux
if [ -f "/usr/sbin/getenforce" ] && [ `id -u` = 0 ] ; then
    /usr/sbin/setenforce $selinux_status 2> /dev/null

tail -f tomcat/logs/catalina.out # Shows contents of logs as they occur.

exit $ERROR

You can of course, do control-c after viewing the tail and this will not shutdown Alfresco.

Now why do I not show much concern for alfresco.log, share.log or solr.log? Because there is nothing these three will give us that won't be shown in catalina.out. Also, unless there's a good reason for it, I do not keep the diagnostic/info logs long term. If I need them for historical purposes, I'll copy them over to another directory for safe-keeping. It probably makes sense to keep access logs for analytical purposes but I've yet to find a good enough reason to keep the info logs (these can get huge in a hurry even if you don't have set debugs and traps).

And so now, we're ready to start. Out of the box, Alfresco can appear to be a bit overwhelming when it comes to management from a SysAdmin or QA tester's point of view but hopefully these tips will come in handy. They have certainly worked wonders for me.

If this blog is helpful, please consider helping me pay it backward with a coffee.

Buy Me a Coffee at