[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Instructions

I'm trying to host multiple unrelated companies on a server.  These instructions were provided:

The safest way:
Deploy multiple instances
LedgerSMB setup
- Copy the LedgerSMB directory to a new one (eg, lsmb-demo to lsmb-acme).
- Edit ledgersmb.conf to point to the new port number.
- Re-generate a new configuration for this service by running sed on the existing
  configuration file (in /etc/httpd/conf.d on Red Hat-like systems)
  to change one directory to another
- Restart Apache.

Let's say the new company is called acme.  I'm going to the following URL to set up the new database:
I've entered the postgres user's password correctly, but LedgerSMB still challenges for a user ID/password.  Any suggestions on how to fix this so I can set up a new database?


Brian Wolf
Phone: 410.367.2958
Email: ..hidden..
Try out Activus Secure Payments™, our recurring payments application.
On 09/07/2012 07:12 PM, Håvard Sørli wrote:
On 06. sep. 2012 15:06, Brian Wolf wrote:
To host a second company (which is completely separate from the first),
my understanding is that we need to run a separate instance of LedgerSMB
and create a separate PostgreSQL database.  Can someone provide clear
instructions on how to set up the second company? Please be as specific
as possible.
The simple way:
Use your current instance
Use setup.pl to create company database number 2,3,4 with ledgersmbadm 
user (or a special admin user for each db).

You have to use different usernames on all users.

The safest way:
Deploy multiple instances

<metatrontech> on irc:
Basically roles are globally shared and so a user created on db A is 
available on db B for grants if they are on the same cluster.  Normally 
we control for this in the following manner if the user exists we throw 
an error and give the admin a chance to import the user.

This means that if the companies are on different Pg clusters the users 
cannot be shared and you can prove this, but if they are on the same pg 
cluster, you can manage it, but you can't prove that users of company A 
cannot access the books of company b.