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