Jim's Depository

this code is not yet written

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 -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; 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/

3:14am, spring daylight savings time day. The church bells across the street have been ringing for 14 minutes.

After my dismal failure at Pohmelfs, I shopped for alternative distributed files systems. I can’t tell if CODA is abandoned or not, but I’ll give it a try.

  1. Build into kernel 2.6.33, no problems.
  2. Debian has let their user mode utilities rot away.
  3. CMU has prebuilt .debs, including for Squeeze. That looks good.
  4. Add the CMU apt sources, looks like this now… # cat /etc/apt/sources.list.d/coda.list deb http://www.coda.cs.cmu.edu/debian lenny/
  5. aptitude update ; aptitude install coda-server, scary text about unsigned packages follows, but it is OK.
  6. Configure server with vice-setup
  7. Similar for the client machines, except aptitude install coda-client… ends with 00:35:02 Venus starting… 00:35:02 /coda now mounted
  8. Test client with CMU’s server: # cfs lv /coda/testserver.coda.cs.cmu.edu Status of volume 7f000000 (2130706432) named “/” Volume type is ReadWrite Looks good. I can read the sample documents.
  9. Test client with my server: Much hanging and server not founding. Most likely related to my “hostname” being an internal address unreachable by the client. There is a spot in the /etc/coda/*.conf file and in one in the /vice directory, but it still attempts to use the unreachable address and no hints in vice-setup on how to force an address.
  10. I temporarily change my hostname to the external interface address. No luck. The client does a pile of DNS lookups for SRV records for my host with _codasrv._udp prepended, then does one for a regular A record. Gets my address, but never tries to contact.
  11. Reboot client. Success! Now we can connect. Something evil must have been cached.
  12. Many failures to authenticate with clog until I realize that the example I’m working from only has an account of admin because that is what they gave vice-setup. Use the account I gave with the password “changeme” and I’m in.
  13. Find cpasswd, change that password.
  14. Try to make myself a user account. au -h MYHOST nu, coda is a pretty hostile system. It echoes my new password in the clear even though it knows how not to, then fails with AuthNameToId() --> AUTH_FAILED
  15. Find pdbtool. Use it to make my account from the server side, but I can’t see how to set the password. Go back and try au from a client, and now I can set my password.
  16. Notice I have no group. Use pdbtool to make a group with my name, program explodes with an assert failure. That’s going to be a problem.
  17. Unpack a linux kernel on the client. It flew until arch/arm, not it is crawling along at about 1 file per second. No load on server, no load on client, no load on network, just glacial progress.
  18. Abandon Code!

Coda is badly documented, user hostile, and not robust.

I do not trust it.

I’ve enjoyed reading zbr’s blog postings about POHMELFS and the Elliptics network for years. With POHMELFS in the staging directories of Linux 2.6.33 and me needing to share some files across several machines, it is time to try it out.

  1. Build myself some fresh new 2.6.33 kernels with POHMELFS enabled.
  2. Look for a HOWTO of sorts, fail.
  3. Check the server out with git: git clone http://www.ioremap.net/git/pohmelfs-server.git
  4. Follow the included README
  5. Fail, install autoconf.
  6. Fail, finally discover that --with-kdir-path=<mylinuxsourc>/drivers/staging/pohmelfs/ is the right answer.
  7. Fail, install libssl-dev.
  8. make
  9. make install
  10. Copy /usr/local/bin/cfg over to the client machines.
  11. Make a new filesystem to export mounted on /jim.
  12. Start the server: fserver -r /jim
  13. Go to a client machine:  #cfg -A add -a -p 1025 -i 1 # mount -t pohmel -o idx=1 none /jim Killed
  14. That isn’t good. dmesg reports there is a null pointer reference in the kernel.
  15. Find two patches that will be in related to “bdi” and not having a real backing device. Add them and make a new kernel.
  16. Fail, badly. Please remember to change your version number in the kernel make file, lest you also forget the init ramdisk and make an unbootable system.
  17. Success! With these patches I can now mount my pohmelfs partition! Unpacking a linux source tree is pleasently quick.
  18. Failure! Chowning the source tree fills dmesg with things like…  pohmelfs_insert_hash: exist: parent: 856, ino: 879, hash: 9f4b42c5, len: 14, data: ‘README.syncppp’, new: ino: 37643, hash: 9f4b42c5, len: 14, data: ‘README.syncppp’. Chown silently and slowly fails.
  19. Unmount and remount. Now chown hangs after a small amount of progress. No messages in dmesg this time. No changes make their way to the server.
  20. I’m beginning to think Pohmelfs is not ready for me.

I will go shopping for other distributed file systems.