[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 ""
     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 "")
     (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('')
     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.
     ------------------------------------------------------------