Re: Initial steps for 1.6, and some longer-term questions

Hi,

On 11/04/2015 08:08 PM, Chris Travers wrote:

Hi John;

Well, the sorts of things that go into the Setup.pl are really not going away any time soon (or ever) and the tooling there is less than ideal. I have a partial replacement there.

2. We could bundle all our tools together. In this case you still run the same program which checks your system, sees whether it can run a web server and if not gives information as to why not. Such a program would then typically not update a system but could change file permissions after running and setting things up.

In both cases, the installer checks external prerequisites, CPAN dependencies, and can either solve or advise on how to solve missing dependencies. I would like LedgerSMB 1.6 to be easier to install than SQL-Ledger 2.6 was. Mostly this is hand-holding, providing clear feedback on how to resolve problems, and a nice interface for showing the information.

I would argue that we should skip all the dependency-checking, etc, and point people either to packages for Debian/RHEL/etc, or the Docker images.

For RHEL users, there are currently a lot of extra dependencies to track down that are not in the standard repos, and if you are installing on a Linux server, you really need to know how to set up PostgreSQL etc. So having a nice installer would help out a lot. If we want to go this route, we really need our own yum/dnf repo. I suppose we could host one at Efficito.

I would prefer to keep you and Erik focused on the core platform, and not package management ;-) seems like an opportunity for others to step up and contribute, if they really want to go the package route...

Docker solves a lot of the Postgres setup -- the "official" postgres container required no configuration to use straight out of the gate. Because it's in a container, you have to interact with it via TCP (well, if you mount a socket you don't technically "have" to but that's an extra step) so Postgres is TCP-enabled in the default container. You set the Postgres password when you create the container, and you can log into the LSMB setup.pl script with it immediately with no other configuration.

It also greatly eases the ability to run different versions of Postgres than may happen to get shipped with your installed OS. So perhaps it becomes our answer to cutting off support for older Postgres versions -- "run a newer Postgres in Docker".

Where we do need to spend time hand-holding is once the system is up and running -- setting up the Chart of Accounts, providing guidance on user permissions, how to set up bulk imports, etc. Nice interfaces for showing best accounting practices, templating guidance, etc.

Agreed on this. This also means db creation and management, etc. In other words ,the area that App::LedgerSMB::Admin (and ::Web) have focused on regarding a next generation cli and web interface. These are the external tools I would like to integrate. It does mean an additional couple dependencies which means getting dependency tracking is a little more important.

Sure! I think this starts with a list of what is required.

The Dockerfile is a very nice way of documenting that -- it's essentially an install script. The Perl:5 image uses Debian Jessie as a base, and you can see what I've got installing here:

1.4 - https://github.com/ledgersmb/ledgersmb-docker/blob/1.4/Dockerfile
1.5 - https://github.com/ledgersmb/ledgersmb-docker/blob/master/Dockerfile

... I think we'll need some coordination here between package maintainers for whichever distributions we package for, Docker, and making sure the list is reflected on the website for those who may want to install everything from source.

> I also want to make sure we have both command line and web tools. Command line tools give experienced administrators a productivity edge here (because it is easier to quickly send complex information to the program), but web tools give new users an ability to get up and running with less immediate knowledge.

By "command line" tools, do you mean something more than what's already there -- the ability to run any of the .pl scripts directly and pass in info using a Bash script, for example?

The immediate ones that come to my mind are:

1) Create a database with a specific coa, etc.

2) Add a user to a database

3) Update a database within a stable branch

4) Upgrade a database from one stable branch to another.

These would help out quite a bit where multiple dbs are managed in the same organization. Docker or no, having a good scriptble admin interface makes things a lot easier.

Now, for 1 and 3, I already have this fairly well working. For 2 and 4, there are some complications.

But they come in really handy in a number of cases, not only hosting itself but holding companies, subsidiaries, etc. where you have an IT team which can use tools like this to automate the update process. It also helps where the web server does not have superuser access to the db for security reasons.

And I have run into enough cases where this was necessary to know that updating and creating dbs from the command line is very helpful.

Agreed...

Thinking about what I do with drush (the Drupal shell tool), here are some other really useful ones:

* Password reset links (or ability to reset passwords)
* Download/Enable/disable plugins

I'm not sure command line/shell tools are the real need -- I think the critical thing is to get an API in place, bit by bit. We can certainly wrap those with a shell tool, but I think the real need is for a solid API.

I totally agree about the need for a solid API.

For the admin tools, the approach I took was:

1) An admin library

2) CLI tools that use it

3) A dancer-based web interface.

My proposal is that we extend these tools nd replace our existing management tools with them.

Sounds fine with me, though I think we'll need to keep some sort of web-based admin tool for those not comfortable in the shell -- but with a good API this could be pretty minimal (as it currently is).

Was going to write more about why we should focus on the API, but...

I'm seeing the API as functional scaffolding to help with the financial rewrite, as well as being an end in itself...

Agreed entirely.

Enough said!

Cheers,
John Locke
http://www.freelock.com