Pre-requisites

  • A working HTTP web server eg. Apache, IIS.
  • A working MySQL server - with innodb tables enabled (see notes below)
  • PHP installed on the web server with MySQL support.
  • Adobe Acrobat Reader - or another PDF reader for viewing the PDF reports before printing them out.
  • php.ini may need to be edited to enable openssl and Apache restarted - XAMPP v1.8.1 SSL DLLs Path Fix
  • Connection to internet is essential so that COAs and other goodies can be downloaded from the repo.frontaccounting.eu and other personal / custom repos.
  • XAMPP related Forum Post
  • On IIS, use PHP Manager for IIS. It is a tool for managing one or many PHP installations on IIS 7 and IIS 7.5 servers. Will need MSVC runtimes.
  • On Kubuntu 13.1 trying to Install/Update Languages will result in an error that is resolved by increasing the session.gc_maxlifetime variable in php.ini
  • On CentOS 6.5, PHP 5.5, MySQL 5.5, Apache 2.2 the following was tested and found that Varnish HTTP accelerator was running in front of Apache and the default.vcl was configured to strip cookies. FrontAccounting needs to create a seession cookie to work and hence this should be remedied.

Important Notes

  • One critical aspect of the PHP installation is the setting of session.auto_start in the php.ini file. Some rpm distributions of PHP have the default setting of session.auto_start = 1. This starts a new session at the beginning of each script. However, this makes it impossible to instantiate any class objects that the system relies on. Classes are used extensively by this system. When sessions are required they are started by the system and this setting should be set as session.auto_start = 0.
  • For security reasons both Register Globals and Magic Quotes php settings should be set to Off. When FrontAccounting is used with www server running php as Apache module, respective flags are set in .htaccess file. When your server uses CGI interface to PHP you should set magic_quotes_gpc = 0 and register_globals = 0 in php.ini file.
  • Innodb tables must be enabled in the MySQL server. These tables allow database transactions which are a critical component of the software. This is enabled by default in the newer versions of MySQL. If you need to enable it yourself, consult the MySQL manual.
  • FrontAccounting is implemented and tested with MySQL. Generally it should work with other databases, but this is not supported in any way at the moment.
  • In order for the install script to run properly, the web-server process must have full read/write/execute access to the following directories:
    • root directory of FrontAccounting (ie. public_html/account)
    • lang/ subdirectory
    • modules/ subdirectory
    • company/* subdirectories
    • themes/* subdirectories (only if and when installing new themes)
    • sql/* (only if and when installing new Chart Of Accounts)
  • New installations will not have file called config.php and config_db.php. They get created by the install script. In order for it to be written, the webroot directory of the installation must have read/write/execute access for the web-server process at least. Other files created during a new install will be 2 installed_extensions.php files (both in webroot folder and in the company/0/ folder - the files are slightly different) and lang/installed_languages.inc besides any extensions downloaded during the install.

Copying all the project files to the correct directory

  • You must obviously have downloaded the project archive to be reading this file.
  • All the files inside this archive should be copied to a directory under the web server root directory.
  • For example, create a folder called /account, and extract the archive into this folder.
  • If you have a dedicated machine or VPS, then incorporate the contents of the .htaccess file into the apache conf file. In Debian, a sample apache conf file at /etc/apache2/sites-available/frontac would be like this.
  • Please note that FA has many file types like *.inc, *.sql, *.log, etc which may not have MIME association in Apache and will result in getting displayed as text in the browser if the .htaccess file or the apache conf file (as the case may be) is not properly done. No attempt to rename the *.inc files to *.inc.php is done as they would then be executable by the web server exposing them to RFI attacks needing ugly checks on every file like the one at the top of language.php file.

Installation Steps

  1. If you have the option to create multiple databases on your host, create one, for instance say frontacc, otherwise write down the database name for your account. At the same time look up the username and password for the database. You will need this information during the wizard install.
  2. Enter your_url/account (or whatever directory you entered). This will run the install wizard. If this is the first time you've run FrontAccounting, setup the training company (Training Co. by default) and, optionally, populate it with initial demo data by ticking (click) the check-box. It is a good idea to get familiar with the system before starting your own company. Later, you can create your own real company. You may also want to consider keeping the training company for training other/future employees.

Post Installation

  1. After Front Accounting has been successfully installed, it is highly recommended to archive and remove or atleast cryptically rename, the install sub-directory for safety reasons. It is no longer needed.
  2. Make the tmp/ directory writable by the web-server process so that error.log files can be written.
  3. Change config_db.php and config.php to read-only.

Making a training copy.

It is very often useful to have a complete copy of a Front Accounting installation for training purposes. The following script will make a safety dump of a live site and load it as a copy of that site.

Please note - this does not use the same FA installation to run the training copy - but uses a whole FA installation. This is useful as it is then possible to have the sites running at different addresses - for example - accounts.example.com and accounts2.example.com. For this to work there should be a separate MySQL database set up and a separate vhost set up.

Please note as well - this is based on using Apache ITK which means that the Apache process runs as an assigned user and so all files can belong to the same server account. This cuts out the issue of files needing to be uploaded as one user then accessible/modifiable by the Apache user (on Debian this is www-data).


#!/bin/bash

# copy_accounts_to_accounts2

# ----------------------------------------------------------------------------------
# This will take a copy of the live Open Atrium site and copy it to a training copy.
# ----------------------------------------------------------------------------------

# -------------------------------------------------------------------------------------------------
# Logging setup
# -------------------------------------------------------------------------------------------------

# Here we can save the output from running this script to a log file.
# These lines have been copied from 
# http://stackoverflow.com/questions/3173131/redirect-copy-of-stdout-to-log-file-from-within-bash-script-itself
# and will send the script output to a log file.
# Uncomment them if you want to use them.
#mkdir -p ~/logs
#DATE_TIME=`date +%Y%m%d-%H%M%S`
#logfile=~/logs/copy_accounts_to_accounts2_${DATE_TIME}.log
#mkfifo ${logfile}.pipe
#tee < ${logfile}.pipe $logfile &
#exec &> ${logfile}.pipe
#rm ${logfile}.pipe

DATE_TIME=`date +%Y%m%d-%H%M%S`

# -------------------------------------------------------------------------------------------------
echo
echo `date`
echo "Backup primary site..."
# -------------------------------------------------------------------------------------------------

# Here we will create backups which are datetime stamped to be able to go back to a previous 
# version if necessary.
mkdir -p /home/frontacc/backups
mysqldump frontacc > /home/frontacc/backups/${DATE_TIME}_frontacc.sql
tar --create --file=/home/frontacc/backups/${DATE_TIME}_frontacc.tar /home/frontacc/public_html

# Here we will make a backup to a standard location so that it is backed up by backup scripts.
# This will also be the backup we will load into the copy site.
mysqldump frontacc > /var/backups/frontacc.sql
tar --create --file=/var/backups/frontacc.tar /home/frontacc/public_html

# -------------------------------------------------------------------------------------------------
echo
echo `date`
echo "Load the backup into the site..."
# -------------------------------------------------------------------------------------------------
mysqladmin --force drop frontacc2
mysqladmin create frontacc2

mysql frontacc2 < /var/backups/frontacc.sql

rm -r /home/frontacc2/public_html/*
tar -x --file=/var/backups/frontacc.tar --directory=/home/frontacc2/public_html --strip-components=3 

# We need to change ownership for the files just unzipped.
chown -R frontacc2:frontacc2 /home/frontacc2/public_html

# -------------------------------------------------------------------------------------------------
echo
echo `date`
echo "Change the database settings - this could probably be done better..."
# -------------------------------------------------------------------------------------------------
sed -i 's/Company Name/Company Name2/g' /home/frontacc2/public_html/config_db.php
sed -i 's/frontacc/frontacc2/g' /home/frontacc2/public_html/config_db.php
sed -i 's/live_copy_mysql_password/training_copy_mysql_password/g' /home/frontacc2/public_html/config_db.php

# -------------------------------------------------------------------------------------------------
echo
echo `date`
echo "Setting up the copy site with a different appearance from the live site..."
# -------------------------------------------------------------------------------------------------
# This is useful to make help the users to see which site they are working on.
# Again, there may be a more elegant solution for this.
sed -i 's/285b86/ff0000/g' /home/frontacc2/public_html/themes/default/default.css

# -------------------------------------------------------------------------------------------------
echo
echo `date`
echo "A restart of Apache is needed for the site to work..."
# -------------------------------------------------------------------------------------------------
/usr/sbin/apache2ctl restart

# -------------------------------------------------------------------------------------------------
echo
echo `date`
echo "Finished"
# -------------------------------------------------------------------------------------------------