Web: Difference between revisions

From FyshyWyky
Jump to navigationJump to search
(→‎Apache 2.0.x: The CGI suexec problem)
(Big update for separate www.fysh.org server, plus we long since switched to apache 2.2 and php5)
Line 1: Line 1:
= Introduction =
= Introduction =
bowl.fysh.org runs web servers under the primary hostname of www.fysh.org.  We currently utilise [http://httpd.apache.org/ Apache] 1.3.x (as supplied in Debian 'stable') for this purpose, with one instance running on port 80 for http access and a separate instance on port 443 for https access.
[[www.fysh.org]] runs web servers under the primary hostname of www.fysh.org.  We currently utilise [http://httpd.apache.org/ Apache] 2.2.x (as supplied in Debian 'stable') for this purpose, with a single instance running on both port 80 for http access and port 443 for https access.


We may also run additional instances of apache, or other web server software, on other ports as needed.
We may also run additional instances of apache, or other web server software, on other ports as needed.


= Webmaster =
= Webmaster =
All enquiries about www.fysh.org and other web services should be directed to the [mailto:webmaster@fysh.org Fyshy Webmaster].
All enquiries about [[www.fysh.org]] and other web services should be directed to the [mailto:webmaster@fysh.org Fyshy Webmaster].


= User Pages =
= User Pages =
Any user with an account on fysh can create a page on the [[http://en.wikipedia.org/wiki/World_wide_web WWW]] simply by placing the requisite files in a directory called public_html in their home directory.  This will yield a URL of http://www.fysh.org/~username/ for example.
Any user with an account on [[bowl.fysh.org]] can create a page on the [[http://en.wikipedia.org/wiki/World_wide_web WWW]] simply by placing the requisite files in a directory called public_html in their home directory.  This will yield a URL of http://www.fysh.org/~username/ for example.  Please note that /home on [[bowl.fysh.org]] is NFS mounted on [[www.fysh.org]] '''read-only'''.  Thus any web page that needs to store data will have to utilise a [[Databases|Database]].  In some circumstances we will set up a separate area for a user to place web pages that absolutely ''require'' file write access, but we would much rather they use a proper [[Databases|Database]] instead.


= User Domains =
= User Domains =
Additionally we will host the web pages for any domain that a user owns or controls and can get the DNS changed to point to our IP.  Contact the [mailto:webmaster@fysh.org Fyshy Webmaster] to enquire about setting this up.  Note that you should ensure that you have a valid and working webmaster email account under your own domain when this is set up.
Additionally we will host the web pages for any domain that a user owns or controls and can get the DNS changed to point to our IP.  Contact the [mailto:webmaster@fysh.org Fyshy Webmaster] to enquire about setting this up.  Note that you should ensure that you have a valid and working webmaster email account under your own domain when this is set up.
The same caveat as for User Pages about '''read-only'' file access will apply.


Note that whilst we can offer HTTPS access to your domain it will be with a self-signed certificate for www.fysh.org, and as such any user accessing your domain's web page via HTTPS will get a warning about the hostname mismatch.  This is because an SSL certificate for HTTPS is tied to the hostname that the IP the server runs on resolves to.  We only have the one IP to use for web services and thus only one possible HTTPS certificate.
Note that whilst we can offer HTTPS access to your domain it will be with a self-signed certificate for www.fysh.org, and as such any user accessing your domain's web page via HTTPS will get a warning about the hostname mismatch.  This is because an SSL certificate for HTTPS is tied to the hostname that the IP the server runs on resolves to.  We only have the one IP to use for web services and thus only one possible HTTPS certificate.
Line 21: Line 23:


== PHP Configuration ==
== PHP Configuration ==
We currently only provide and support version 4.3.10 of PHP, as supplied by Debian 'stable'.
We currently only provide and support version 5.2.0 of PHP, as supplied by Debian 'stable'.  PHP4, version 4.4.4, is still available, but only via the CGI method and only if you suffix files with .php4.


Our default PHP configuration is somewhat paranoid and as a result you may find you need to adjust some php settings, either by getting [mailto:webmaster@fysh.org us] to change the central config files, or by you making use of a .htaccess file as appropriate.  The setting that most often needs adjustment is open_basedir, although we also default register_globals to 'Off'.
Our default PHP configuration is somewhat paranoid and as a result you may find you need to adjust some php settings, either by getting [mailto:webmaster@fysh.org us] to change the central config files, or by you making use of a .htaccess file as appropriate.  The setting that most often needs adjustment is open_basedir, although we also default register_globals to 'Off'.
= Apache 2.0.x =
Starting 23rd November 2006 there is an experimental installation of Apache 2.0.* running on bowl.fysh.org using port 81 (as opposed to the usual port 80 for HTTP).  The configuration of this matches the current Apache 1.3.x web server as closely as possible, but please see the note below about CGIs.  As such, if a web service that you utilise is listed below please do test it with port 81 and report any problems to [mailto:webmaster@fysh.org The Fyshy Webmaster].
Currently this web server should properly be serving pages under:
*[http://www.fysh.org:81/ www.fysh.org] including user pages, i.e. [http://www.fysh.org:81/~athan/ www.fysh.org/~athan/] and CGIs if properly named with a .cgi or .pl extension.
*[http://wiki.fysh.org:81/ wiki.fysh.org]
*[http://squirrelmail.fysh.org:81/ squirrelmail.fysh.org]
*'''ALL''' virtually hosted websites for users.


== CGIs ==
== CGIs ==
Line 49: Line 41:
The ownership on these directories are set the same as the DocumentRoot directory currently configured for the site.  Thus the owning user of a site can set up just the CGIs, or the whole site if preferred, to be under this directory.
The ownership on these directories are set the same as the DocumentRoot directory currently configured for the site.  Thus the owning user of a site can set up just the CGIs, or the whole site if preferred, to be under this directory.


Note, however, that as yet there have been no changes to the ScriptAlias directive in the apache2 configuration for sites, so it will still be trying to use, i.e.
If you do use CGIs but do not rely at all on them running as a specific user/group then you also needn't worry as things should just work.
 
:        /home/athan/public_html/cgi-bin/foo
 
for
 
:        http://www.miggy.org:81/cgi-bin/foo
 
instead of
 
:        /var/www/virtual/www.miggy.org/cgi-bin/foo
 
So what does this mean for you?  Well, if you don't use any CGIs at all you needn't worry, but it's probably a good idea to let us know so we can change your ScriptAlias setting to point under /var/www/virtual, rather than wait until you need the functionality and have to get us to change it then.  ''NB: ScriptAlias is just a convenience so that you can use arbitrary filenames for CGI scripts/files so long as they're placed in the specified directory.  As configured apache1 and 2 will execute files as CGIs if their filename ends in either '''.cgi''' or '''.pl''' no matter where they are located.''
 
If you do use CGIs but do not rely at all on them running as a specific user/group then you also needn't worry as things should just work.  This means not having User and/or Group directives in the apache 1.3.x configuration for your virtual host (check /etc/apache/httpd.conf).
 
If you use CGIs and currently have User and/or Group directives for your virtual host in /etc/apache/httpd.conf, even if the
CGIs do not actually specifically use this functionality, then your CGIs will not work on port 81 with apache2.  It will be trying to run the CGIs as the specified User and/or Group which will then fail when suexec finds they are not under /var/www.
 
The best thing for you to do is '''copy''' (''not move'', as that would impact on their functionality with apache 1.3.x/port 80) the CGI into the appropriate /var/www/virtual/<site name>/cgi-bin directory, make any necessary adjustments to the code, and then let us know to change the apache2 configuration to point ScriptAlias there.  Alternatively, as the current bowl just has "One Big Filesystem[tm]", you can instead hardlink (that's an "ln" command without the "-s" option which would make it a symbolic link instead) the CGI files to the /var/www location.  i.e. to have /home/athan/public_html/cgi-bin/foo.cgi work under apache2 issue the command:
 
ln /home/athan/public_html/cgi-bin/foo.cgi /var/www/virtual/www.miggy.org/cgi-bin/foo.cgi
 
which will make the latter an additional ''name'' for the exact same file and contents.


[[Category:Services]]
[[Category:Services]]

Revision as of 14:55, 27 November 2007

Introduction

www.fysh.org runs web servers under the primary hostname of www.fysh.org. We currently utilise Apache 2.2.x (as supplied in Debian 'stable') for this purpose, with a single instance running on both port 80 for http access and port 443 for https access.

We may also run additional instances of apache, or other web server software, on other ports as needed.

Webmaster

All enquiries about www.fysh.org and other web services should be directed to the Fyshy Webmaster.

User Pages

Any user with an account on bowl.fysh.org can create a page on the [WWW] simply by placing the requisite files in a directory called public_html in their home directory. This will yield a URL of http://www.fysh.org/~username/ for example. Please note that /home on bowl.fysh.org is NFS mounted on www.fysh.org read-only. Thus any web page that needs to store data will have to utilise a Database. In some circumstances we will set up a separate area for a user to place web pages that absolutely require file write access, but we would much rather they use a proper Database instead.

User Domains

Additionally we will host the web pages for any domain that a user owns or controls and can get the DNS changed to point to our IP. Contact the Fyshy Webmaster to enquire about setting this up. Note that you should ensure that you have a valid and working webmaster email account under your own domain when this is set up.

The same caveat as for User Pages about 'read-only file access will apply.

Note that whilst we can offer HTTPS access to your domain it will be with a self-signed certificate for www.fysh.org, and as such any user accessing your domain's web page via HTTPS will get a warning about the hostname mismatch. This is because an SSL certificate for HTTPS is tied to the hostname that the IP the server runs on resolves to. We only have the one IP to use for web services and thus only one possible HTTPS certificate.

If you have a desperate need to run a domain with HTTPS on the www.fysh.org server under your own domain and need to have your own distinct certificate then we may be able to arrange for additional IP(s) as needed, but we will have to pass on the charges of our hosting provider for this to you.

Dynamic Content

Going beyond simple static content we support use of [CGI]s, written using any of the installed development languages, and PHP scripts directly via an Apache module. NB: in the case of CGIs the filename will have to end with either .cgi or .pl, unless the script is inside a virtual host's /cgi-bin/ directory. Files whose name have no extension or other than .cgi or .pl will have their contents displayed instead of being run.

PHP Configuration

We currently only provide and support version 5.2.0 of PHP, as supplied by Debian 'stable'. PHP4, version 4.4.4, is still available, but only via the CGI method and only if you suffix files with .php4.

Our default PHP configuration is somewhat paranoid and as a result you may find you need to adjust some php settings, either by getting us to change the central config files, or by you making use of a .htaccess file as appropriate. The setting that most often needs adjustment is open_basedir, although we also default register_globals to 'Off'.

CGIs

There is a problem with the use of CGIs where the site is configured to run them as a specific user and/or group, rather than the default of www-data for both, AND where the CGI code relies on this for access to files, be this reading/writing extant files or creating new ones.

By default Debian installs 'suexec' (the program that is used to securely allow CGIs to run under a different user/group) to only allow CGIs under /var/www. In the past we have compiled our own local version of this to use the path prefix /home instead. However this is fraught with problems, including the time and hassle in compiling a new version for each patch and the fact that there's a window between installing a new version of apache and us remembering to redo the custom suexec, during which the functionality is broken.

As such with apache2 we have decided to stick with the default /var/www prefix. To support this every apache2 configured site now has a directory under /var/www/virtual, with two sub-directories, cgi-bin and site, i.e.

/var/www/virtual/www.miggy.org
/var/www/virtual/www.miggy.org/site
/var/www/virtual/www.miggy.org/cgi-bin

The ownership on these directories are set the same as the DocumentRoot directory currently configured for the site. Thus the owning user of a site can set up just the CGIs, or the whole site if preferred, to be under this directory.

If you do use CGIs but do not rely at all on them running as a specific user/group then you also needn't worry as things should just work.