I hope everybody has been VERY CAREFUL on C4::context.pm that Andrew posted yesterday... It's really a GREAT SCRIPT : * well documented * nice and clean perl * very useful. * extendable as we want and need. I think everybody should follow andrew paths... For the coming scripts, i STRONGLY recommend to use C4::context.pm and forget anything else... About parameters : ------------------------- I think we're on a dangerous way... some parameters are in /etc/koha.conf, some are in systempreferences table. I think, and chris too, that we should use koha.conf ONLY for DB parameters, and systempreferences for everything else. Example : it's bad, i think, to have theme in systempref and theme-path in koha.conf. Does anyone have an objection ? -- Paul
On Thu, 3 Oct 2002, paul POULAIN wrote:
About parameters : ------------------------- I think we're on a dangerous way... some parameters are in /etc/koha.conf, some are in systempreferences table. I think, and chris too, that we should use koha.conf ONLY for DB parameters, and systempreferences for everything else. Example : it's bad, i think, to have theme in systempref and theme-path in koha.conf.
I'm not sure. It seems that the systempreferences table ought to apply to the entire Koha setup throughout the library, and /etc/koha.conf should have a) information necessary for the web server to find the database, and b) information pertinent only to that particular web server. For instance, let's say that a library has branches in New York and in Washington, DC. There are two web servers, www.dc.library.org and www.ny.library.org. On the Washington server, the template files are in /software/web/koha/themes, whereas on the New York server, they are in C:\Web Documents\Koha\Local\Themes (Perl is quite portable, so I see no reason why Koha couldn't be ported to Windows, MacOS, etc.) The library as a whole might want to set "MyTheme" as the site-wide default theme, so it makes sense to put that in the Koha database. But each web server needs to find that theme in its own setup, which can vary from one server to the next, so it makes sense to put that in /etc/koha.conf. One gray area that comes to mind is printers: when Koha prints something, the printer that it uses depends on several things: who the user is (librarian or patron, and perhaps children shouldn't be allowed to print at all), which machine ve is using (a librarian in her office should be able to print to her printer, whereas a patron on the 3d floor of the New York branch should print to the 3d floor common printer. A patron using Koha from home shouldn't be allowed to print to a library printer at all). I'm not sure how much, if any, of this should go in /etc/koha.conf, and how much in the database. On one hand, it's the web server that will be printing (and it can find out which queues are available to it), so perhaps the default printer should be set there. On the other hand, this is Koha configuration, not web configuration, so perhaps it should go in the database. On the whole, I agree that /etc/koha.conf should contain as little as possible. I'm just trying to come up with scenarios in which it would make sense to put additional stuff in /etc/koha.conf. -- Andrew Arensburger Actually, these _do_ represent the arensb@ooblick.com opinions of ooblick.com! Generic Tagline V 6.01
On Thu, 3 Oct 2002, paul POULAIN wrote:
About parameters : ------------------------- I think we're on a dangerous way... some parameters are in /etc/koha.conf, some are in systempreferences table.
Andrew Arensburger wrote: On the whole, I agree that /etc/koha.conf should contain as little as possible. I'm just trying to come up with scenarios in which it would make sense to put additional stuff in /etc/koha.conf.
We run three independent Kohas on a single web server. This requires three separate copies of koha.conf (hardwired in Output.pm). This also requires that we run six virtual hosts and a complicated file structure with lots of duplication. This also means that I have spent a lot of time evauating various options for file structure and configuration. We don't experience the same difficulties with other web based services. I think that a re-organistaion of the koha file structure couldhelp reduce complexity - thus simplifying the config options and reducing complexity for programming, installation, maintenance and security. As a basis for discussion, this is the type of file structure we'd suggest: /usr/local/www/htdocs/koha ./* (shared) ./opac ./opac/includes ./opac/templates ./intranet ./intranet/includes ./intranet/templates /usr/local/www/cgi-bin/koha ./* (shared) ./C4 ./opac ./intranet /usr/local/www/htdocs/koha/images ./* (shared) ./opac ./intranet IMO, the advantages of this type of layout are: 1. Easily integrated into pre-existing web user space (no additional virtual host(s) required) 2. Folder based differentiation between "opac" and "intranet" (rather than current virtual host based differentiation) 3. More differentiation between "opac" and "intranet" specific resources. 4. Identifiable folders to contain shared (opac versus intranet) resources of all types. 5. Path based configuration options independent of virtual host aliases IMO, the one disadvantage is that more configuration options will need to be set to replace the separation currently provided by virtual host aliases. This may appear to be onerous... but I think the present structure gives a false feeling of security/logic - the separation between "opac" and "intranet" resources are somewhat more blurred than they appear to be at face value. Again, my reasons for considering the above is that Koha configuration seems potentially complex (compared with other web based services that we run). I would like to propose some more detailed changes but after having a look at CVS structure over last week - I can't get my head around what the current file structure actually _is_ ;^) I am not a programmer so have probably totally overlooked lots of important problems associated with above. I am happy to do more work on this given some direction.... R.
On Fri, Oct 04, 2002 at 10:18:27AM +1000, Roger Buck wrote:
We run three independent Kohas on a single web server. This requires three separate copies of koha.conf (hardwired in Output.pm).
I'm currently fixing things to use the C4::Context module; by default, it reads the configuration from /etc/koha.conf, but you can override this with the $KOHA_CONF environment variable. Here's the VirtualHost block that I'm using: <VirtualHost 192.168.132.83> ServerName koha2.ooblick.com DocumentRoot /folks/koha/internal-unstable/htdocs ScriptAlias /cgi-bin/koha/ /folks/koha/internal-unstable/cgi-bin/ AddHandler server-parsed .html SetEnv PERL5LIB /folks/koha/internal-unstable/perl SetEnv KOHA_CONF /folks/koha/internal-unstable/koha.conf </VirtualHost>
/usr/local/www/cgi-bin/koha ./C4
This is the main bit that I (slightly) disagree on: C4 contains Perl modules that will be used by everything that uses Koha, not just by the web server. As I understand it, the web interface is the only one being really worked on, but if and when the other ones (e.g., standalone text- or GUI-based tool) are brought up to date, they'll need to use the C4 Perl modules as well. On top of that, any maintenance cron jobs (e.g., to recalculate fines and send out notices) will need to use those as well. So IMHO this ought to be installed like a normal Perl package, wherever Perl thinks it belongs. Of course, I can also see the advantages of keeping everything in one place, so perhaps if you tell the installer that you'll only be using the web interface on this machine, it'll put the C4 directory where you suggest. -- Andrew Arensburger This message *does* represent the arensb@ooblick.com views of ooblick.com I tried to get a life once, but they were out of stock.
Andrew Arensburger wrote: [--snip--]
I'm currently fixing things to use the C4::Context module; by default, it reads the configuration from /etc/koha.conf, but you can override this with the $KOHA_CONF environment variable. Here's the VirtualHost block that I'm using:
Excellent! [--snip--]
/usr/local/www/cgi-bin/koha ./C4
This is the main bit that I (slightly) disagree on: C4
[--snip--]
So IMHO this ought to be installed like a normal Perl package, wherever Perl thinks it belongs.
Yes - In general agreed... and...
Of course, I can also see the advantages of keeping everything in one place, so perhaps if you tell the installer that you'll only be using the web interface on this machine, it'll put the C4 directory where you suggest.
... I think this is also a worthwhile option - especially as a work-around some potential problems - For example, accommodating some path restrictions imposed by some third party hosting services where it may not be possible to install perl modules in "normal" locations? R.
Andrew Arensburger wrote:
For instance, let's say that a library has branches in New York and in Washington, DC. There are two web servers, www.dc.library.org and www.ny.library.org. On the Washington server, the template files are in /software/web/koha/themes, whereas on the New York server, they are in C:\Web Documents\Koha\Local\Themes (Perl is quite portable, so I see no reason why Koha couldn't be ported to Windows, MacOS, etc.)
AFAIK, nobody succeded to make koha run on windows. So, it's "unsupported" for instance. It works on Mac OSX (at least 2 installation succeeds, 1 here in France) -- Paul
participants (3)
-
Andrew Arensburger -
paul POULAIN -
Roger Buck