Setting environment variables for cgi/fcgi scripts


#1

Hi –

I’m having trouble getting shared libraries to load in my Ruby CGI scripts, and I’m pretty sure it’s because the LD_LIBRARY_PATH variable is getting stripped out of the environment by the web server for “safety” reasons. (Everything works just fine if I run things as stand-alone scripts without the right environment variables.) Unfortunately, setting ENV[“LD_LIBRARY_PATH”] in the Ruby process itself before attempting to load the shared library appears to be “too late”…it needs the environment variable set correctly before the Ruby process starts, or it doesn’t work at all.

Question: how do I either (1) keep LD_LIBRARY_PATH from getting stripped out – I’m guessing this is not actually possible without superuser privileges – or (2) create a wrapper [f]cgi script that sets the enviornment variable correctly before forwarding the request to the “real” [f]cgi script? (Or if there are any other ways of working around this @#$% “security” measure, I’d love to hear them…)

Thanks,

– Scott


#2

For future reference, here’s how I worked around the issue:

  • Rename dispatch.cgi to, say, dispatch2.cgi
  • Create a new dispatch.cgi that looks something like this:

#!/bin/sh
LD_LIBRARY_PATH="/your/path/here:/another/path"
export LD_LIBRARY_PATH
exec dirname $0/dispatch2.cgi ${1+"$@"}

A similar solution appears to work with dispatch.fcgi.

One glitch that tripped me up before I arrived at the above: at first I called my wrapper script “dispatch_env.cgi”, had it exec my original “dispatch.cgi”, and modified .htaccess to call dispatch_env.cgi. DON’T do that: there seems to be some special-casing done by the web server to handle scripts with base names of “dispatch”, because having .htaccess call a script with a different name causes other environment variables to be set in slightly different ways that may mess up any URLs generated by your “real” script by making them relative to your wrapper script.