Alfresco - Alfresco Setup for Sysadmins and QA Testers
Published on Sun, 14 Jan 2018
By Harlin Seritt
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 126.96.36.199. 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 5.2.2 5.2.1 201707
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 alfresco.sh common manager-linux-x64.run 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/188.8.131.52 $ mkdir wars/184.108.40.206 etc.
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/alfresco-global.properties $ 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 alfresco-global.properties bin licenses scripts wars alfresco.ico common manager-linux-x64.run solr4 web-extension alfresco.sh 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 alfresco-global.properties as well.
I also prefer to have quick access to both Alfresco and Share's log4j.properties files so I can add debugging as needed:
$ ln -s tomcat/webapps/alfresco/WEB-INF/classes/log4j.properties log4j-alfresco.properties $ ln -s tomcat/webapps/share/WEB-INF/classes/log4j.properties log4j-share.properties $ ls alf_data amps_share libreoffice postgresql solr.log alfresco-global.properties bin licenses properties.ini tomcat alfresco.ico clear-repo.sh log4j-alfresco.properties README.txt uninstall alfresco.log common log4j-share.properties scripts uninstall.dat alfresco.sh extension manager-linux-x64.run 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 alfresco.sh
Near the top I like to add this:
#!/bin/sh 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 fi 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.