Alfresco upgrade from 4e to 5d

Article still being edited.


This upgrade doc was written with the help of the following document

This is an upgrade from Alfresco 4.2.e to version 5.0.d but may well work for other versions.

I assume Alfresco 4.2.e is installed under the default directory /opt/alfresco-4.2.e

Stop Alfresco:

#service alfresco stop

Ensure that the old version does not start automatically upon reboot:

# chkconfig alfresco off

We need to find out what the database password is to dump the database:

# grep db.password /opt/alfresco-4.2.c/tomcat/shared/classes/alfresco-global.properties

This will show the current db password. e.g. here it is dbpass4.2.e


Install the newer version of Alfresco:

chmod a+x



run through all the installation prompts and when finished I let it start up, one thing I did to allow it to be installed alongside the old version to to call the start-up script alfresco-e

Once installed and started we can stop the new Alfresco:

# service alfresco-e stop

we now need to just start the database:

# su – postgres

$ /opt/alfresco-4.2.c/postgresql/bin/pg_ctl start -w -D /opt/alfresco-4.2.c/alf_data/postgresql

We now need to dump the current database:

$ cd /opt/alfresco-4.2.c/postgresql/bin

./pg_dump -Fc alfresco > backup.pgb

We now stop the old database:

$ /opt/alfresco-4.2.c/postgresql/bin/pg_ctl stop -w -D /opt/alfresco-4.2.c/alf_data/postgresql/

We now have a database dump that can be used to populate a new database in the new installation. First we have to create the database, then populate it.

we now start the new database:

cd /opt/alfresco-4.2.e/postgresql/bin/

$ /opt/alfresco-4.2.e/postgresql/bin/pg_ctl start -w -D /opt/alfresco-4.2.e/alf_data/postgresql/

After that we connect to the new postgres instance to create the new database:

$ ./psql -U postgres -h localhost

Now enter the new password (which is the admin password you used during installation of alfresco-4.2.e), if you have forgotten you will find it in /opt/alfresco-4.2.e/tomcat/shared/classes/alfresco-global.properties

Now create the database, where we will restore the data to:

postgres=# create DATABASE alfresco_42c;


The \q will quit out of the database shell

We left the database dump in the existing alfresco installation directory, so we address it from there when restoring

$ ./pg_restore -d alfresco_42c /opt/alfresco-4.2.c/postgresql/bin/backup.pgb

Now we will stop the database

$ /opt/alfresco-4.2.e/postgresql/bin/pg_ctl stop -w -D /opt/alfresco-4.2.e/alf_data/postgresql/

We now need to point the new installation to our new database:

use your favourite editor to change the database referenced by the new Alfresco:

switch back to root

$ exit

# vim /opt/alfresco-4.2.e/tomcat/shared/classes/alfresco-global.properties

change db.name=alfresco to db.name=alfresco_42c

We first delete the default installation data and then replace it with our repository data:

# cd /opt/alfresco-4.2.e/alf_data

# rm -rf contentstore  contentstore.deleted  keystore  oouser   solr  solrBackup

(this is everything in the directory apart from postgresql)

now we sync everything across:

rsync -trv –progress –exclude=”/postgresql/” /opt/alfresco-4.2.c/alf_data/* /opt/alfresco-4.2.e/alf_data

It should now be possible to restart the new repository:

# service alfresco-e restart

And test the web interface; depending upon how fast your machine is and how much data it will take some time to restart

Finally we have to copy across any global settings we may have such as mail and share settings in /opt/alfresco-4.2.c/tomcat/shared/classes/alfresco-global.properties to /opt/alfresco-4.2.e/tomcat/shared/classes/alfresco-global.properties

Last is a restart to take the new settings:

# service alfresco-e restart

Disabling services on Zimbra

This will disable snmp, you may also consider disabling logger and stats.

zmprov ms server.hostname.se -zimbraServiceEnabled snmp



Connecting to a squid proxy securely

Squid allows the use of https_port to specify a port that it will accept proxy requests over SSL.

An example is as follows in the squid.conf file:

https_port 8123 cert=/etc/pki/tls/private/squid.pem

I am using port 8123 as it is already a port allowed under the default SELinux installation on Red Hat Enterprise Linux. The cert instruction is the path to the SSL cert in PEM format. If you do not specify the key Squid assumes it is bundled in the SSL cert PEM file.

Don’t forget to open the firewall port.

At present Firefox and Chrome support connecting to the squid proxy over SSL, though one must use a pac file at the moment rather than the internal application settings.

An example pac file looks like:

cat /var/www/html/wpad.pac
function FindProxyForURL(url, host) {
return “HTTPS proxy.example.com:8123;”

You can then stick the pac file on a friendly web server or on your local file system and point the web browser in the configuration settings.

You can also launch chrome from the command line on mac with the following settings:

open ./Google\ Chrome.app  –args –proxy-server=https://proxy.example.com:8123

Windows will take similar settings details here:


Check your proxy logs to ensure that the proxy is functioning.

PLEASE NOTE: Chrome and Firefox will not take the secure proxy settings in their application configuration settings. They require the use of a proxy.pac / wpad.dat file to function. If you configure the secure proxy in the application settings the web browser will fail to connect and throw an error.

Zimbra upgrade from 8.0.7 to 8.50

The upgrade went smoothly. The hiccoughs I had were based on the move of the Postfix postfix_transport_maps to LDAP and the decision to stop supporting hash function in the postfix transportfile from 8.50 onwards. This meant that the setting was broken and then migrated to LDAP.

The error message printed in zimbra.log is:

postfix/trivial-rewrite[22832]: warning: hash:/opt/zimbra/postfix/conf/transportfile is unavailable. unsupported dictionary type: hash

I could see the setting, which had the default setting and the server specific setting. The first output is the global setting that has been migrated, the second is the server specific setting:

zmprov getConfig zimbraMtaTransportMaps

The original result provided two results:

zimbraMtaTransportMaps: proxy:ldap:/opt/zimbra/conf/ldap-transport.cf
zimbraMtaTransportMaps: hash:/opt/zimbra/postfix/conf/transportfile proxy:ldap:/opt/zimbra/conf/ldap-transport.cf

What I want in the end result is:

zimbraMtaTransportMaps: lmdb:/opt/zimbra/postfix/conf/transportfile proxy:ldap:/opt/zimbra/conf/ldap-transport.cf

To change this setting I used to be able to use zmprov; however the new setting is set in LDAP, which will require the use of        .

To start there is a very useful page here: https://wiki.zimbra.com/wiki/Ajcody-LDAP-Topics that gives some great tips to be able to do queries on the Zimbra LDAP database.  Changing to the zimbra user and sourcing the correct variables allows us to do very easy queries. We can do:

su – zimbra source ~/bin/zmshutil zmsetvars ldapsearch -x -H $ldap_master_url -D $zimbra_ldap_userdn -w $zimbra_ldap_password

We are now given the full LDAP dump, which we can pipe through grep to find the transport settings:

ldapsearch -x -H $ldap_master_url -D $zimbra_ldap_userdn -w $zimbra_ldap_password | grep transport

I found two entries here as I mentioned, I want to change both of them.

I ought to be able to do this using zmprov and the zimbraMtaTransportMaps key. There is no example that I could find on the Internet and rather than experiment on the server I cheated and used a graphical LDAP editor to change the setting from hash to LDAP.

I browsed through config and then servers to find the global setting and then the server specific setting respectively.

Now when I run:

zmprov getConfig zimbraMtaTransportMaps

I get the correct result and Zimbra starts accpeting email again.

LDAP Zimbra login screen

LDAP Zimbra login screen

Zimbra LDAP browser

Zimbra LDAP browser

Comments Off on Zimbra upgrade from 8.0.7 to 8.50 more...

Failure to change Passwords on SugarCRM

It seems that there is a bug in the default install for SugarCRM version 6.5 The error received is something like:
Please provide a new password. Incorrect current password for user. Re-enter password information.

One can work around this error by going to Admin, then setting:
System-Generated Password Expiration to None.

While this is not ideal, I assume that this will be fixed in the next release.

Mounting an encrypted drive

he drive I am using here is a USB drive that has been mounted and encrypted on my laptop running RHEL6 (Red Hat Enterprise Linux 6). I want to mount on a server also running RHEL6.

I run dmesg and I can see that the server recognises it as /dev/sdb:

USB Mass Storage support registered.
usb-storage: device scan complete
scsi 2:0:0:0: Direct-Access     Maxtor 6 Y120M0                PQ: 0 ANSI: 2 CCS
scsi 2:0:0:1: Direct-Access     WDC WD50 00AAKS-00YGA0         PQ: 0 ANSI: 2 CCS
scsi 2:0:0:0: Attached scsi generic sg1 type 0
scsi 2:0:0:1: Attached scsi generic sg2 type 0
sd 2:0:0:0: [sda] 240121728 512-byte logical blocks: (122 GB/114 GiB)
sd 2:0:0:1: [sdb] 976773168 512-byte logical blocks: (500 GB/465 GiB)



The operating system needs a device to talk to the under-lying encryption, to create this device on the new server we can use the cryptsetup utility. I am going to call the disk device d500.


cryptsetup luksOpen /dev/sdb1 d500


We can now look for the new device:

ls /dev/mapper/
control  d500  vg_lump-lv_root  vg_lump-lv_swap


Before we mount the disk we need a directory to mount it to.

mkdir /mnt/d500


Then mount the disk:

mount /dev/mapper/d500 /mnt/d500


We can also see the disk is now mounted:

df -h
/dev/mapper/d500      459G  198M  435G   1% /mnt/d500


If we want the disk to automatically mount upon boot we need to create an entry in /etc/fstab

If you need this to survive a reboot then an entry needs to be entered in /etc/crypttab so that the dev/mapper device is created at every reboot.

The fields are:

Name (that will be created under /dev/mapper/[name])   Device (often identified by UUID) and options (such as password to decrypt)

You can get the UUID by running the command


This will give you by default the UUIDs of all devices on the system.

You can then edit


then add something like:

d500    UUID=2e23233fc-2323-49ba-a239-2872642-fd733219 none

Then when the system boots it will ask for the relevant password.

Adding a disk for SElinux & virt

A short one this.

Add the directories, set the contexts and then restore the contexts.

Still working on disk /mnt/d500


Create the directories I want to use:

mkdir -p /mnt/d500/libvirt/images


Set the context for the libvirt directory:

semanage fcontext -a -t virt_var_lib_t "/mnt/d500/libvirt"


Set the context for the images directory:

semanage fcontext -a -t virt_image_t "/mnt/d500/libvirt(/.*)?"


Then write the contexts:

restorecon -R /mnt/d500/

Then check the contexts:

ls -lZd /mnt/d500/libvirt/images/


Copyright © 1996-2013 Xander Harkness. All rights reserved.
iDream theme by Templates Next | Powered by WordPress