Re: [Koha-devel] Koha installation procedure

[MJ Ray]

Jared Camins-Esakov <address@hidden> wrote:
> I am interested in reimplementing the Koha installation procedure to
> meet the following requirements:

I do not see why you want to reimplement. I would prefer to upgrade.
Some of the things the installer needs to do are fiddly, as we've
discovered wrinkles in the past.

> * File installation and configuration should be separate from each other
> (necessary for creating a port compliant with the FreeBSD ports system's
> unspoken best practices, and probably other packaging systems' best
> practices as well)

If it's undocumented, how will we know if we do it "right"?

> * Configuration should be possible at any time after installation (so on
> systems where the sysadmin is not also the Koha admin, the sysadmin
> doesn't have to wait for the Koha admin)

Can you elaborate on this, please?

> * It should be possible to specify ALL options to the installation and
> configuration scripts using command line switches or environment
> variables, or something else that doesn't require user intervention (so
> that the setup process for the entire system could be scripted [I've
> done this, so I imagine other people do it too]; the auto-configuration
> file doesn't really lend itself to scripting, in my opinion)

I'm still looking at the auto_install part. Why do you think it
"doesn't really lend itself to scripting"?

Specifying all options in the environment/command-line would be
a bad idea for security, as there are passwords which you don't
want visible on the output of ps.

> * It should be possible to install Koha without having GRANT privileges
> on the MySQL server (or root access to the server), if an account has
> already been created for Koha's use

This would be a good addition, but koha should use an opac
account different from the librarian one. I know you can
circumvent that if there's only one account, but it must
be supported.

> My plan is to start by separating the installation and configuration
> into two separate scripts, both using the Install.pm module. I am not
> sure how to implement the second issue. Perhaps have the installation
> set up the intranet module temporarily, and then use a one-time
> web-based configurator a la Refbase (refbase.sourceforge.net)?

Install.pm really should try to use only core perl modules
at first, IMO.  I think past maintainers probably agreed, as
things are fed to mysql tools rather than using DBI. It may
be worth reconsidering the approach to this, as command line
behaviour differs between platforms.

> My first
> thought was to install the Install.pm module in site_perl and the
> configuration script in $PREFIX/sbin (for example), but I guess
> installing anything outside of Apache's area should be avoided?

Why?

[...]
> Any thoughts on this? Anything I've suggested that is a Really Bad Idea?
> Anything that should be done differently than I suggested? Anything that
> you'd like to see implemented in the installer? If no one has any
> problems with my suggestions, and the current maintainer of the
> installer is willing to consider my patches, I'll start work on this.

I'd really like single-feature patches (diff -u), but it sounds
like you are heading off down a "rewrite everything" road. In
that situation, I'll probably not consider large patches and
just wait until you have a working alternative.

Putting passwords on the command line seems a Really Bad Idea, but
that's the only one which stands out and it shouldn't detract from
the general aim of automating everything.

Hope this helps,
-- 
MJ Ray (slef), K. Lynn, England, email see http://mjr.towers.org.uk/
http://www.ttllp.co.uk/koha/