552021-02-24 02:47:00ClintonEbadifix example, fast_php is deprecated542020-02-28 03:14:08ClintonEbadiChange language in HTTP subsection to make it clearer that the linked page explains how to generate a CSR532018-10-20 18:18:58ClintonEbadibits about sni and windows xp are finally not very relevant, ip address comment more generic ... for now digitalocean gives free ipv4 as long as we use them522018-10-20 18:14:37ClintonEbadiphp5 -> fast_php512016-02-09 21:59:33StephenMichelsentence order makes sense now502014-05-02 05:43:29c-50-148-186-167.hsd1.ca.comcast.net492014-04-23 03:58:12ClintonEbadithe cruft! oh the cruft!482014-04-23 03:50:52ClintonEbadiwebdav in general works, but dav.hcoop.net is gone472014-04-23 01:28:31MattCarberryRemoved WebDAV info now that it no longer exists.462013-01-21 17:50:35ClintonEbadifun fact: because of TIME you don't need an IP to use SSL any more, hooray452013-01-14 07:15:36ClintonEbaditypos442013-01-14 07:12:58ClintonEbadicat / coming domtool-tail changes432013-01-06 11:53:10ClintonEbadinote that permissions do not actually affect anything and only need to be set to make suexec shut up422013-01-05 06:09:35c-66-41-66-133.hsd1.mn.comcast.net412012-12-17 21:17:32ClintonEbadiorganizational nit402009-11-18 13:20:50AdamChlipalaI believe the original was right. Let us know if one of our machines is missing 'fsr'.392009-11-18 08:09:26quinto.staff.cscs.chtypo fix382009-09-09 20:08:25ClintonEbadiRevert to revision 36.372009-09-09 18:20:3393.174.94.59zD0N8X on Aviation Environment Protection (CAEP) is responsible for setting standards relat-, [[http://ukazurenet.com/members/qantas_2D00_airline/default.aspx|qantas airline]]In regions where temperat362008-07-15 19:58:18AdamChlipaladomtool-tail352008-07-07 04:28:02localhostconverted to 1.6 markup342008-05-25 13:30:37AdamChlipalaRunningYourOwnApache332008-04-20 23:48:27DavorOcelic322008-04-20 23:46:57DavorOcelic312008-03-11 17:23:53JustinLeitgebmodify WebDAV instructions -- read and write works with https://dav.hcoop.net302008-01-20 06:42:59MichaelOlsons/and/or/292008-01-20 06:42:12MichaelOlsonAdd PHP explanation282008-01-15 01:55:02adsl-dynamic-pool-xxx.hcm.fpt.vn272007-12-15 17:20:32AdamChlipalamembers -> members2262007-12-14 00:32:43AdamChlipalaStress /var/log/apache2 off limits252007-12-11 03:17:15RyanMikulovsky.htaccess warning242007-11-24 01:53:38RyanMikulovskyREALLY bold it this time232007-11-24 01:53:13RyanMikulovskybold USER222007-11-23 22:01:43RyanMikulovskyUSER.daemon for dynamic websites..212007-11-22 20:11:56AdamChlipalaRewrite Domtool example to use 'webAtIp' like mwolson should have in the first place. ;-)202007-11-19 03:38:31MichaelOlsonupdate dav example. remove ssl example192007-11-17 05:51:28MichaelOlsonTypo182007-11-17 05:50:23MichaelOlsonRemove warning, update paths172007-11-16 02:50:21MichaelOlsonLink to MoinMoin subpage162007-11-14 05:14:27MichaelOlsonHTTPS is a work-in-progress152007-11-12 15:33:37MichaelOlsonupdate freq of webalizer142007-11-12 15:31:44MichaelOlsonMention webalizer and ~/.logs/apache132007-11-12 05:23:30RyanMikulovsky122007-11-12 05:23:00RyanMikulovsky112007-11-12 03:46:17RyanMikulovskyextraneous / at end of WebDAV setup URL102007-11-12 03:45:47MichaelOlsonFix ssl cert instructions link92007-11-12 03:41:18MichaelOlsonAdd HTTPS example and link to ssl cert subpage82007-11-12 03:35:19MichaelOlsonMake DAV example more generic72007-11-12 03:33:37MichaelOlsonAdd DAV example62007-11-12 02:11:34MichaelOlsonInitial DAV and HTTPS instructions, sans examples52007-11-12 01:54:55MichaelOlsonMove "see ..." part to end of section for readability, and point at MemberManual AFS section42007-11-11 20:11:21RyanMikulovskytransfer stuff from MigrationGuide32007-11-11 19:57:53RyanMikulovskyadd a friendly hints, and links, to make common tasks described in the manual easily accessible22007-11-11 19:44:47RyanMikulovskyadd some content12007-10-25 01:22:48MichaelOlsonInitial contentsThis is the chapter of the MemberManual that describes how to serve your website(s).

If you're going to use a domain, please read the next section. If you plan on having static websites without any CGI such as php or perl, then read on. In your home directory, there is a directory named public_html. By default, you can access this at http://www.hcoop.net/~USER. You will never be able to execute server-side scripts when accessing webpages in that manner.

If you plan on having a website that utilizes CGI such as php or perl, then you must either have a domain or an hcoop.net subdomain (i.e., USER.hcoop.net). When you have chosen a domain to be hosted by HCoop, you then simply request control of that domain at the portal. Once it is authorized by an administrator, you will be able to utilize DomTool. DomTool will let Apache and other services know about your domain. Please take a look at using DomTool, DomTool user guide, and DomTool examples to learn how to do this. Our nameservers are ns1.hcoop.net and ns2.hcoop.net. As a hint, DomTool configurations are stored in ~/.domtool/. Some users have made their production configurations readable and so you may be able to learn from them. See the bottom of DomTool examples to find out who is showing off their DomTool configurations. If your web application needs write access to a data directory, give USER.daemon write permission to it and all of its subdirectories. In this example, be sure to replace USER with your username (lowercase): Alternatively, use only fs if you need to set the ACL for just one directory. For database help, take a look at this manual's Databases chapter. To see how you can transfer files to HCoop, see the Transferring Files chapter. In addition, .htaccess files are not processed on our servers. See DomTool Examples to learn how to use rewrite rules and other features normally provided by .htaccess.

We use FastCGI based PHP 7.2 by default to serve .php, .phtml, and .php5 files. We may offer PHP variants (supported variants are documented in the Domtool library reference); to explicitly set the PHP version, use the phpVersion action as follows. To use PHP 5 in a directory or virtual host:

It is likely that another member has configured one of many common applications and documented it on the ../WebApplications page.

Many popular Apache modules for "fast web serving," like mod_python and mod_perl, are incompatible with our security requirements; they force all Python, Perl, etc., scripts run through them to run as a single UNIX user. Thus, to use these modules, you will need to run your own separate web server. See RunningYourOwnApache. You will probably want to run lighttpd instead of your own Apache, since configuring it is much simpler. It also couldn't hurt to petition the authors of these modules to fix this problem. ;-)

The error and access logs are stored in ~/.logs/apache. They are separated by machine and domain. Your ~/.logs/apache directory is updated once every 20 minutes from the "real" logs in /var/log/apache2 on the machine that serves your virtual host. This is almost certainly navajos. It is expected that you don't have permission to read your logs in /var/log/apache2. Instead, use the handy domtool-tail program to view the logs in realtime. For instance, this command line will dump the last entries in the access log for www.domain.com, in the style of the UNIX tail program. We assume that you have Domtool permissions on domain.com. The optional -n LINES argument will fetch that many lines from the log. You can view a graphical representation of your access logs by browsing our webalizer interface at . Its statistics are updated once per day.

When you publish web content, it will probably live in your home directory. The web server will need permission to read your files, or it will return "403 Access Denied" errors. Since your home directory is in AFS, normal UNIX permissions are irrelevant. For instance, if you get a 403 error serving ~/public_html/otherdir/page.html, you might run this to see what's up: Oops! Apache only matches the "system:anyuser" principal, so it only gets the "l" (= "list") permission and can only list your directory contents. Try this to fix it: The first two give full read permission on the mentioned directories. "l" permission is needed in every parent directory of a file to be able to access it, so the last line makes sure "l" is granted to system:anyuser on your home directory. When your web content is accessed through your own virtual host, you can also grant read access to $USER.daemon instead of the broader system:anyuser, where $USER is your username. This is your bizarro-world twin, which Apache runs as when serving your content. Note that your CGI directories and executables should be in the group nogroup; if this is not the case you may see cryptic warnings in your error.log along the lines of suexec policy violation: see suexec log for more details. See the Getting Started chapter of the Member Manual, in particular the AFS section, for information on how to work with AFS's separate notion of permissions.

If you get a 500 server error when running a CGI script, one likely cause is directory permissions. suexec will refuse to run a cgi if its parent directory is writeable by others. So, make sure permissions are set to 755 and not 775. Note that the directory permissions do not actually affect anything (since we're using AndrewFileSystem), but modifying the suexec code to skip the checks is considered too risky.

In order to serve websites over HTTPS, you will need to generate an SSL certificate and optionally request an IP address from us. Generate a Key and Certificate Signing Request, and then either generate a self-signed SSL certificate yourself, buy one from somewhere (search for "ssl certificate" using your search engine of choice for a list of popular vendors), or request a certificate from letsencrypt. Request permission to use your certificate for a domain. Add a stanza to your DomTool configuration file. Examples of this may be found at DomTool/Examples. This relies on TLS SNI to work, which will work in almost all cases (the only notable software no longer supporting SNI is Java 6, which is deprecated). If for any reason you need a dedicated IP address, we are happy to provide you with one as long as our upstream providers will provide them.

WebDAV is a set of extensions to the HTTP protocol which allows users to collaboratively edit and manage files on remote web servers. WebDAV is useful when working on a website using systems that cannot mount an AFS share. General information of WebDAV can be found at. If you want to be able to use DAV services with your own domain name, you will need to set up a host which is served via HTTPS. The Getting HTTPS access working section above should be of help. Then, you will want to add a stanza to your DomTool configuration to serve DAV. An example follows. You will almost certainly want to require authorization to access your davFilesystem, since it runs with your $USER.daemon tokens, and can therefore read and write anything it can. CategoryMemberManual