Installazione

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 session cookie to work and hence this should be remedied.
• Sending Mail from XAMPP (or from any Windows install of FA) using fake sendmail.
• If you cannot use gettext language translations on some versions of PHP (5.3.0 to 5.3.5 or thereon) on Windows (XAMPP/WAMP) the use php-gettext as shown here instead of the PHP module. It may not work for some languages and some others may need some tweaks (like LANGUAGE instead of LANG parameter). GNU gettext for Windows is also available - v0.14.4 and v0.19.8.1.
• Forum Post - In windows, some users have disabled the php_gettext.dll php extension in the php.ini file and got translations to work.
• When using FA in PHP 7.1.x, the constructors and destructors for all classes used must be renamed to __construct and __destruct as the old way of naming it as the class name is not only deprecated, it has now been removed in it's entirety from this version of PHP onwards. Forum Post: Fixes to all such files are provided for FA v2.4.2 as a patch file and as a commit by Paul Shipley as of 2017-10-02. This is now in the official FA 2.4.3+ Git Master.
• Forum Post: Fixes for locale and openssl along with IIS7 and PHP 7.1.14 on Windows 10.
• If there are random timeouts when using FA, then check if the following php.ini setting is a minimum of session.gc_maxlifetime = 1440
• Forum Post: XAMPP v1.8.2 is the last version with PHP 5.4 that is supported on WinXP SP3. Do not use XAMPP v1.8.2-6 for FA but use XAMPP 1.8.2-5 instead with the php.ini changes listed in the post and like:

short_open_tag = On
precision = 17
max_execution_time = 60
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
post_max_size = 32M
upload_max_filesize = 32M
extension=php_fileinfo.dll
extension=php_imap.dll
extension=php_openssl.dll
extension=php_pdo_odbc.dll
; date.timezone = Asia/Kolkata ; change as needed

• php_intl.dll fix for XAMPP (tested with v1.8.2.5) to get classes like Normalize to work required copying the xampp/php/icu*.dll files to the xampp/apache/bin folder.

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 installation directory tree. For example, on Ubuntu 14.04 LTS Trusty, the apache2 web-server is user www-data and belongs to the www-data group, and these must have the respective permissions rwx and r-x on at least the following directories:
  • webroot directory of FrontAccounting (e.g. on Ubuntu the server webroot directory might be /var/www/html/frontacc)
  • lang/ subdirectory
  • modules/ subdirectory
  • company/* subdirectories
  • themes/* subdirectories (only if and when installing new themes)
  • sql/* (only if and when installing a new Chart of Accounts -- also known as CoA).

• 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 (with collation type utf8_general_ci?), 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.
3. DB Clustering for Master to Master Replication: MariaDB (a drop in replacement for MySQL) as of v10.1 supports Galera Clustering and InnoDB whilst MyISAM is experimental. PDF Guide (Cache) with corrections included.
4. Tax system configuration should be done when a company is setup.

Post Installation

1. After FrontAccounting 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.
4. Import your Opening Balances if any.

Locked out on PHP / MySQL upgrade

Forum Post: Even though your username and password are correct, FA may deny access if there is no MySQL socket available as obtains when there has been a PHP / MySQL upgrade. Check tmp/error.log for any errors.

Making a training copy.

It is very often useful to have a complete copy of a FrontAccounting 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 FrontAccounting 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"
# -------------------------------------------------------------------------------------------------

Prerequisiti

• Un server web HTTP p.es. Apache o IIS
• Un server MySQL - con abilitazione delle tabelle innodb (vedi nota successiva)
• Sul server web deve essere installata una versione aggiornata di PHP comprensiva di supporto MySQL
• Adobe Acrobat Reader – o altro lettore PDF per visualizzare i report in formato PDF prima di inviarli in stampa
• php.ini può necessitare di modifiche per abilitare openssl; ricordarsi di riavviare Apache dopo le modifiche - XAMPP v1.8.1 SSL DLLs Path Fix
• Una connessione internet per scaricare Piani dei Conti (COA) ed altre chicche da o altri repository
• e, se necessario, consultare i Post nel Forum di XAMPP
• Su IIS, va utilizzato PHP Manager for IIS. E’ uno strumento per gestire una o più installazioni PHP su server IIS 7 e IIS 7.5. Necessita di MSVC runtimes
• Su Kubuntu 13.1 lanciando Install/Update Languages viene generato un errore che si risolve aumentando il valore della variabile session.gc_maxlifetime in php.ini
• Su CentOS 6.5, PHP 5.5, MySQL 5.5, Apache 2.2 si è verificato quanto segue: si è constatato che su Apache stava girando Varnish HTTP accelerator e che default.vcl era configurato in modo da disabilitare i cookie. FrontAccounting ha necessità di creare cookie di sessione per lavorare e quindi questa condizione va modificata
• Inviare Mail da XAMPP (o da altra istallazione Windows di ) usando l’istruzione fake sendmail

Note Importanti

• Uno degli aspetti critici dell’installazione di PHP è l’impostazione di session.auto_start nel file php.ini. Alcune distribuzione rpm di PHP hanno come impostazione di default session.auto_start = 1. Ciò induce l’avvio di una nuova sessione all’inizio di ogni script e rende impossibile l’instanziazione delle classi di oggetti su cui si basa il sistema, che fa un uso ampio di classi. Le sessioni devono essere avviate dal sistema secondo necessità e quindi dovete verificare che questa impostazione sia impostata a session.auto_start = 0
• Per motivi di sicurezza entrambe le impostazioni php Register Globals e Magic Quotes dovrebbero essere disabilitate. Quando si utilizza FrontAccounting su un server che fa girare php come modulo Apache, questi flag sono impostati nel file .htaccess. Quando invece il vostro server utilizza un’interfaccia CGI verso PHP dovete essere voi ad impostare magic_quotes_gpc = 0 e register_globals = 0 nel file php.ini
• Nel server MySQL devono essere abilitate le tabelle Innodb. Queste tabelle consentono l’uso delle transazioni, che sono un componente critico e sono abilitate di default nelle versioni più recenti di MySQL. Se dovete effettuarne l’abilitazione manualmente, fate riferimento al manuale MySQL
• FrontAccounting viene implementato e testato in abbinamento con MySQL. In generale dovrebbe essere in grado di funzionare con altri database, ma al momento questa opzione non è dotata di alcun supporto
• Perché lo script di installazione funzioni correttamente, il processo web-server deve avere pieno accesso read/write/execute all’albero delle directory di installazione. Per esempio in Ubuntu 14.04 LTS Trusty, il web server apache2 è l'utente www-data e appartiene al gruppo www-data, e deve essere dotato rispettivamente delle permission rwx e r-x su quanto meno le seguenti directory:
  • la directory webroot di FrontAccounting (p.es. in Ubuntu la directory webroot del server potrebbe essere /var/www/html/frontacc)
  • la subdirectory lang/
  • la subdirectory modules/
  • le subdirectory company/*
  • le subdirectory themes/* (solo se e quando fossero installati nuovi temi)
  • le subdirectory sql/* (solo se e quando fossero installati nuovi Piani dei Conti (aka CoA)

• Nelle nuove installazioni inizialmente non sono presenti i file config.php e config_db.php: vengono creati successivamente lanciando lo script di installazione. Per far sì che vengano creati, la directory webroot deve consentire l’accesso read/write/execute ai processi del web server. Il processo di installazione, oltre a tutte le estensioni scaricate in questa fase, creerà i 2 file installed_extensions.php (uno nella cartella webroot e l’altro nella cartella company/0/ – i file saranno leggermente differenti) e il file lang/installed_languages.inc

Copiare tutti i file del progetto nella directory giusta

• Ovviamente dovrete aver scaricato tutto l’archivio del progetto
• Tutti i file contenuti nel progetto andrebbero copiati in una directory sottostante la directory radice del server web
• Per esempio, create una cartella denominata /account, e estraete i file dell’archivio in questa cartella
• Se disponete di una macchina dedicata o di un VPS (Virtual Private Server) incorporate il contenuto del file .htaccess nel file conf di Apache. In Debian, un file conf di esempio in /etc/apache2/sites-available/frontac sarebbe simile a questo
• Tenete presente che FA contiene molti tipi di file con estensioni del tipo *.inc, *.sql, *.log, ecc. che potrebbero non disporre di un’associazione MIME in Apache e quindi verrebbero visualizzati come testo se il file .htaccess o il file conf di apache (quale che sia il caso) non è formulato correttamente. Non tentate di rinominare i file *.inc come *.inc.php perché in questo modo per il server web diventerebbero eseguibili, cosa che li esporrebbe ad attacchi RFI ed alla necessità di inserire sgradevoli controlli in ogni file come quello presentie all’inizio di language.php

Passi dell’Installazione

1. Se avete l’opportunità di creare database multipli sul vostro host, createne uno nuovo, p.es. frontacc; altrimenti segnatevi il nome del database assegnato al vostro account, e prendete nota di username e password del database: avrete bisogno di queste informazioni durante l’esecuzione del wizard di installazione
2. Accedete a vostra_url/account (o quale che sia la directory predisposta): verrà eseguito il wizard di installazione. Se è la prima volta che lanciate FrontAccounting, impostate l’azienda di prova (di default, Training Co.) e, opzionalmente, popolatela con dei dati iniziali di prova selezionando l’apposita check-box. E’ una buona idea familiarizzare col sistema prima di incominciare a operare con la vostra vera azienda: questa potrete crearla in seguito. Potete anche mantenere l'azienda di prova per utiizzarla in futuro per consentire la formazione di altri nuovi utenti

Dopo l’Installazione

1. Dopo aver installato correttamente FrontAccounting, è consigliabile, per ragioni di sicurezza, archiviare e cancellare, o quanto meno rinominare in modo non intellegibile, la subdirectory install, non più necessaria
2. Assegnate alla directory tmp/ l'attributo writable per il processo web-server, in modo che vi possa scrivere i file error.log
3. Trasformate in read-only i file config_db.php e config.php

Creare un’Azienda di Prova

E’ spesso di grande utilità disporre di una copia completa della propria installazione di FrontAccounting, da utilizzare sia per dei test che per finalità formative. Lo script fornito di seguito crea in modo sicuro una copia completa e funzionante di un sito esistente

Si noti che il sito di prova non viene eseguito usando l'installazione originale di FA , ma una nuova e completamente distinta. In questo modo si possono avere entrambi i siti in esecuzione ad indirizzi diversi (p.es. accounts.example.com e accounts2.example.com). In alternativa, perché tutto ciò funzioni, si dovrebbero effettuare setup separati sia del database MySQL che di vhost

Si noti parimenti che tutto ciò si basa sull’utilizzo di Apache ITK, il che significa che il processo Apache è in esecuzione come un utente determinato, proprietario di tutti i file. Ciò elimina il problema dei file che vanno caricati, dato che questo medesimo utente Apache (su Debian sarà www-data) risulta essere abilitato sia in accesso che in modifica

#!/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"
# -------------------------------------------------------------------------------------------------