[Koha-devel] RFC - installer changes

[Galen Charlton]

Hi,

On 12/14/07, MJ Ray <mjr at phonecoop.coop> wrote:
> "Galen Charlton" <galen.charlton at liblime.com> wrote:
> > On 12/13/07, MJ Ray <mjr at phonecoop.coop> wrote:
> It doesn't at the moment, but accidents will happen.  _get_value()
> doesn't detect when it is being run non-interactively and may keep
> asking prompt() and getting the same invalid default value again and
> again.  Can we add the supplied default value to the valid values,
> just to be sure?

Yep.

> > According to my reading of Apache suexec guide, u+w is not a problem
> > (g+w or o+w are, but the installer does not install any files with
> > those modes).  That said, I have not done any testing using suexec
> > mode, and would appreciate information from anybody who has.
>
> I'm thinking more of the opac rewriting koha's files if any weakness
> is found... I need to think more about this and hammer on it, unless
> anyone else has tested it.

The user owning Koha's files should not be the same as the Apache user
(e.g., www-data on a default Debian install), and I can add suitably
loud language to that effect in the installer's prompts.

That leaves two (AFAIK) places where Koha's CGI scripts currently want
to write non-temporary files:

[1] edithelp.pl
[2] member picture upload

I'm inclined to have the installation instructions tell the installer
to set up ACLs to allow write access to the affected directories
rather than recommend use of suexec.  Alternatively, or in addition, a
setuid daemon could be written to control access to the upload
directories, or (in the case of the patron images) they could be
stored as BLOBs in a separate mysql database.

> What case should we be optimising for?  The user who downloads a first
> koha and installs it to try it out?  Or the library consortia?

We can do both -- see below.

> > Therefore, I'm not in favor of putting C4 in Perl's built-in @INC by
> > default [...]
>
> So how does that comply with the Debian Perl policy, for example?
> http://www.fr.debian.org/doc/packaging-manuals/perl-policy/ch-perl.html#s-paths

That policy seems to be geared to "library" Perl modules, i.e., those
intended to be shared by more than one application.  That document
would be more clear if it addressed the distinction between a shared
Perl module versus one created simply to organize an app's code.  C4
falls in the later category; there is no practical reason to install
the C4 modules absent installation of the rest of Koha.

There are several Debian packages for Perl web applications that
follow what I'm suggesting and put the application-specific modules
under /usr/share/<package>/lib, including request-tracker3.6 (i.e.,
RT) and cgiirc.  While not all Perl web-apps do this, there is enough
of a precedent.

> Anyway, I think a bigger problem is requiring new users to make more
> config steps.  Can we optimise this for new first installs?

My tree now has a mechanism to paste in the installed Perl module path
for use by the command-line scripts.  They now all refer to kohalib.pl
to adjust @INC, and kohalib.pl in turn is set by rewrite-config.PL.
In the case of a 'dev' mode install, where kohalib.pl is not munged,
as usual developers will have to plan on setting PERL5LIB and
KOHA_CONF.

The upshot is that now, after doing an installation, no environment
variables need to be set to use the command-line tools.

> I don't recall why kohaversion.pl was added in August when
> $C4::Context::VERSION was already there.  Are we stuck with it?
> Can we replace it with use C4::Context; return $C4::Context::VERSION?

I don't know the history, but I do like having some kind of
separation, mostly for the trivial reason that the log for
C4/Context.pm wouldn't get cluttered with commits that are not really
related to Context.pm itself.

> If we're stuck with it, can we use kohaversion.pl with a versionnumber?
> Does it mean we have to add "use kohaversion.pl ..." calls to every
> script, rather than appending the version number to use C4::Context?

No, we can still apply the version check to C4::Context by overriding
the VERSION method -- we would need to do this anyway, as the VERSION
imported from UNIVERSAL.pm croaks only if the requested version is
larger than the module's $VERSION.  Since I'm not aware that the C4
API is presently being designed or maintained for backwards
compatibility, such a version check would have to require an exact
match to be completely safe.

Regards,

Galen
-- 
Galen Charlton
Koha Application Developer
LibLime
galen.charlton at liblime.com
p: 1-888-564-2457 x709