[ SDF Public Access UNIX System .. Est. 1987 ]

join welcome faq status members store tour gopher abuse dialup minecraft social
tilde nihongo europa webmail gallery usermap irc tutorials telnet git ssh


     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
     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)

     # My silly.cgi
     echo Content-type: text/html
     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. ------------------------------------------------------------


©1987-2065 SDF Public Access UNIX System, Inc. 501(c)(7)
(this page was generated using ksh, sed and awk)