Installation

Session expired immediately after logging in

Submitted by ehu on

When I log in, LedgerSMB 1.8 or higher immediately says my session has expired. What can I do to fix this?

Short answer: add the "--preload-app" flag to the Starman command line.

Long answer: As of LedgerSMB 1.8, session information is stored in an encrypted cookie. To make sure the encryption key is unique for every installation, a new encryption secret is being generated each time LedgerSMB is started. However, Starman (without the "--preload-app" flag) loads the application in each forked worker separately, leading to different encryption secrets in each worker with the indicated behaviour as a result.

Upgrading LedgerSMB 1.8.x to 1.8.y

Submitted by ehu on

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

  1. Upgrade the software
  2. Upgrade the company database

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

Upgrade the software

The steps to upgrade the software differ between Docker or tarball (from source) installations.

Upgrading Docker installations

In case the installation was created using the docker-compose infrastructure provided by the project, the upgrade should be as simple as running

I want to switch to LedgerSMB, but I have unpaid invoices. What to do?

Submitted by ehu on

The general approach is to migrate invoices first, creating them as they exist in the current accounting solution. Then, differences with the intended balance can be calculated and the remainder posted at-once. For more comprehensive explanation see How do I migrate my existing books to LedgerSMB?

Why does the acc_trans table have fewer lines after upgrading to 1.7?

Submitted by ehu on

Short answer: Due to differences in the database schema in relation to storing foreign currency transactions.

Long answer: The database schema before 1.7 required 2 database rows in the acc_trans table to store functional currency and foreign currency amounts. As of 1.7, the schema stores these two amounts - which relate to the same journal line - into one database row. When migrating data from the old schema to the new one, the migration routine tries hard to identify pairs of rows which can be combined into a single row in the new schema.

Upgrading LedgerSMB 1.5.x to 1.5.y

Submitted by ehu on

Upgrading tarball installations

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:

Upgrading to LedgerSMB 1.5

Submitted by ehu on

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!

Controlling Starman

Submitted by Anonymous (not verified) on

Useful Starman commands.
Using the perl based Starman webserver is the easiest way to run LedgerSMB locally (and quite possibly for production use as well).

## 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.

I want to upgrade PostgreSQL from 8.3 to 8.4+. How does that work?

Submitted by ehu on

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.

Subscribe to Installation