[Koha] Proposed new cgi directory structure
Roger Buck
rog at saas.nsw.edu.au
Sun Mar 24 21:25:21 NZST 2002
Hello all,
I have had a good look at this over the weekend leading to a significant
shift in perspective :-)
I now believe the existing cgi-bin structure is quite OK... but that
significant improvements can be made by re-organising most of the
_other_ paths.
I have completed 95% of the editing work required and run some local
tests.
There do not seem to be any noticeable problems with the new setup.
The main advantage with the revised structure is that any combination of
koha "intranet" and/or "ipac" and/or web site, can be run in single host
web space without requiring virtual servers etc. A secondary advantage
is that the koha "intranet" content can be easily differentiated and
protected using apache based authentication without limiting the
services available via the public opac interface.
Despite the changes, I think that all of the current flexibility is
retained.
AFAICT, the existing perl code does not need to be modified in any way
to support the new structure.
On the down side, the re-editing is boring and takes a long time <grin>
Atr the time of writing, I have completed more than 95% of re-editing
required to support above.
I would like some feedback.
Here is what I have done - I have edited a local copy of latest cvs
files to comply with following new folder structure.
NB: In the examples below, pathto = /usr/local/www
Create new /etc/koha.conf
database=kohadb
hostname=localhost
user=kohadbuser
pass=xxxxxxxx
includes=/pathto/html/koha/includes
Create a general purpose web site:
/pathto/html
/pathto/cgi-bin
Create koa web installations folders:
/pathto/html/koha/includes
/pathto/html/koha/oadmin
/pathto/html/koha/opac
Create koa cgi-bin folders:
/pathto/cgi-bin/opac
/pathto/cgi-bin/koha
/pathto/cgi-bin/koha/C4
Copy koha distro opac-html\* into /pathto/koha/opac/*
Copy koha distro intranet-html\* into /pathto/koha/oadmin/*
Copy koha distro koha\* into /pathto/cgi-bin/oadmin (icluding C4
directory and its contents).
Copy member.pl + seach.pl into /pathto/cgi-bin/opac
Move /pathto/koha/opac/images/* into /pathto/images/opac/*
Move /pathto/koha/oadmin/images/* into /pathto/images/oadmin/*
Rename opac *.inc files so that they all have opac-* prefix
- rename "join-top.inc" to "opac-join-top.inc"
- rename "members-top.inc" to "opac-members-top.inc"
Move _ALL_ includes from koha distro into /pathto/koha/includes
- It is preferable that any new includes for opac should be
- named using the "opac-" prefix convention (or similar)
Example excerpts from apache httpd.conf:
ServerName library.example.org
ServerPath /usr/local/www
DocumentRoot /usr/local/www/html
#
Alias /images/ "/usr/local/www/html/images/"
SetEnv PERL5LIB "/usr/local/www/cgi-bin/koha"
<Directory /var/www/html>
# This is the root of general purpose website
# NO server side includes!
AllowOverride None
Options -Includes -FollowSymlinks -Indexes
Order Deny,Allow
Allow From All
</Directory>
# ======== Use Server Side Includes Here =======
<Directory /usr/local/www/html/koha/opac>
AllowOverride None
Options +Includes -FollowSymlinks -Indexes
AddHandler server-parsed .html
</Directory>
#
<Directory "/usr/local/www/html/koha/oadmin">
#
AllowOverride None
#
# First, you must enable +Includes or +IncludesNoExec
# in "Options"...
Options +Includes -FollowSymlinks -Indexes
#
# Allow server-parsed content (SSI) for files
AddHandler server-parsed .html
#
# Optional simple server based authentication....
# Authtype Basic
# AuthName Koha-Online-Admin
# AuthUserFile /usr/local/www/ok_users/koha-users
# AuthGroupFile /usr/local/www/ok_groups/koha-groups
# <Limit GET POST PUT DELETE>
# require user koha-admin group lib-admins
# </Limit>
</Directory>
</VirtualHost>
-------
That's it for now.
Thanks for reading this far ;^),
R.
Roger Buck wrote:
>
> PURPOSE OF THIS THREAD:
> To examine options for revision of koa cgi directory tree
>
> CURRENT SITUATION:
> Koha is designed to be installed as two separate services - each having
> a unique web address and folder structure (two virtual web hosts). The
> folder structures for both servers are designed to operate separately
> and independently; The only reason for this is to simplify security.
>
> Currently both services access a single SQL database which may be hosted
> on the same server or on a remote server. The two separate web servers
> are referred to as "koha" and "opac" ("koha" refers to the on-line admin
> interface whilst "opac" refers to the on-line public access catalogue
> interface). The term "intranet" in the koha doc refers specifically to
> the "koha" web site.
>
> PROBLEM:
> Koha is designed to operate in two independent web spaces - this can add
> complexity to installation, security and maintenance.
>
> REQUIREMENTS:
> Any departure from existing structure must provide significant benefits
> whilst minimising changes to existing code base.
>
> AIMS:
> To allow for clarify terminology and layout leading to simplified koha
> installation, security and administration:
>
> PROPOSED NEW DEFINITION FOR "koha":
> The current usage of "koha" is muddled: The current service referred to
> as "koha" (also referred to as Intranet) should be re-named to something
> like "oadmin" (on-line admin). The term "koha" then is free to
> encompasses both the "opac" and "oadmin" services.
>
> Example 1. Current cgi tree:
>
> cgi-bin / - koa
>
> cgi-bin / - opac
>
> Example 2. Proposed new cgi tree structure:
>
> cgi-bin / koha /- C4
> |
> /- oadmin
> |
> /- opac
>
> If the new tree structure is adopted, then I'd suggest a similar change
> to the htdocs tree structure might be fruitful (but that's a separate
> issue).
>
> Without going into detailed explanations of reasoning (except on request
> ;^)...
>
> Example 2 may offer the following advantages:
> 1. The directory names relate more closely to function.
> 2. More flexible - Same config setup for both single and dual services
> 3. All project specific perl stuff stored in single folder
> 4. Simpler apache configuration
> 5. Simpler installation for hosting (especially 3rd part hosting)
> 6. No reduction in security / authorisation options.
>
> Example 2 offers following disadvantages:
> May require some re-coding of hard-coded paths.
>
> What changes are required to support proposed new structure?:
>
> Option 1 - No change required to koha code, all changes can be affected
> solely by editing paths / aliases in webserver config file (httpd.conf).
> This is probably not strictly true as some paths may be hard-coded in
> existing koha code... but it would be better if all hard-coded paths
> could be reduced to relative paths anyhow.
>
> Option 2 - Extend the /etc/koha.conf file to support additional path
> variables.
>
> Option 2 offers benefit of simplified configuration using a conventional
> style, single user editable config file whilst significantly simplifying
> webserver config requirements. The current koha.conf file does not
> require additional development at this time - just a possible
> development direction for the future if this proposal is adopted.
>
> Does anyone see any fundamental problems with proposed changes?
>
> If there is positive feedback to this proposal, I'll follow up with a
> _lot_ more detail... otherwise I'll re-evaluate afresh without wasting
> everyone's time ;^)
>
> Feedback please?
>
> R.
> _______________________________________________
> Koha mailing list
> Koha at lists.katipo.co.nz
> http://lists.katipo.co.nz/mailman/listinfo/koha
More information about the Koha
mailing list