On Sun, Jun 3, 2012 at 6:44 AM, Brian Wolf
<..hidden..> wrote:
We've just taken on a few clients who each have requirements that
LedgerSMB can satisfy. At least one client needs enhancements or
modifications to workflow / screens; some changes are specific to
the client and others apply more broadly to other clients.
I'm new to LedgerSMB and by no means have expertise in PostgreSQL
administration. I imagine that multiple clients can be hosted on
one server, but I don't have a clear picture how that would be set
up. Can someone provide a step-by-step outline?
As I understand it from talking to you, you are looking at hosting LedgerSMB for multiple businesses. There are a few gotchas to get into here and so my recommendation generally is that unless there is a common accounting team between two businesses, these should be deployed with both multiple instances of LedgerSMB and multiple instances of PostgreSQL. These can of course share servers however the load allows you to do (but I would recommend eventually a decent physical server for PostgreSQL with good I/O bandwidth if you get enough users to make that worthwhile).
One key design consideration you will have to think about is that we use PostgreSQL roles for user accounts and these are global to a PostgreSQL instance. So if there is a common accounting team behind two companies, you can just use two db's and share user accounts. On the other hand, if there are multiple companies this becomes difficult.
I am assuming you want to let your customers create user accounts etc. If you don't and if you want to manage permissions for the user, then you will have some light customization to do. That's beyond the scope of this recommendation.
Spinning up additional PostgreSQL instances is pretty cheap processor-wise. These don't take a lot of memory for the process that just listens on the socket, and your memory issues are primary those about usage. In general you should have enough memory on your PostgreSQL server that all user data across all companies fits comfortably in memory, though.
The first thing to look at doing is creating a new PostgreSQL instance. To do this, basically you (using Red Hat paths here):
sudo -u postgres initdb -D /var/lib/pgsql/data-acme
Where acme is the customer's name.
Then edit the /var/lib/pgsql/data-acme/postgresql.conf to listen on a different port (let's say 5433 for the second customer, and increasing one each time). And you probably want to copy the pg_hba.conf from a stock version (adding the IP of your web server and allowing it to authenticate via md5). You may want to open up additional addresses for the customer at their request, and you can do this if you like.
Then you have to edit the startup scripts. This is becoming more distro-dependent. But you need to make sure PostgreSQL is also started against the new data directory. If it is CentOS 5.x or similar, the /etc/init.d/postgresql is the file to edit. If that file is not listed, see if there is a /usr/lib/systemd/system/postgresql.service and if so read the comments and create a new file as per the specifications there.
That's all that is required for PostgreSQL.
On the LedgerSMB side, just copy the LedgerSMB directory to a new one (maybe lsmb-demo to lsmb-acme) and alter the ledgersmb.conf to point at the new port number. Then you need to re-generate a new configuration for this service. You could do this by running sed on the existing configuration file (in /etc/httpd/conf.d on Red Hat-like systems) to change one directory to another, and outputting that to a new file. Then service httpd restart will restart Apache with the new directory active.
Hope this helps.
Chris Travers