Jim's Depository

this code is not yet written
 

Setting up nginx and lua fastcgi on Debian Squeeze

The available pages I can google about this seem overly complicated. This one documents setting up nginx to run lua scripts on Debian Squeeze. These instructions are derived from http://www.unreliablepollution.net/p/other/howto-nginx-and-lua and a dozen remedial googleings.

  1. aptitude install nginx
    The config in /etc/nginx is good in squeeze. We will need to add the fastcgi handler, but that is to be expected. (I edited it to pull the root up to /var/www instead of in an nginx-default subdirectory.)
  2. aptitude install liblua5.1-wsapi-fcgi-1
    There is also a ‘0’ version, but I took 1 on the theory that newer is better.
  3. aptitude install liblua5.1-coxpcall0
    liblua5.1-wsapi-fcgi-1 probably needs a dependency on this. Things will go poorly for you without it.
  4. aptitude install lua5.1
    Can’t forget that.
  5. aptitude install spawn-fcgi
    Older instructions talk about libfastcgi-dev, but it isn’t available and I think they just wanted spawn-fcgi out of it anyway.

  6. Put a Lua file in /var/www/hello.lua
    The WSAPI is a little strange. Apparently you don’t just print your output, but rather coroutine.yield() it. I used this example program from http://keplerproject.github.com/wsapi/manual.html …

    module(…, package.seeall)

    function run(wsapi_env) local headers = { [“Content-type”] = “text/html” }

    local function hello_text() coroutine.yield(”<html><body>”) coroutine.yield(”<p>Hello Wsapi!</p>”) coroutine.yield(”<p>PATH_INFO: “ .. wsapi_env.PATH_INFO .. “</p>”) coroutine.yield(”<p>SCRIPT_NAME: “ .. wsapi_env.SCRIPT_NAME .. “</p>”) coroutine.yield(”</body></html>”) end

    return 200, headers, coroutine.wrap(hello_text) end

  7. spawn-fcgi -a 127.0.0.1 -p 9100 -F 4 -- /usr/bin/wsapi.fcgi
    Now we have handlers on port 9100. This will need to be in /etc/init.d/blahblahblah but this will do for now.
    Note: spawn-fcgi silently fails if you get the command wrong. Do a “ps” and make sure they are there. You will have a section like this if it succeeds…
    18554 ?        Ss     0:00 lua5.1 /usr/bin/wsapi.fcgi
    18555 ?        Ss     0:00 lua5.1 /usr/bin/wsapi.fcgi
    18556 ?        Ss     0:00 lua5.1 /usr/bin/wsapi.fcgi
    18557 ?        Ss     0:00 lua5.1 /usr/bin/wsapi.fcgi

  8. Edit /etc/nginx/sites-available/default to know how we want .lua files handled. I put in this section
    location \~ \^(.+\.lua)(.*)\$ { root /var/www/; fastcgi_pass 127.0.0.1:9100; fastcgi_index index.lua; fastcgi_split_path_info \^(.+\.lua)(.*)\$; fastcgi_param PATH_INFO \$fastcgi_path_info; fastcgi_param SCRIPT_FILENAME \$document_root\$fastcgi_script_name; include fastcgi_params; } Be careful! Make ‘root’ match your root!

  9. Restart nginx. /etc/init.d/nginx restart

  10. Load http://YOURSERVER/hello.lua in your browser. You should get something along the lines of:

    Hello Wsapi!

    PATH_INFO: / SCRIPT_NAME: /hello.lua

  11. Celebrate!

Now my thoughts: This may be more than I wanted. I have to think about the implications of a scrutinizer layer above my Lua program. I really wanted to just blast my standard output back up the fastcgi socket. All this yielding seems strange.

Very strange indeed.  I still don't understand why every Lua implementation (except for luasp.org) seems to be done backwards. Why doesn't anyone try to take the php approach and allow web designers to work on designing instead of doing strange script-fu just to use Lua?
For anyone else who stumbles across this, I found a better solution: http://www.marmottus.net/blog/2012/03/25/nginx-and-lua/