Hi, I have made a number of changes to the installer and now have a version ready for general review. My git branch and the results can be accessed as follows: git repo: http://manage-gmc.dev.kohalibrary.com/koha-installer.git gitweb: http://manage-gmc.dev.kohalibrary.com/cgi-bin/gitweb.cgi?p=koha-installer.gi... Tarball with the revised installer: http://manage-gmc.dev.kohalibrary.com/koha-3.00.00.032.tar.gz Changes include: * Prompting for more configuration information during perl Makefile.PL * Introduction of three installation modes: ** 'standard': typical install as root ** 'single': install everything under one subdirectory; meant for users who do not have root on their host but are allowed to install software. ** 'dev': run as much as possible from a git checkout * Improved conformance with FHS and Debian web application guidelines, particular in 'standard' mode. * Improved support for specifying where each logical installation target should go. * Replaced glob with a directory walk to identify files to be installed (thanks fbcit!). * Separation of Zebra configuration and data files in 'standard' mode. * Adjustment of Zebra configuration file layout. All Zebra config files in the Koha package are now installed and are available for use; the installer now simply sets profilePath to control which MARC and language options are in effect. * During 'standard' install, ownership of Koha's files can now be assigned to a non-root user (which should be different from the httpd user, of course). This allows most Koha server-side administration and web design tasks to be done without requiring root access. * Files are now installed with u+w. * By default the C4 Perl modules are bundled with the rest of Koha's files. * 'make test' now enabled * 'make' now just stages files in blib; nothing is actually installed until you do 'make install' * general bugfixes I should emphasize that by default the C4 modules are installed along with the rest of the Koha files, e.g. in /usr/share/koha/lib. They are not installed in any of the standard Perl module directories, although a packager could choose to put them there by setting PERL_MODULE_DIR when running perl Makefile.PL. As a consequence, this means that by default use of the PERL5LIB environment variable is necessary; 'make install' now prints a message suggesting the the user set KOHA_CONF and PERL5LIB in their profile. The default koha-httpd.conf now includes both of these variables. My main reason for doing this by default is that the C4 modules have at present no independent use outside of supporting Koha's CGI scripts and are intimately tied to the version of those scripts. Putting them in the default @INC will risk problems for users who need to run multiple versions of Koha on a box. Requiring use of PERL5LIB is not perfect, but it should be noted that we already have one required environment variable in the form of KOHA_CONF. If it is thought that this would cause too many problems, I would consider use of FindBin and use lib along with using rewrite-config.PL to set the correct module path in the command-line scripts. Related to this, I think it will be useful to consider specifying the version number when doing 'use C4::*' from the scripts, and possibly consider use of the 'only' pragma [1]. I would like to request that interested developers and users test the installer and provide feedback, debate, flames, etc. to koha-devel. My testing was done solely on Debian Etch, by the way. Also, please note that my repository was cloned from HEAD almost two weeks ago and I have not yet merged in current work, so please bear that in mind. Thanks to Henri-Damien Laurent, Chris Nighswonger, and Chris Cormack for contributing patches so far, and thanks to MJ Ray for creating the current installer on which my work was based. Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709 [1]: http://www.perl.com/pub/a/2003/03/18/only.html
"Galen Charlton" <galen.charlton@liblime.com> wrote:
git repo: http://manage-gmc.dev.kohalibrary.com/koha-installer.git
The branch is called "installer" just in case I'm not the only one struggling to figure that out. After making a dummy branch for it, git pull http://manage-gmc.dev.kohalibrary.com/koha-installer.git installer seems to work. How do others manage it? It conflicts with git.koha.org on the following dependencies:- <<<<<<< HEAD:Makefile.PL 'MARC::Charset' => 0.98, 'MARC::Crosswalk::DublinCore' => 0.03, 'MARC::File::XML' => 0.88, 'MARC::Record' => 2.00, 'MARC::Crosswalk::DublinCore' => 0.02, ======= 'MARC::Charset' => 0.95, 'MARC::File::XML' => 0.86, 'MARC::Record' => 1.38,
> 9e7a7e986b1af05ba36b2a980cdbbd5cc465f4a7:Makefile.PL
Which versions do we need? Actually, koha.org is a bit buggy on one of those, repeating MARC::Crosswalk::DublinCore, but the other version differences are odd. I'd've gone with 'MARC::Charset' => 0.98, 'MARC::Crosswalk::DublinCore' => 0.03, 'MARC::File::XML' => 0.88, 'MARC::Record' => 2.00, but I think I'd have just messed up the branch by doing so. There also seem to be missing deps on XML::LibXSLT and Net::Z3950::ZOOM. I see now it's because of this from later in the email:
[...] Also, please note that my repository was cloned from HEAD almost two weeks ago and I have not yet merged in current work, so please bear that in mind.
Merging is usually a download-time+5-minutes task with git, so that's a poor excuse to be giving people old development versions, as long as you don't think HEAD's QA is letting in new breakages! Although now you've not been merging HEAD, you've got the conflict above to resolve... So I should have branched HEAD from some unspecified past date. [...rewind...]
* Prompting for more configuration information during perl Makefile.PL
Has this been done in a way that makes this step difficult to automate/package? It looks very similar to repeating some mistakes of the 2.2 installer. I think any questions should be asked by a very simple front-end script that sets variables and then calls a silent Makefile.PL. That would also probably make it easier for GUI installer makers to see what they needed to do. I'm hesitant to merge this into the other installer branches until I see how to automate it. Can _get_value() get stuck in an infinite loop if the supplied $default isn't in $valid_values and STDIN is empty (so prompt returns $default every time)? OK, it should never happen, but I'd bet it will...
* Replaced glob with a directory walk to identify files to be installed (thanks fbcit!). * Separation of Zebra configuration and data files in 'standard' mode. * Adjustment of Zebra configuration file layout. All Zebra config files in the Koha package are now installed and are available for use; the installer now simply sets profilePath to control which MARC and language options are in effect.
Yes, those are big improvements. Thanks to you, fbcit and any others who helped to develop them!
* During 'standard' install, ownership of Koha's files can now be assigned to a non-root user (which should be different from the httpd user, of course). This allows most Koha server-side administration and web design tasks to be done without requiring root access. * Files are now installed with u+w.
Is this problematic for suexec users? (I don't know and haven't tested it yet.) [...]
* 'make test' now enabled
Great! [...]
As a consequence, this means that by default use of the PERL5LIB environment variable is necessary; 'make install' now prints a message suggesting the the user set KOHA_CONF and PERL5LIB in their profile. The default koha-httpd.conf now includes both of these variables.
My main reason for doing this by default is that the C4 modules have at present no independent use outside of supporting Koha's CGI scripts and are intimately tied to the version of those scripts. Putting them in the default @INC will risk problems for users who need to run multiple versions of Koha on a box.
Requiring use of PERL5LIB is not perfect, but it should be noted that we already have one required environment variable in the form of KOHA_CONF.
Only if the config file isn't in the default location in C4::Context, surely? To be clear, I think this is a step backwards. My goal is for someone running one koha on their own server to be able to install it with the defaults and it to work immediately. I don't think running multiple versions of Koha on a box is a common requirement except when upgrading and I think people would be happy to mess with PERL5LIB in that situation. [...]
Related to this, I think it will be useful to consider specifying the version number when doing 'use C4::*' from the scripts, and possibly consider use of the 'only' pragma [1].
Yes, I think that would be a very good idea and one way to guard against accidents if the API changes. Hope that helps, -- MJ Ray http://mjr.towers.org.uk/email.html tel:+44-844-4437-237 - Webmaster-developer, statistician, sysadmin, online shop builder, consumer and workers co-operative member http://www.ttllp.co.uk/ - Writing on koha, debian, sat TV, Kewstoke http://mjr.towers.org.uk/
HI, Partial response -- more later: On 12/13/07, MJ Ray <mjr@phonecoop.coop> wrote:
"Galen Charlton" <galen.charlton@liblime.com> wrote:
git repo: http://manage-gmc.dev.kohalibrary.com/koha-installer.git
The branch is called "installer" just in case I'm not the only one struggling to figure that out. After making a dummy branch for it, git pull http://manage-gmc.dev.kohalibrary.com/koha-installer.git installer seems to work. How do others manage it?
The master branch on the published repo has the changes. For testing the installer on other boxes, I've always just cloned, but making a new branch in your local repo and doing git pull http://manage-gmc.dev.kohalibrary.com/koha-installer.git master seems to work for me as well.
It conflicts with git.koha.org on the following dependencies:- [snip] I'd've gone with 'MARC::Charset' => 0.98, 'MARC::Crosswalk::DublinCore' => 0.03, 'MARC::File::XML' => 0.88, 'MARC::Record' => 2.00, but I think I'd have just messed up the branch by doing so.
My version now reflects those choices. There are some other dependencies (e.g., POE), that still need to be added; I will do so my branch in and submit patches for git.koha.org.
There also seem to be missing deps on XML::LibXSLT and Net::Z3950::ZOOM.
They we already there AFAICT, but in any event I confirm they're present now.
I see now it's because of this from later in the email:
[...] Also, please note that my repository was cloned from HEAD almost two weeks ago and I have not yet merged in current work, so please bear that in mind.
Merging is usually a download-time+5-minutes task with git, so that's a poor excuse to be giving people old development versions, as long as you don't think HEAD's QA is letting in new breakages! Although now you've not been merging HEAD, you've got the conflict above to resolve...
OK, I was paranoid about git dealing with the moves and changes to the Zebra configuration files, but I've worked through that (thanks MJ) and synced with HEAD. My public git repo is now up-to-date; I will release a new tarball later today after I make some more changes. Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709
Hi, On 12/13/07, MJ Ray <mjr@phonecoop.coop> wrote:
"Galen Charlton" <galen.charlton@liblime.com> wrote:
* Prompting for more configuration information during perl Makefile.PL
Has this been done in a way that makes this step difficult to automate/package? It looks very similar to repeating some mistakes of the 2.2 installer. I think any questions should be asked by a very simple front-end script that sets variables and then calls a silent Makefile.PL. That would also probably make it easier for GUI installer makers to see what they needed to do.
All parameters can now be set by using environment variables and running perl Makefie.PL either detached from STDIN or by setting PERL_MM_USE_DEFAULT -- see more below.
Can _get_value() get stuck in an infinite loop if the supplied $default isn't in $valid_values and STDIN is empty (so prompt returns $default every time)? OK, it should never happen, but I'd bet it will...
Shouldn't happen (and didn't when I tested it): per EU::MM documentation, prompt() detects when it is being run non-interactively and automatically supplies the default value. It also supplies the default value when he PERL_MM_USE_DEFAULT environment variable is set to (Perl) true.
* Files are now installed with u+w.
Is this problematic for suexec users? (I don't know and haven't tested it yet.)
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.
As a consequence, this means that by default use of the PERL5LIB environment variable is necessary; 'make install' now prints a message suggesting the the user set KOHA_CONF and PERL5LIB in their profile. The default koha-httpd.conf now includes both of these variables.
My main reason for doing this by default is that the C4 modules have at present no independent use outside of supporting Koha's CGI scripts and are intimately tied to the version of those scripts. Putting them in the default @INC will risk problems for users who need to run multiple versions of Koha on a box.
Requiring use of PERL5LIB is not perfect, but it should be noted that we already have one required environment variable in the form of KOHA_CONF.
Only if the config file isn't in the default location in C4::Context, surely?
The default location (/etc/koha.xml) was wrong and has been for a while; my tree now has the default as /etc/koha/koha-conf.xml. Installation in 'standard' and 'single' mode now also uses rewrite-config.PL to paste in the installed location of koha-conf.xml; in that case, C4::Context now uses the following search hierarchy: 1. File name explicitly passed by use C4::Context /path/to/conf. 2. Value of environment variable KOHA_CONF. 3. Installed file name. 4. Last-ditch default of /etc/koha/koha-conf.xml. When installing in developer mode, you will have to set KOHA_CONF.
To be clear, I think this is a step backwards. My goal is for someone running one koha on their own server to be able to install it with the defaults and it to work immediately. I don't think running multiple versions of Koha on a box is a common requirement except when upgrading and I think people would be happy to mess with PERL5LIB in that situation.
I agree that a default installation should result in a "just works" setup of Koha. I disagree that running multiple Koha instances is an uncommon requirement: there are a lot of library consortia and service providers who will need to do exactly that. Even a single library who (responsibly) wants to maintain a production instance and one or more test instances will often need or want to use the same box. Therefore, I'm not in favor of putting C4 in Perl's built-in @INC by default However, I am working on a way to make command-line scripts pick up the correct library even if the user does not set PERL5LIB, and hope to post about it tomorrow.
Related to this, I think it will be useful to consider specifying the version number when doing 'use C4::*' from the scripts, and possibly consider use of the 'only' pragma [1].
Yes, I think that would be a very good idea and one way to guard against accidents if the API changes.
This raises the issue of Koha's main software version number. At present, it ostensibly lives in both kohaversion.pl (used by internal version checking code) and C4/Context.pm (solely for use by Makefile.PL). That's one place too many, so I've edited kohaversion.pl so that it can be used by WriteMakefile()'s VERSION_FROM. Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709
"Galen Charlton" <galen.charlton@liblime.com> wrote:
On 12/13/07, MJ Ray <mjr@phonecoop.coop> wrote:
Can _get_value() get stuck in an infinite loop if the supplied $default isn't in $valid_values and STDIN is empty (so prompt returns $default every time)? OK, it should never happen, but I'd bet it will...
Shouldn't happen (and didn't when I tested it): per EU::MM documentation, prompt() detects when it is being run non-interactively and automatically supplies the default value. [...]
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?
Is this problematic for suexec users? (I don't know and haven't tested it yet.)
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. [C4 installation to koha or INC]
To be clear, I think this is a step backwards. My goal is for someone running one koha on their own server to be able to install it with the defaults and it to work immediately. I don't think running multiple versions of Koha on a box is a common requirement except when upgrading and I think people would be happy to mess with PERL5LIB in that situation.
I agree that a default installation should result in a "just works" setup of Koha. I disagree that running multiple Koha instances is an uncommon requirement: there are a lot of library consortia and service providers who will need to do exactly that. Even a single library who (responsibly) wants to maintain a production instance and one or more test instances will often need or want to use the same box.
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? I think those library consortia and service providers (should?) have sysadmins who can cope with changing the default module path when they want to run multiple Koha versions (not instances) at once. Single libraries will probably at least need to copy the database for test instances, so it just becomes safer to run it on another (virtual, perhaps) server and not risk the production instance.
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-pa... Anyway, I think a bigger problem is requiring new users to make more config steps. Can we optimise this for new first installs? [specifying the version number when doing 'use C4::*']
Yes, I think that would be a very good idea and one way to guard against accidents if the API changes.
This raises the issue of Koha's main software version number. At present, it ostensibly lives in both kohaversion.pl (used by internal version checking code) and C4/Context.pm (solely for use by Makefile.PL). That's one place too many, so I've edited kohaversion.pl so that it can be used by WriteMakefile()'s VERSION_FROM.
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? 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? Puzzled,
Hi, On 12/14/07, MJ Ray <mjr@phonecoop.coop> wrote:
"Galen Charlton" <galen.charlton@liblime.com> wrote:
On 12/13/07, MJ Ray <mjr@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-pa...
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@liblime.com p: 1-888-564-2457 x709
"Galen Charlton" <galen.charlton@liblime.com> wrote:
On 12/14/07, MJ Ray <mjr@phonecoop.coop> wrote:
"Galen Charlton" <galen.charlton@liblime.com> wrote:
On 12/13/07, MJ Ray <mjr@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.
OK, so will you commit something like this, or shall I? diff --git a/Makefile.PL b/Makefile.PL index b3b5002..8050c41 100644 --- a/Makefile.PL +++ b/Makefile.PL @@ -849,7 +849,7 @@ sub _get_value { } my $val = prompt($msg, $default); - while (exists $valid_values->{$key} and not exists $valid_values->{$key}->{$val}) { + while (exists $valid_values->{$key} and not exists $valid_values->{$key}->{$val} and ($val!=$default)) { my $retry_msg = "Value '$val' is not a valid option.\n"; $retry_msg .= "Please enter a value"; $retry_msg .= _add_valid_values_disp($key, $valid_values);
[...] 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. [...] 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. [...]
(Can't they just use permissions rather than ACLs?) Anyway, some web hosts will use suexec, so it would be good if we can make sure koha plays nice with it, even if not recommended.
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-pa...
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.
Maybe not absent the rest of Koha, but other scripts (think contrib) may want to use them later and it would be cleaner if they don't have to be installed into koha or with koha-specific details that they don't need otherwise. I think C4 is more than simply organising Koha's code - it defines the API used by other developers.
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.
I'll be disappointed if packaged koha is as much hassle to install and get running as RT. (We're keen RT users, but the debian package doesn't make life much simpler IME.) [C4-finding scripts]
The upshot is that now, after doing an installation, no environment variables need to be set to use the command-line tools.
Great. Why should they still have to be set in Apache on single-Koha hosts?
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.
So someone make C4::Version if they fancy it. It seemed cleaner to me for C4::Context (which is loaded by everything, to get the configuration) to host it. That said, even while the database is in real flux, C4/Context.pm has had 25 commits during kohaversion.pl's 37, so probably wouldn't need committing much more frequently.
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. [...]
How? Are you suggesting the C4::Context module will invoke the kohaversion.pl script? So script loads module loads script? If so, this really seems a strange way to do it. Why would we need to override the VERSION method? I thought the idea was to use only.pm. Very confused about the confusing VERSION system, -- MJ Ray http://mjr.towers.org.uk/email.html tel:+44-844-4437-237 - Webmaster-developer, statistician, sysadmin, online shop builder, consumer and workers co-operative member http://www.ttllp.co.uk/ - Writing on koha, debian, sat TV, Kewstoke http://mjr.towers.org.uk/
Hi, On 12/17/07, MJ Ray <mjr@phonecoop.coop> wrote:
"Galen Charlton" <galen.charlton@liblime.com> wrote:
On 12/14/07, MJ Ray <mjr@phonecoop.coop> wrote:
"Galen Charlton" <galen.charlton@liblime.com> wrote:
On 12/13/07, MJ Ray <mjr@phonecoop.coop> wrote: again. Can we add the supplied default value to the valid values, just to be sure?
Yep.
OK, so will you commit something like this, or shall I?
I committed a change on 14 December for this. [snippage re C4]
Maybe not absent the rest of Koha, but other scripts (think contrib) may want to use them later and it would be cleaner if they don't have to be installed into koha or with koha-specific details that they don't need otherwise. I think C4 is more than simply organising Koha's code - it defines the API used by other developers.
C4 is an API which is generally non-functional if not connected to a Koha database. Sorry, I find it rather unlikely that any Koha contribs that involve Perl code (outside of a consumer of one of the web services) will be developed or deployed outside of a full Koha installation.
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.
I'll be disappointed if packaged koha is as much hassle to install and get running as RT. (We're keen RT users, but the debian package doesn't make life much simpler IME.)
Once a package is created that includes all of the dependencies, I do not see why there should be any particular issue. The only things that would require manual setup would be presumably (a) creating the mysql database, since I assume a Debian package installer wouldn't do this automatically as a matter of policy. (b) starting Zebra and zebraqueue_daemon (or the cronjob) (c) tuning the Apache configuration, assuming that Koha is not necessarily the only web app installed.
[C4-finding scripts]
The upshot is that now, after doing an installation, no environment variables need to be set to use the command-line tools.
Great. Why should they still have to be set in Apache on single-Koha hosts?
Considering that the supplied koha-httpd.conf already does this, I do not see what the issue is.
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.
So someone make C4::Version if they fancy it. It seemed cleaner to me for C4::Context (which is loaded by everything, to get the configuration) to host it.
Yes, I agree that this is the way to go.
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. [...]
How? Are you suggesting the C4::Context module will invoke the kohaversion.pl script? So script loads module loads script? If so, this really seems a strange way to do it.
That is in fact the current behavior. However, I thus far have not found any reason why this is preferable to having a C4::Version module, so I'm inclined to change this.
Why would we need to override the VERSION method? I thought the idea was to use only.pm.
I'm experimenting with both approaches. Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709
Galen Charlton wrote:
Once a package is created that includes all of the dependencies, I do not see why there should be any particular issue. The only things that would require manual setup would be presumably
(a) creating the mysql database, since I assume a Debian package installer wouldn't do this automatically as a matter of policy.
This can be handle via debconf and dbconfig-common. I already setup this several times. The default will be to create a mysql database on the local machine but the administrator can easily decide otherwise. As an example, you can see my [not yet in Debian] dotclear package (a mysql/php blog engine) : http://www-id.imag.fr/~danjean/deb.html#dotclear I can work on this once I finish to package yaz (licenses issues that should be corrected) and zebra.
(b) starting Zebra and zebraqueue_daemon (or the cronjob)
This should be handled by init.d scripts (and perhaps desactivated by default, but in this case, the user should only need to change a variable in /etc/default/koha)
(c) tuning the Apache configuration, assuming that Koha is not necessarily the only web app installed.
Here, I agree. There is currently no easy way to configure apache from a installing package point of view. webapps-common will perhaps change this in the future but it is not yet ready to be uploaded. So the package will need to provide apache config files as examples and a clear documentation about how to enable them. About putting C4 in a system-wide perl directory or in an application specific directory (/usr/share/koha/perl probably), I do not thing that Debian have specific requirement. It is more up to you (upstream) to decide if the API is public or not. If C4 is installed in the system-wide perl directory AND if other packages depend on it, then coordination between theses packages will be needed at each koha upgrade to unsure correct dependencies and smooth upgrade path. Best regards, Vincent -- Vincent Danjean GPG key ID 0x9D025E87 vdanjean@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pacakges: http://www-id.imag.fr/~danjean/deb.html#package APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main
Le 12 déc. 07 à 19:56, Galen Charlton a écrit :
** 'single': install everything under one subdirectory; meant for users who do not have root on their host but are allowed to install software.
The problem is that you still need to be root to use the koha- httpd.conf file (steps 5-7). Almost everything in this file can be written in a .htaccess for a server that has mod_rewrite and mod_env. The only problem is the use of DocumentRoot. By using this directive the opac and the intranet cannot be accessed from the same root. Is there a way to configure the system to be able to access the opac under say example.org/opac and the intranet under example.org/admin ? I tried to install such a setting with 2.2.9 but the problem is that the links in both ui point back to the root e.g. example.org/cgi-bin. But you would like them to point to example.org/opac/cgi-bin for the opac and example.org/admin/cgi-bin for the intranet. You cannot use a rewrite rule for that since in general you don't know if the request for example.org/cgi-bin is for the opac or for the intranet. Is there some variable I can set to prefix the links generated in the ui ? Actually the most flexible would be two variables per ui, one for the the prefix location of the templates and another for the prefix location of the scripts. This could be specified in koha-conf.xml. Best, Daniel
Hi, On 12/13/07, Bünzli Daniel <daniel.buenzli@erratique.ch> wrote:
Le 12 déc. 07 à 19:56, Galen Charlton a écrit :
** 'single': install everything under one subdirectory; meant for users who do not have root on their host but are allowed to install software.
The problem is that you still need to be root to use the koha- httpd.conf file (steps 5-7). Almost everything in this file can be written in a .htaccess for a server that has mod_rewrite and mod_env. [snip] Is there some variable I can set to prefix the links generated in the ui ? Actually the most flexible would be two variables per ui, one for the the prefix location of the templates and another for the prefix location of the scripts. This could be specified in koha-conf.xml.
There are no variables in place for specifying a prefix for the URL path, alas, but I agree that supporting an .htaccess-only configuration is a worthy goal. I will play around with this idea, but it will probably be a while before I come up with a branch for this unless somebody has a clever idea about how to do it without touching almost all of the scripts and templates. Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709
Bünzli Daniel <daniel.buenzli@erratique.ch> wrote: [...]
I tried to install such a setting with 2.2.9 but the problem is that the links in both ui point back to the root e.g. example.org/cgi-bin. But you would like them to point to example.org/opac/cgi-bin for the opac and example.org/admin/cgi-bin for the intranet. You cannot use a rewrite rule for that since in general you don't know if the request for example.org/cgi-bin is for the opac or for the intranet.
Really? The few file names which are shared seem to be copies of the same file (checked with diff), but it's easier with two virtualhosts. A long and seriously unfun RewriteCond regexp might be possible. Prefixing (of koha and opac links and also database tables) isn't supported yet AFAICR, but probably should be on many wishlists. Best wishes, -- MJ Ray http://mjr.towers.org.uk/email.html tel:+44-844-4437-237 - Webmaster-developer, statistician, sysadmin, online shop builder, consumer and workers co-operative member http://www.ttllp.co.uk/ - Writing on koha, debian, sat TV, Kewstoke http://mjr.towers.org.uk/
Le 14 déc. 07 à 13:34, MJ Ray a écrit :
Really? The few file names which are shared seem to be copies of the same file (checked with diff),
True, the result of
diff -s -r intranet/cgi-bin opac/cgi-bin/opac
reveals this. I managed to avoid virtual hosts by doing the following. But it is really an ugly solution. I installed koha in single mode at $ROOT/ koha. $ROOT is the root from which files are served. Then I did
ln -s $ROOT/intranet/htdocs/intranet-tmpl $ROOT/intranet-tmpl ln -s $ROOT/opac/htdocs/opac-tmpl $ROOT/opac-tmpl mkdir -p $ROOT/cgi-bin/koha cp -R $ROOT/koha/intranet/cgi-bin/* $ROOT/cgi-bin/koha/ cp -R $ROOT/koha/opac/cgi-bin/opac/* $ROOT/cgi-bin/koha/
And created a $ROOT/.htaccess with the following content (maybe the other rules found in virtual hosts should also go here) :
AddHandler cgi-script .pl RewriteEngine on RewriteBase /
RewriteRule ^opac$ cgi-bin/koha/opac-main.pl [R=permanent,L] RewriteRule ^admin$ cgi-bin/koha/mainpage.pl [R=permanent,L]
RewriteCond %{QUERY_STRING} (.*?)(?:[A-Za-z0-9_-]+)=&(.*) RewriteRule (.+) $1?%1%2 [N,R,NE]
SetEnv KOHA_CONF "$ROOT/koha/etc/koha-conf.xml" SetEnv PERL5LIB "$ROOT/koha/lib"
Best, Daniel
Bünzli Daniel <daniel.buenzli@erratique.ch> wrote:
I managed to avoid virtual hosts by doing the following. But it is really an ugly solution. I installed koha in single mode at $ROOT/ koha. $ROOT is the root from which files are served.
Then I did
ln -s $ROOT/intranet/htdocs/intranet-tmpl $ROOT/intranet-tmpl ln -s $ROOT/opac/htdocs/opac-tmpl $ROOT/opac-tmpl mkdir -p $ROOT/cgi-bin/koha cp -R $ROOT/koha/intranet/cgi-bin/* $ROOT/cgi-bin/koha/ cp -R $ROOT/koha/opac/cgi-bin/opac/* $ROOT/cgi-bin/koha/
Yikes! I thought you were going to use the .htaccess rewrites to avoid merging the two cgi-bin somehow. Does this have implications for cookies and logins... but then, are librarians special readers anyway?
And created a $ROOT/.htaccess with the following content (maybe the other rules found in virtual hosts should also go here) :
OK, it's the end of a long week and I've been ill, so let's try some comments:- # Make sure perl cgi scripts are running.
AddHandler cgi-script .pl
# Start the rewriter.
RewriteEngine on RewriteBase /
# Redirect the front pages.
RewriteRule ^opac$ cgi-bin/koha/opac-main.pl [R=permanent,L] RewriteRule ^admin$ cgi-bin/koha/mainpage.pl [R=permanent,L]
# The main multi-purpose rewriter.
RewriteCond %{QUERY_STRING} (.*?)(?:[A-Za-z0-9_-]+)=&(.*) RewriteRule (.+) $1?%1%2 [N,R,NE]
# Finally, the usual koha config variables.
SetEnv KOHA_CONF "$ROOT/koha/etc/koha-conf.xml" SetEnv PERL5LIB "$ROOT/koha/lib"
# - Why a RewriteCond here not a QSA flag on the Rule? # - Why a Redirect [R] flag on it? Does that preserve POST data? Puzzled, -- MJ Ray http://mjr.towers.org.uk/email.html tel:+44-844-4437-237 - Webmaster-developer, statistician, sysadmin, online shop builder, consumer and workers co-operative member http://www.ttllp.co.uk/ - Writing on koha, debian, sat TV, Kewstoke http://mjr.towers.org.uk/
Le 14 déc. 07 à 19:12, MJ Ray a écrit :
Yikes!
Yes I know.
I thought you were going to use the .htaccess rewrites to avoid merging the two cgi-bin somehow.
First I thought this wouldn't really be possible unless you manually list all files (which would be inefficient). But now that I look at the opac scripts I see most are prefixed by 'opac'. I'll give it a try in a few days and post my results.
Does this have implications for cookies and logins... but then, are librarians special readers anyway?
No idea.
# The main multi-purpose rewriter.
RewriteCond %{QUERY_STRING} (.*?)(?:[A-Za-z0-9_-]+)=&(.*) RewriteRule (.+) $1?%1%2 [N,R,NE]
# - Why a RewriteCond here not a QSA flag on the Rule? # - Why a Redirect [R] flag on it? Does that preserve POST data?
I have no idea about this rule. I just found it in the koha-http.conf so I added it. It seemed somewhat important... There are also other rewrites that I don't know if they are convenience rewrites or essential to get the system working in the sense that the ui generates such uri (e.g. those for /bib/). Best, Daniel
I revised my mod_rewrite rules for an install without virtual hosts. The following seems to work. 1. Install koha in single mode under $ROOT/koha where $ROOT is the location from which files are served. 2. Create the file $ROOT/.htaccess file with the following rules
## Depending on the webserver configuration this may not be necessary AddHandler cgi-script .pl RewriteEngine on RewriteBase /
# Redirect front pages RewriteRule ^opac$ koha/opac/cgi-bin/opac/opac-main.pl [R=permanent,L] RewriteRule ^admin$ koha/intranet/cgi-bin/mainpage.pl [R=permanent,L]
# Redirect template requests RewriteRule ^intranet-tmpl(.*)$ koha/intranet/htdocs/intranet-tmpl$1 [L] RewriteRule ^opac-tmpl(.*)$ koha/opac/htdocs/opac-tmpl$1 [L]
# Redirect opac cgi requests RewriteRule ^cgi-bin/koha/opac(.*)$ koha/opac/cgi-bin/opac/opac$1 [L] RewriteRule ^cgi-bin/koha/sco(.*)$ koha/opac/cgi-bin/opac/sco$1 [L] RewriteRule ^cgi-bin/koha/maintenance.pl(.*)$ koha/opac/cgi-bin/opac/ maintenance.pl$1 [L]
# Other cgi requests are intranet requests RewriteRule ^cgi-bin/koha/(.*)$ koha/intranet/cgi-bin/$1 [L]
# Do we need this ? RewriteCond %{QUERY_STRING} (.*?)(?:[A-Za-z0-9_-]+)=&(.*) RewriteRule (.+) $1?%1%2 [N,R,NE]
# Koha config variables. SetEnv KOHA_CONF "$ROOT/koha/etc/koha-conf.xml" SetEnv PERL5LIB "$ROOT/koha/lib"
Best, Daniel
On 12/17/07, Bünzli Daniel <daniel.buenzli@erratique.ch> wrote:
# Do we need this ? RewriteCond %{QUERY_STRING} (.*?)(?:[A-Za-z0-9_-]+)=&(.*) RewriteRule (.+) $1?%1%2 [N,R,NE]
It's not an essential part of Koha, nothing will break if you don't use it, however it performs a fairly useful function if you like pretty URIs. I did a blog post about the purpose of it a while back http://kados.org/apache/remove-empty-parameters-from-uris/ Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
On 12/12/07, Galen Charlton <galen.charlton@liblime.com> wrote:
I loaded the code from this repository about an hour ago (14 Dec 2:25 am UTC-6). When I run Makefile.PL I get the following message: [Fri Dec 14 03:17:07 2007] Makefile.PL: Warning: prerequisite MARC::Crosswalk::DublinCore 0.03 not found. We have 0.02. I have installed this module using CPAN and I tried searching for the 0.03 version but I was not able to find it. Regards, Bradley Peters.
Hi, On 12/14/07, Bradley D. Peters <bdp@moberley.com> wrote:
On 12/12/07, Galen Charlton <galen.charlton@liblime.com> wrote: [Fri Dec 14 03:17:07 2007] Makefile.PL: Warning: prerequisite MARC::Crosswalk::DublinCore 0.03 not found. We have 0.02.
I have installed this module using CPAN and I tried searching for the 0.03 version but I was not able to find it.
After poking around, it looks like 0.03 was a typo. I've corrected my tree to reflect 0.02. Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709
Hi, On 12/12/07, Galen Charlton <galen.charlton@liblime.com> wrote:
Tarball with the revised installer:
http://manage-gmc.dev.kohalibrary.com/koha-3.00.00.032.tar.gz
A new tarball reflecting the current state of my tree is available: http://manage-gmc.dev.kohalibrary.com/koha-3.00.00.035.tar.gz A summary of the changes (most of which I've already mentioned on koha-devel): * Dropped requirement to set KOHA_CONF and PERL5LIB to use command-line tools after a 'standard' or 'single' install. * Now supports full automation of perl Makefile.PL. * DB permissions checks in web installer improved. * Various bugfixes to the installer * Plus all of the non-installer work done in HEAD during the past few days. Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709
participants (6)
-
Bradley D. Peters -
Bünzli Daniel -
Galen Charlton -
Joshua Ferraro -
MJ Ray -
Vincent Danjean