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@lists.katipo.co.nz
> http://lists.katipo.co.nz/mailman/listinfo/koha
I have had a good look at this over the weekend leading to a significant shift in perspective 
I now believe the cgi-bin structure is 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>
Thanks,
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@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha 
