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
------------------------------------------------------------------------------
_______________________________________________
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel