Re: State of Perl-based database setup utilities for LedgerSMB 1.3

[Chris Travers <..hidden..>]

On Sat, May 28, 2011 at 9:08 AM, Adam Thompson <..hidden..> wrote:
>> Where would the data be stored?  Do we require write permissions to
>> the ledgersmb directory?
>
> Um, in the case I was describing, yes, I think so.  In the examples I've
> seen, the administrator has the choice of either configuring their
> webserver & system to allow the PHP script to write to the config file,
> *or* updating the config file manually.  Which is what LSMB requires,
> currently.
>

I think it's a lot safer not to trust the application with these
things.  If we were to go about that, I would suggest an addon, turned
off by default, that would change permissions appropriately and
provide an interface for making the changes.  But more to the point,
that doesn't set up a database for accounting data.  I don't see an
easy way to detect that prior to login since we have no access to the
database server absent credentials supplied by the user.

Now, this doesn't preclude a package manager from creating a database
as part of the package installation process using the tools we
provide.

It's worth considering for a moment how little trust the application
actually receives from a security perspective.  Unlike most open
source applications, we made the decision to make application users
into database roles.  One advantage here is that the application has
no more access to data than the user who is currently logged in.  This
reduces our security exposure a great deal by re-using a well-tested,
mature authentication system in the background.  It also means that
long-term a user could be granted the ability to connect to the same
database using other tools and have the same rights applied across the
board.

In other words, LedgerSMB doesn't authenticate users in 1.3, nor is it
the final check against exceeding permissions.  These are both handled
by PostgreSQL.

So to create a database we have to obtain user permissions sufficient
to create the database.

>> I suppose we could create a single world-writable file and maybe delete
>> it or something after the database setup.
>
> >From my perspective, even if we force the admin to edit a config file by
> hand, at least the "installation instructions" are now embedded in a
> sanity check expressed as code - and as we all know, (generally)
> programmers like to code yet hate writing documentation.
> So, we
> 1) package LSMB as a self-contained RPM/DEB/whatever *without* needing a
> (relatively speaking) very complex post-install script

Yes, that should be possible.

> 2) now allow the install script to be written in perl, since it's part of
> the LSMB code

Install scripts will be in Perl.  Currently they are and depend on
make utilities (via Module::Install)

However there is no reason we can't create a script which calls prove
on relevant test scripts to create, load, and test a database, then
declaring it ready for production use.  This would get rid of the
requirement for make, but it would still require Test::More.

> 3) avoid keeping a separate piece of documentation up-to-date w.r.t.
> dependencies, DB setup, etc.  (It still has to be kept up to date, but in
> a different way.)

Have you taken a look at the Makefile.PL and the db test scripts
mentioned in README.test?

Best Wishes,
Chris Travers