[02] IS PHP, ASP, PERL, SSI, CGI AVAILABLE HERE?
YES!
This is probably the #1 FAQ regarding SDF hosted web sites.
The web server on the cluster uses suEXEC and suPHP. These are
httpd modules that can launch a CGI script found in a user's
html directory. A script owned by user bob (say,
-rwxr-xr-x - bob arpa - - /PATH/TO/bob/html/myscript.cgi)
will run as user bob, not as the default httpd user. (The
result is essentially what bob would get by logging into sdf and
piping to lynx the standard output of his script, a useful fact
that sometimes helps with debugging.)
The CGI engine on the MetaArray is fastcgi, which communicates
with the nginx web server over a UNIX socket. Unlike suEXEC and
suPHP (which run your scripts as if you were logged in at the shell),
fastcgi has a different model of privilege separation. As a result,
your scripts must end in the suffix '.cgi' in order for nginx
to know that a background process is responsible for generating
the actual HTML content.
Regardless of whether your website is hosted on the cluster or the
MetaArray, your scripts cannot run with greater privileges than your
user account. But all the languages available to you at the shell
are available for CGI scripting.
Users are encouraged to educate themselves and take resposibility
to ensure their web content is properly formed, secure and not
using excessive system resources.
Server Side Includes (SSI)
To make the server detect and process any SSI before delivering the
content to the client, you can simply use .shtml as the filename
extension. Alternatively, put the line "XBitHack on" in an htaccess
file at the root of your html directory, and turn on the executable
bit for any file that you want scanned for SSI commands (the "long"
directory listing would show the file with mode -rwxr-xr-x). The
latter method will make the server do more work than necessary
unless you manually unset the executable bit for files without any
SSI. (`mkhomepg -p` is not smart enough to tell the difference; it
sets the executable bit indiscriminately.)
Now that the server has native support for php, you are better off
creating dynamic content in that language rather than SSI.
Need to see php options? Create a file called 'test.php'
in your web directory, and put the line
phpinfo();
inside a block of php code (delimited by <php? and ?>)
Don't forget to run 'mkhomepg -p' afterwards to set the
proper permissions. Display results in web browser pointed
at "http://${YOUR_SDF_ID}.sdf.org/test.php".
More about CGI
CGI scripts ARE allowed. Giving a detailed tutorial is
beyond the scope of this FAQ; however, some rather
simple examples appear below. (Note: if you're viewing this FAQ
in a web browser, the sample code will not display correctly. See
the full code by logging in to SDF and typing `faq` at the shell.)
If you want to create a simple CGI, you don't need to use
PERL, you can do it the UNIX way in ksh! (p.s., PERL != CGI)
#!/bin/ksh
#
# My silly.cgi
#
echo Content-type: text/html
echo
echo "
my silly output"
echo "my silly hello world.
"
To create powerful CGIs, you can use OpenLISP on SDF, as illustrated
here:
#!/usr/pkg/uxlisp/uxlisp -quiet
;
; My powerful.cgi
;
(print "Content-type: text/html")
(print)
(print "my powerful output")
(print "my powerful hello world.
")
Or if you're more familiar with Python programming, the same result
can be obtained as follows:
#!/usr/bin/env python3
import cgi
print('Content-Type: text/html')
print()
print('my powerful output')
print('my powerful hello world.
')
As stated above, these scripts run with the privileges of the user
who owns them. The server-side execution of scripts is enabled by
default when your site is accessed through a vanity domain,
${YOUR_SDF_ID}.sdf.org. For sites accessed via a tilde-style URL,
like http://sdf.org/~${YOUR_SDF_ID}, you have to add a line in htaccess
for each filename extension that you want processed on the server.
(These handlers are turned off when the UserDir module is
used to navigate into your home directory.)
Consult the htaccess tutorial for the syntax of these directives.
When your site lives on the MetaArray, arbitrary filenames like
'MyPowerful.py' are harder to associate with the appropriate handler,
because nginx has a central configuration file (which can only be
updated by administrators), and no ability to delegate configuration
across per-directory htaccess files. The safest filename extension for
a MetaArray-hosted site is '.cgi', leaving it up to the fastcgi module
to scan the first line and determine which interpreter is needed.
Also note that the MetaArray doesn't seem to like serving up CGI sites
over insecure connections. After you decide on a vanity domain, or
toggle your hosting to the MetaArray, it might take a while for the
SSL certificates to be issued. Be patient, and try your CGI scripts
again when it becomes possible to connect over HTTPS.
------------------------------------------------------------