Re: [Koha-devel] Koha installation procedure

[Jared Camins-Esakov]

MJ --

> 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.

Apologies. I should have been more clear. I do not want to rewrite the
entire installer procedure. I want to use the existing code and modify
it. The code that actually does the installation seems to work well
enough. I'm not sure why I used the word "reimplement." I suspect
because it was a little bit after midnight and I was exhausted... I'll
let that be a lesson to me, and in the future try to remember to wait to
send messages to the list until the morning.

> > * 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"?

In this case, because a major part of the test procedure for a port is
to build, install, uninstall, and reinstall the port on an unattended
server farm. Any user intervention will prevent it from doing so.

> > * 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?

Certainly. I don't know how common this is, but I worked at a company
where one of my coworkers was the sysadmin, and I did the web server
configuration separately, after he had finished intalling the software.
I'm thinking about a situation like that, where the sysadmin may only
install Koha and expect someone else to configure Koha. The
configuration option that made me think of that was the installation of
the MARC tables. A sysadmin wouldn't necessarily know what MARC is.

> > * 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"?

It would make any "meta-installer" depend on an additional file, and,
more importantly, there are no accessor functions for it, besides
writing something that will parse it, so reading in the file to display
your options from the meta-installer, for example, would be difficult.
Right? Did I miss something here?

> 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.

Oh dear. I hadn't thought of that. Any suggestions besides an
auto_install file? Or suggestions about how to deal with the above
objections about auto_install files? Or, even better, an explanation of
how my objections were based on incorrect information?

> > * 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.

What about giving the option of specifying two accounts, one for the
OPAC and one for the Librarian?

> > 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.

It's something to think about. That would be the last change I would
implement, actually, I think, being the largest.

> > 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?

Because fundamentally Koha is a web application that runs in Apache, and
not a system package. If you don't think this is a problem, though, I'd
certainly not argue with you.

> > 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.

The separation of installation and configuration lends itself to a small
patch... as does configuring the installer to accept pre-assigned MySQL
accounts. Shall I start with those two, then we can consider the other
two, and I'll try to think of ways to deal with the passwords and the
post-installation configuration of Koha?

Thanks.
-- Jared Camins-Esakov
-- 
Jared Camins-Esakov
E-mail: address@hidden