FAQ

FAQ Category: Installation

Please note that these instructions assume you have installed LedgerSMB from tarball.

There are two steps to upgrading a LedgerSMB 1.5.x installation to 1.5.y (x smaller than y):

  1. Upgrade the software
  2. Upgrade the company database

The last step has to be executed for each company database that's set up.

Note that all the steps below are prefixed with the 'sudo' command, but these can be executed as 'root' directly as well.

 

Upgrading the software

This is by far the easiest part. These are the steps to go through, assuming an installation from tarball:

  • Stop the LedgerSMB application server (e.g. Starman)
    $ sudo service starman-ledgersmb stop
  • Back up the old software by moving it out of the way (assuming you installed in /usr/local/ledgersmb):
    $ sudo mv /usr/local/ledgersmb /usr/local/ledgersmb.backup
  • Untar the tarball into /usr/local/ledgersmb:
    $ sudo tar xf ledgersmb-1.5.x.tar.gz --directory /usr/local
  • Copy the configuration file from the old installation:
    $ sudo cp /usr/local/ledgersmb.backup/ledgersmb.conf /usr/local/ledgersmb/
  • Start the LedgerSMB application server again (Starman example given, as before):
    $ sudo service starman-ledgersmb start

Upgrading the company database

After the software has been upgraded, the company database(s) have to be upgraded. When a user logs in on a database which is of a version different from the software that's used to access the database, a "Database version mismatch" error will be generated.

To upgrade the company database from the Web UI, navigate to the setup.pl page (e.g. when you're hosting your LedgerSMB on https://localhost/ and normally log in through https://localhost/login.pl, now you need to navigate to https://localhost/setup.pl). Log into setup.pl with the database admin credentials (the "lsmb_dbadmin" user, if you followed the installation instructions).

After login, setup.pl will show a sccreen with the following at the top:

 

Logged in as lsmb_dbadmin
LedgerSMB 1.5 db found
Rebuild/Upgrade?

By clicking the "Yes" button, the company database upgrade process will be executed.

Repeat this process for all company databases.

Upgrading Dojo (installs from Git only)

When tracking the GitHub Git repository, not much more is required for an upgrade than to pull all changes from the server and restart Starman. However, on some releases, Dojo Toolkit will be upgraded. (One such release is the 1.5.13 release.) In order to update the installed Dojo version, run these commands:

$ git submodule foreach git remote update -p
$ git submodule update

With the source Dojo now up to date, the Dojo built JavaScript assets need to be regenerated:

$ make dojo

After these have been completed, make sure all browser sessions are being freshly restarted.

Before starting to update to 1.5, the following are differences to be aware of between 1.4 and 1.5:

  • JavaScript in the browser
  • Additional data constraints
  • PSGI / Apache configuration
  • Printed document templates (e.g. invoice templates)
  • Database schema maintenance

See below for explanations of each of these differences.

 

Important note: before trying to migrate your database to a new version of LedgerSMB, create a backup of the database!

Upgrading from 1.4

The upgrade process for from-tarball installs works the same as the upgrades between 1.4.x and 1.4.y versions (assuming installation in /usr/local/ledgersmb):

  • Stop the server processing LedgerSMB's web requests, by either
    • Stopping Apache (when using a CGI setup -- this is the usual case)
      $ sudo service apache2 stop
      or
      $ sudo /etc/init.d/apache2 stop
    • Stopping Starman (when using PSGI setup)
      $ sudo service starman-ledgersmb stop
  • Move the current software aside:
    $ sudo mv /usr/local/ledgersmb /usr/local/ledgersmb.backup
  • Untar the new software:
    $ sudo tar xf ledgersmb-1.5.x.tar.gz --directory /usr/local

From here, follow the general 1.5 installation instructions.

When done with the installation process, be sure to continue with the company database upgrade instructions.

Upgrading from 1.3

Please follow the instructions for upgrades from 1.4.

Data from 1.3 is migrated to 1.5 by creating a new database schema (new tables) and populating that from the existing 1.3 tables. As 1.4 and 1.5 have added numerous new data integrity constraints, a number of checks have been implemented to validate if a data migration can be successful: pre-migration checks.

Please note that edited data during the pre-migration checks is saved to the original 1.3 database (if you're not running the migration on your backup).

Even if the pre-migration checks succeed, it's happened that the migration still fails. If this is the case with your data, please contact the developers mailing list or the LedgerSMB channel on Matrix.

Upgrading from 1.2

Please follow the instructions for upgrades from 1.4.

Data from 1.2 is migrated to 1.5 by creating a new database schema (new tables) and populating that from the existing 1.2 tables. As 1.3 through 1.5 have added numerous new data integrity constraints, a number of checks have been implemented to validate if a data migration can be successful: pre-migration checks.

Please note that edited data during the pre-migration checks is saved to the original 1.2 database (if you're not running the migration on your backup).

Even if the pre-migration checks succeed, it's happened that the migration still fails. If this is the case with your data, please contact the developers mailing list or the LedgerSMB channel on Matrix.

There's an added complexity to migrations from 1.2 when compared to migrations from 1.3: the user accounts are not migrated. We'd like to address this issue but are unaware of any users currently in need of migrating from 1.2. Please contact the developers mailing list or LedgerSMB channel on Matrix if you experience this problem. We'd like to help and fix our migration code to help any others who still might need this migration.

Upgrading from 1.1 or earlier

There are no direct upgrades from 1.1 or 1.0. Please first upgrade to any version 1.2 through 1.4 before upgrading to 1.5.

Key areas where 1.5 and 1.4 differ

JavaScript in the browser

While JavaScript was mostly optional in all releases prior to 1.5, having it enabled is a hard requirement for the correct operation of LedgerSMB 1.5 and newer.

Additional data constraints

Unlike the 1.3 -> 1.4 upgrade, the upgrade from 1.4 to 1.5 works fully in-place, just as the patch version upgrades within release series. The following constraints have been added and data stored in the database in violation with these constraints may block a successful upgrade:

  • Number of items sold in sales, out of a purchase invoice, may not exceed the total number in the purchase
  • Items in an order are required to exist as parts or services
  • Items in the pricematrix are required to exist as parts or services
  • Make/model details are required to belong to an existing part

PSGI / Apache configuration

The 1.5 release for LedgerSMB doesn't support CGI installation, meaning that the top-level *.pl files have been removed. Instead, LedgerSMB now uses PSGI, a "glue" framework for Perl web applications and their web servers. PSGI allows LedgerSMB to handle requests with much better response times, because the large parts of the application are kept in memory between requests.

To run a PSGI web application, one needs a PSGI compatible web server. The goto PSGI compatible web server is Starman. For production setups exposed to the web, Starman suggests to run behind a so-called reverse proxy.

Apache or Nginx can serve as reverse proxies. Running behind a reverse proxy has two major benefits:

  1. The setup reduces the exposed code footprint to the (highly audited) code of Apache or Nginx
  2. The reverse proxies can handle static content (JavaScript, CSS, images) directly; they do this much more efficiently

In the conf/ directory, there are reverse proxy configuration files for Apache, Nginx and Varnish. There are systemd service configuration files for a ledgersmb starman service as well.

Full installation instructions for the reverse proxy setup can be found elsewhere on this site.

Printed document templates

As of version 1.5, printed document templates are entirely retrieved from the database, including INCLUDEd templates. This differs from 1.4 in the sense that INCLUDEd documents were retrieved from disk while the top-level templates were read from the database. Due to this change in handling, the following changes were required:

  • Inclusion of the letterhead
  • Included files are no longer included with extension

Inclusion of the letterhead

In 1.4, the LETTERHEAD template was included as:

<?lsmb LETTERHEAD ?>

For 1.5, this should be changed to

<?lsmb INCLUDE letterhead ?>

Included files are no longer included with extension

In 1.4, the base check template would be included into "check.tex" as:

  <?lsmb PROCESS check_base.tex ?>

This no longer works in 1.5, due to the fact that the extension isn't supported anymore. The new syntax has become:

  <?lsmb PROCESS check_base ?>

Database schema maintenance

In the 1.4 series, database schema maintenance was done by loading the file sql/modules/Fixes.sql. This process caused a confusing amount of spurious errors and has been replaced by the mechanism in sql/changes/ which separates each schema change out into its own file.

The table below lists the compatibility of LedgerSMB versions with Perl versions. Products for which support has ceased due to End-of-Life date being reached are not listed and should not be used.

PostgreSQL compatibility
PostgreSQL1.4.x1.5 planned1.6 planned
5.10yesyesno
5.12yesyesno
5.14yesyesyes
5.16yesyesyes
5.18yesyesyes
5.20yesyesyes
5.22yesyesyes
5.24yesyesyes

Versions 1.0, 1.1, 1.2 and 1.3 are not in this table due to the fact that they're past End of Life.

## At the terminal, and from your LedgerSMB directory:
### Start Starman

starman  tools/starman.psgi

Default port is 5000.

starman -l :8080 tools/starman.psgi

Start with 8080 specified as the port.

Note: some documentation specifies the switch

--preload-app

It has been sugggested that this may give performance advantages in a production environment but isn't recommended while developing.
The manpage has more to say on this.

man starman

Based on that we currently would not recommend using --preload-app even on a production server

### While Starman is running

#### Reload Starman

pkill -HUP -f "starman master"

#### Restart Starman {#RestartStarman}

pkill -TERM -f "starman master"

#### Release the port if Starman is terminated
NOTE: try [Restart Starman](#RestartStarman) before doing this.

pkill -KILL -f "starman master"

First of all, you need to backup all your company databases followed by an upgrade of your PostgreSQL installation. There are plenty of places on the web to explain how to do that. The high-level process is to install the two versions in parallel and run the pg_upgradecluster command.

When the technical upgrade has succeeded, however, you're not ready to see the performance improvements promised by the 8.4+ versions of PostgreSQL with respect to the menu-generation. This is because the database doesn't automatically use the new 8.4+ code definitions.

To take advantage of the performance improvements of 8.4+, you'll need to re-run setup.pl on all your company databases. With each of the databases, you can clean up after having run setup.pl: the tablefunc contrib is no longer required, meaning you can

psql -U ledgersmb -d -f /uninstall_tablefunc.sql

On my own database I needed to run the above command three times to make it stop reporting "ERROR: Can't DROP because other objects depend on it." (On each round the number of other errors increased: on each round the number of objects successfully being dropped increased.)

That should do it. You should have a clean 8.4+ PostgreSQL database with LedgerSMB.

Yes; there's at least one known (relatively current) story at https://wiki.koumbit.net/LedgerSmbUpgrade#A1.2.25_to_1.3.18 (written by 'anarcat' on irc)

In general: neither. The advice is to have the full source tree in /opt/ledgersmb/<version>.

Installing the LedgerSMB modules in the standard Perl search path works, but interferes with running different versions side-by-side.

To undo installation in /usr/local:

  • remove /usr/local/share/perl/5.XX.X/LedgerSMB/
  • delete /usr/local/share/perl/5.XX.X/LedgerSMB.pm; and
  • find and remove the .pl files that come in LedgerSMB's project root directory and bin/ and LedgerSMB/Scripts/ directories.

The default configuration limits access to the /ledgersmb/login.pl page to connections from localhost (127.0.0.1) only for maximum security.

If you want to allow connections from other locations, it's highly advisable to use encrypted (VPN) connections to access your ledger in order to maintain good security.

Q: This particular merchant runs Windows. I don't think they have a pole display, though I can check. Ideally, it would be great to accommodate, with or without pole display. If it runs better on Linux, going forward I would propose Linux workstations for new merchants.

Ok. Let's first explain what the problems we have to solve are, then discuss the solutions that are bundled.

In general web browsers are engineered so that malicious sites can't access your computer's hardware. In general we don't want to change the browser (for example with an add-on) to make it do this because there might be a capacity for abuse elsewhere. So things like receipt printers, pole displays, cash drawers, and barcode scanners cannot be directly be accessed by the browser. This makes a web-based point of sale rather challenging, but we have solutions to these problems. The solutions though are only tested on Linux. On Windows they will require slight modification and I would recommend some extra testing. Backup/fallback methods are discussed below as well.

What we do instead preferably is to turn the point of sale terminal into a server for the point of sale hardware. Scripts to do this (written in Bash) are in the utils/pos directory of the LedgerSMB installation. the client-side script is pos-hardware-client-startup-script which basically fires up netcat and listens for data to redirect to a hardware port. You probably want to use firewall software to limit this traffic to approved servers. The ports are configurable on both ends. On the LedgerSMB side, see the pos.conf.pl.

The other is directnet.pl which is used to send printable documents over this (and to the POS printer on the other side). This is designed to be a low-latency alternative to using CUPS and the like. It redirects pole display logic usually to a serial port, and the printer logic to a parallel port.

This means you can use any printer that accepts ESC/POS and it will send signals to open the cash drawer (programmable in the pos.conf.pl) if the cash drawer is the kind that plugs into the printer. You can also use a pole display although currently we only have drivers for the LC3000 by Logic Controls. The drivers are really easy to write though. Feel free to ask for help or contribute one.

Barcode scanners and magnetic stripe readers need to come into the computer as keyboard input. Typically this means a keyboard wedge interface for magstripe readers, and either a keyboard interface for a barcode scanner, or a barcode scanner attached to a POS keyboard with a built-in barcode decoder. I have had better luck with the latter in terms of long-term maintenance, but they both work.

On to the pos.conf.pl. The default values here are in the pos.conf.pl.template, so please cp pos.conf.pl.template pos.conf.pl

For the miost part this defines a single variable for storing the information called $pos_config. Keys for this and their significance are:

rem_host: Remote host to send pole display/printer info to. By default this is the remote host. However if you are running X11 applications remotely you may have to change this.

pd_host; Host for the pole display. Defaults to rem_host
pd_port: Port for the pole display. Defaults to 6601
pd_proto: Protocol for pd. Either 'tcp' or 'udp' defaulting to udp.

rp_host
rp_port
rp_proto

Same as pd_* above but for printer

rp_cash_open: The code to open the printer. Defaults to those for the Epson U220D iirc, which is binary string of values 27, 112, 0, 25, 250

coa_prefix: prefix for the till amounts. If you have a till '16' and a coa_prefix of 1300, the till account will be 1300.16. This account must exist or you will get errors.

close_cash_accno: Cash account to put closing cash into. Must exist by closing time.

$pos_sources is used to define memo fields for different types of payment. You can customize this as you want.

$pos_source_default is the default for the sources drop down.

curren is the currency
breakdown covers your currency denominations. Used in closing. I dont know if you want to add a 0.5 as 50 cent piece there since those are rare.

till_type is either the 'cashier' meaning the employee id becomes the till number or 'terminal' in which the last octet of the IP address becomes the till number. If you need to customize this handling you can do so underneath the request to stop editing at a certain point.

Advanced options include

source_accno_override used to override cash account handling of various sources (such as gift certs for example)

disable_tables is no longer necessary. But you can use this if you aren't using projects and/or departments. It defaults to disabling everything.

If the directnet approach for printing does not work for you you can comment out the printer definition at the bottom of the pos.conf.pl and set up cups to process and send the file to the workstation to be printed. This adds a few seconds often, however, so where directnet works, it is preferred especially in time-critical point of sale environments.

Q : Brian Wolf
A: Chris Travers
Source: http://permalink.gmane.org/gmane.comp.finance.ledger.smb.user/6290

By Steven Marshall

I found something very interesting. I created a test HTML page containing solely text called testpage.html. I dropped this file in two locations. One in the Apache root directory (/srv/www/htdocs/) and the other in the ledgersmb directory (/user/local/ledgersmb/). I changed ownership of the file to wwwrun:www. I then ran the following tests:

Test 1:
URL: http://192.168.1.10/testpage.html
Results: Page loaded almost instantaneously.

Test 2:
URL: http://192.168.1.10/ledgersmb/testpage.html
Results: Page loaded in about 14 seconds

It seems to be choking on page loads for files that reside in the ledgersmb directory. My ledgersmb-httpd.conf is located in my ledgersmb directory at /usr/local/ledgersmb. I had added my "Include /usr/local/ledgersmb/ledgersmb-httpd.conf" to the bottom of default-server.conf.

I believe I have solved the issue. I am still testing just to make sure, but it appears that my issue was in ledgersmb-httpd.conf. In the section where by default you "Allow from localhost", I had changed to the following adding two additional "Allow from" statements so that I could connect remotely to Ledgersmb:

Order Deny, Allow
Allow from 127.0.0.1
Allow from localhost
Allow from 192.168.1
Deny from All

It appears that it was struggling with the multiple "Allow from" statements. Based on Apache documentation I believe I should have been able to do it this way, but I decided to change it to the following, using just one "Allow from" statement and separating the addresses with spaces, and my performance issue cleared up. This is what my modified version that works looks like:

Order Deny, Allow
Allow from 192.168.1 localhost 127.0.0.1
Deny from All

Source: http://archive.ledgersmb.org/ledger-smb-users/msg05639.html

I manage several companies on LedgerSMB, can I login to any of these companies with one user?
Applies to LedgerSMB 1.3.x -->
V. 0.1 - 22. Nov 2011

I have 100 companies though on my system and decide to change my password, wouldn't I have to change it a 100 times (one for each company)? What would be the best approach to setting up a user that could be used on several companies (databases)?

In LedgerSMB all your users are database users in PostgreSQL. All PostgreSQL users do not have access to login with LedgerSMB on each company database(s). LedgerSMB has to give access to each user as an LedgerSMB application user, even if the user have PostgreSQL superuser rights on the database level.

You can add the Postgresql user to be a LedgerSMB application user when you make an new database or after the database is created. If you import the account into all the other databases, the password management is consistent cross the databases. However, you are not guaranteed the same permissions on all databases. You could have one set on one database and another set on another.

Fast route: User get "Manage Users" or "Full Permissons" access to LedgerSMB
Use setup.pl to create company database number 1 with ledgersmbdbadm user.
Add a normal application user in the proses ("Enter User" screen) example: your_100_db_user_name

Use setup.pl to create company database number 2, 3, 4... with ledgersmbadm user (or a special admin user for each db).
Import the normal application user you made in database 1 ("Enter User" screen in setup.pl)
Username: your_100_db_user_name
Password: Do not set a password. Leave it blank
Import : Yes
Fill inn first name, last name and select Country and assign permissions.

You can also add the user to the db later:
System->Admin Users->Add Users
Username: your_100_db_user_name
Password: Only set a password in the firstdb. Leave it blank in db 2, 3, 4..
Import : Yes
Fill inn first name, last name and select Contry and assign permissions.

If you add the users later you have the opions to add only the permissions the user needs to do a spesific task.

Technical solution:
From LedgeSMB use this user to setup the database you create a databaseuser with Superuser priviliges.
CREATE USER ledgersmbdbadm WITH superuser password 'somepassword';

Create a normal user
CREATE USER your_100_db_user_name WITH password 'somepassword';
(normal user with no drop db rights)

When you create the db:
Use setup.pl to make the company database(es). Use the ledgersmbdbadm user to login to create the company database (first screen) and add a new user on the ("Enter User" screen)
Username: your_100_db_user_name
Password: Do not set a password. Leave it blank
Import : Yes
Fill inn first name, last name and select Contry and assign permissions.

You can add the user to the db later:
System->Admin Users->Add Users
Username: your_100_db_user_name
Password: Do not set a password. Leave it blank
Import : Yes
Fill inn first name, last name and select Contry and assign permissions.

If you add the users later you have the opions to add only the permissions the user needs to do a spesific task.

Direct login to correct company, take a look at this:
/faq/can-ledgersmbloginpl-take-arguments

Compiled from this e-mail treads:
http://permalink.gmane.org/gmane.comp.finance.ledger.smb.user/5334
http://permalink.gmane.org/gmane.comp.finance.ledger.smb.user/5356
Question from: Steven Marshall
Answer from Håvard Sørli and Chris Travers

 

Short error:
Math::BigInt: couldn't load specified math lib(s), fallback to Math::BigInt::FastCalc

Full error message:
[Thu Nov 10 22:53:58 2011] [error] [client 127.0.0.1] Math::BigInt: couldn't load specified math lib(s), fallback to Math::BigInt::FastCalc at /usr/local/share/perl/5.10.1/LedgerSMB/Form.pm line 61, referer: http://localhost/ledgersmb/menu.pl?login=username&menu=1&id=103&open=:

What should you do with this? Nothing or install math libs

From irc:
ehu: you can run without it, just slower.
ehu: but you can install it and rid yourself of the error reported.

Install Math:BigInt:GMP to get rid of the message.

Debian:
apt-get install libmath-bigint-gmp-perl

Ubuntu 10.4 LTS:
sudo apt-get install libmath-bigint-gmp-perl

RPM (Centos, Redhat...)
perl-Math-BigInt-GMP is available from the rpmforge repository - http://repoforge.org/

From irc:
haso: The setup script do not check for it. ... Should it ?
ehu: well, since you can run without, I don't think so.
ehu: do you?
haso: It could be an informed option.
ehu: well, that's indeed an idea.
ehu: it's in the install file for debian and RH, I think.

When trying to use XeLaTeX, you may get a message like:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! You are attempting to make a LaTeX format from a source file
! That is more than five years old.
!
! If you enter to scroll past this message then the format
! will be built, but please consider obtaining newer source files
! before continuing to build LaTeX.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

! LaTeX source files more than 5 years old!.
l.545 ...aTeX source files more than 5 years old!}

?
! Emergency stop.
l.545 ...aTeX source files more than 5 years old!}

No pages of output.
Transcript written on xelatex.log.
Error: `xetex -ini -jobname=xelatex -progname=xelatex -etex xelatex.ini' failed

###############################################################################
fmtutil: Error! Not all formats have been built successfully.
Visit the log files in directory
/var/lib/texmf/web2c
for details.
###############################################################################

This is a summary of all `failed' messages and warnings:
`xetex -ini -jobname=xelatex -progname=xelatex -etex xelatex.ini' failed

This is confirmed to be a problem on CentOS 6, Scientific Linux 6, Red Hat Enterprise Linux 6, and Fedora Core 13.

You can correct this issue (as root) by:

cd /usr/var/texmf/web2c
xetex -ini -jobname=xelatex -progname=xelatex -etex xelatex.ini

Once you type this you will get the same message, but have the option to press return and generate the file anyway.

(admin.pl is replaced with setup.pl in LedgerSMB v. 1.3.x and upwards)

I am trying to install ledgerSMB on SuSE 11.1 and have followed the INSTALL and README documents to do so, and have also installed all dependencies.

When I get to the following instruction I get some errors.

$ ./Build test

The errors are seen in the last few lines of output following the instruction. I list them below. Note that prior to these last few lines are many lines starting with "BEGIN failed--compilation aborted ..."

Also note the last line "Failed 6/6 test programs. 58/76 subtests failed." Clearly something is wrong here.

================================================
BEGIN failed--compilation aborted at LedgerSMB/Sysconfig.pm line 8.
Compilation failed in require at LedgerSMB/Form.pm line 37.
BEGIN failed--compilation aborted at LedgerSMB/Form.pm line 37.
Compilation failed in require at t/99-versioning.t line 8.
BEGIN failed--compilation aborted at t/99-versioning.t line 8.
# Looks like your test died before it could output anything.
t/99-versioning.........dubious
Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 1-9
Failed 9/9 tests, 0.00% okay
Failed Test Stat Wstat Total Fail List of Failed
-------------------------------------------------------------------------------
t/01-load.t 12 3072 30 12 1-3 5 11-12 14 16 20 26-27 29
t/02-number-handling.t 255 65280 ?? ?? ??
t/03-date-handling.t 255 65280 ?? ?? ??
t/10-form.t 255 65280 ?? ?? ??
t/12-menu.t 255 65280 37 74 1-37
t/99-versioning.t 255 65280 9 18 1-9
Failed 6/6 test scripts. 58/76 subtests failed.
Files=6, Tests=76, 1 wallclock secs ( 0.93 cusr + 0.12 csys = 1.05 CPU)
Failed 6/6 test programs. 58/76 subtests failed.
================================================

After restarting both postgresql and apache, I tried to go to http://localhost/ledgersmb/admin.pl and received the following error on Firefox:

================================================
Server error!

The server encountered an internal error and was unable to complete your request.

Error message:
Premature end of script headers: admin.pl

If you think this is a server error, please contact the webmaster.
Error 500
localhost
Mon Nov 2 08:59:41 2009
Apache/2.2.10 (Linux/SUSE)
================================================

=======================================================
PROBLEM SOLVED ==> See below for the solution to this installation problem.
=======================================================

The problem was solved with the help of irc.freenode #ledgersmb. Here is how:

The error message says, "BEGIN failed--compilation aborted at LedgerSMB/Sysconfig.pm line 8." Line 8 in LedgerSMB/Sysconfig.pm is "use Config::Std;" This suggests that there was something wrong with Config::Std. Either it was not installed or there was some problems with its installation.

So, I tried reinstalling Config::Std and I received error messages suggesting problems with dependencies that were not reported when I ran "perl Build.PL"

http://search.cpan.org/ allows you to look up modules, such as Config::Std. Once found, there is a "dependencies" link, which lists dependencies, each of which have further dependencies, which have dependencies... . Well, you get the idea. Be patient and follow through noting all the dependency modules and dependent on dependent modules. Download and install each of these. I started installing those with least dependencies themselves.

I then reran "perl Build.PL" and "./Build test" and then restarted Apache and PostgreSQL. Voila! When I went to http://localhost/ledgersmb/admin.pl, I received the login page with no error!!

Written by: Joe

Q: How could I set it up ledgersmb to support SSL connection?

SSL support on Apache is handled by configuring Apache. For having LedgerSMB connect to PostgreSQL using SSL, you can set the PGSSLMODE environment variable to 'require' in the ledgersmb.conf. Note that by default, LedgerSMB will try to connect to PostgreSQL via SSL and fall back to unsecured connections if this is not available.

We highly recommend using SSL for any access to LedgerSMB over the network.

Make sure you have TexLive installed. Older TeTeX was recommended but according to Ubuntu repositories, TexLive is the new package to install.

You can install this with the following command:

apt-get install texlive-latex-extra

 

Adding support for other database management systems would require that the database logic be coded to the least common denominator. We have decided that we want to eventually allow add-ons in different languages, and thus the database becomes the only point where we can enforce accounting logic consistantly across all parts of the application. Porting and maintaining such logic across database systems is not feasible for this project.

Additionally PostgreSQL is an outstanding RDBMS and we have no desire to move from it.

The table below lists the compatibility of LedgerSMB versions with PostgreSQL versions. Products for which support has ceased due to End-of-Life date being reached are not listed and should not be used.

PostgreSQL compatibility
PostgreSQL1.4.x1.5 planned1.6 planned
8.4nonono
9.0yesnono
9.1yesnono
9.2yesnono
9.3yesnono
9.4 yesyesyes
9.5yesyesyes

Versions 1.0, 1.1, 1.2 and 1.3 are not in this table due to the fact that they're past End of Life.