Proposed new cgi directory structure
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.
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@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Roger Buck wrote: [--snip--]
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.
Hmmm I forgot about having done the %s/images/images\/koha/ in *.pl and I have yet to figure out the best way to do that for files like member.pl and search.pl which can be used eithe by opac or koha intranet... maybe bring back the prefix for the opac files: opac-search.pl, opac-members.pl and so on? R.
Roger Buck wrote:
Roger Buck wrote: [--snip--]
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.
After having combed through every file over the last couple of days looking at path configuration I am more familiar with koha in general and now have a few questions: 1. Is there any general desire to re-work the default koha distribution to support more flexible installation options (see prev messages this thread)? 2. If anwer is "yes" then can we do this be extending koha.conf to include a number of path variables (and get rid of all the current hard-coded paths in .html, .inc and .pl files). 3. If "yes" then what is the easiest way to add new variable to koha.conf? 4. While answer is "yes", then I am volunteering to make the necessary changes under the guidance advice of others... or assist in any other way if more appropriate. Thanks :-) R.
Roger Buck wrote: [--snip--]
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.
[-snip--] I have now completed 99% of this (still searching for left-overs). If anyone is interested, let me know and I'll send you a tar.gz of all changes including new html and cgi-bin tree structure (NB: tarball size is about 1M though!) R.
participants (1)
-
Roger Buck