[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 "<title>my silly output</title>"
    echo "<h3>my silly hello world.</h3>"

    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 "<title>my powerful output</title>")
    (print "<h3>my powerful hello world.</h3>")

    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('<title>my powerful output</title>')
    print('<h3>my powerful hello world.</h3>')

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

You are viewing proxied material from sdf.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.