Trac with fcgi wants to use /tmp and requires chmod +rwx

[bb]

When I run trac as an fcgi application it fails if it does not have read-access to the /tmp directory. I tried a lot of things to make it use a different temp directory, but none were of any avail. It would be great if you could at least change the location of the temporary dir. Changing the permissions of this directory just is not an option sometimes.

[osimons]

It likely needs the tmp directory to extract egg resources - the eggs are installed packaged (may be overridden using the easy_install --always-unzip option).

The location used to unpack is determined by PYTHON_EGG_CACHE env variable - at the beginning of your fcgi script, do:

import os
os.environ['PYTHON_EGG_CACHE'] = '/path/to/temp'
...

Try this for more information - it is a frequent issue: search:PYTHON_EGG_CACHE

Please report back.

[bb]

I tried every environment variable I could think of by setting it through lighttpd:

"bin-environment" => (...,
  "TMP" => "/trac",
  "TMPDIR" => "/trac",
  "EGG_TMP_DIR" => "/trac",
  "PYTHON_EGG_CACHE" => "/trac",
  "TEMP" => "/trac",
  "TEMP_DIR" => "/trac",
  "TMP_DIR" => "/trac",
  "TEMPDIR" => "/trac"
),

But nothing helped. Doing chmod a+r /tmp did help, though, but that is not exactly a viable solution for me. :/ at least, I'd very much like to do it differently.

(Severity changed to "blocker" as it prevents one from running trac altogether)

[cboos]

Replying to bb:

(Severity changed to "blocker" as it prevents one from running trac altogether)

Of course not, fcgi is simply one option among others, and this issue is only blocking you, not anyone using Trac. If for some reason you're having trouble with that deployment, try another way (TracModPython, TracModWsgi).

Besides, it seems quite odd that you're interfering with /tmp in that way. It's a place where anyone is supposed to be able to write, last time I looked... I guess you're preventing fcgi to use mktemp, but it's only a guess as I've never used fcgi myself.

This ticket is bordering on worksforme and local installation issue.

[bb]

Replying to cboos:

Replying to bb:

(Severity changed to "blocker" as it prevents one from running trac altogether)

Of course not, fcgi is simply one option among others, and this issue is only blocking you, not anyone using Trac. If for some reason you're having trouble with that deployment, try another way (TracModPython, TracModWsgi).

I figured that the severity was supposed to describe the effect of the bug (in this case it blocks me from running trac altogether) and that the priority was meant to describe how important that actually is, but I guess I understood it wrong. All my apologies.

Besides, it seems quite odd that you're interfering with /tmp in that way. It's a place where anyone is supposed to be able to write, last time I looked... I guess you're preventing fcgi to use mktemp, but it's only a guess as I've never used fcgi myself.

No, I am not interfering with /tmp, this is the default setup for Mandriva with security level set to "server". /tmp is chmod 773 so everybody can create their files just fine, they just can't see the list of temporary files (makes sense if you ask me, even for silly things like forgetting to make PHP store session files in a seperate dir to prevent session stealing, but ymmv). The lighttpd user (which runs the fcgi) can run mktemp just fine:

-sh-3.2$ whoami
lighttpd
-sh-3.2$ mktemp
/tmp/tmp.JIbAK10429

This ticket is bordering on worksforme and local installation issue.

I guess all I can say is that it's not even bordering on that, since this goes for all mandriva users who played with the security drop-down menu during the installation. It's not exactly local.

Actually, this is just like tracd wanting read permission on the /usr/bin directory, which is also denied in Mandriva for non-admin users. Why do you need read permissions on that?

[anonymous]

Replying to cboos:

Replying to bb:

(Severity changed to "blocker" as it prevents one from running trac altogether)

Of course not, fcgi is simply one option among others, and this issue is only blocking you, not anyone using Trac. If for some reason you're having trouble with that deployment, try another way (TracModPython, TracModWsgi).

What I forgot to address here is the assumption this is fcgi-specific.. are you sure?

[bb]

I now see I totally forgot to add the traceback I get when I do chmod 1773 /tmp. Here it is:

Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/trac/web/main.py", line 406, in dispatch_request
  File "/usr/lib/python2.5/site-packages/trac/web/main.py", line 191, in dispatch
  File "/usr/lib/python2.5/site-packages/trac/web/main.py", line 263, in _pre_process_request
  File "/usr/lib/python2.5/site-packages/trac/versioncontrol/api.py", line 73, in pre_process_request
  File "/usr/lib/python2.5/site-packages/trac/versioncontrol/cache.py", line 71, in sync
  File "/usr/lib/python2.5/site-packages/trac/db/util.py", line 51, in execute
  File "/usr/lib/python2.5/site-packages/trac/db/sqlite_backend.py", line 56, in execute
  File "/usr/lib/python2.5/site-packages/trac/db/sqlite_backend.py", line 48, in _rollback_on_error
OperationalError: unable to open database file

[rblank]

Replying to bb:

Actually, this is just like tracd wanting read permission on the /usr/bin directory, which is also denied in Mandriva for non-admin users. Why do you need read permissions on that?

Because /usr/bin/tracd is a script, not an executable. It must be readable so that it can be passed to /usr/bin/python for execution.

Is this still an issue with 0.11.1? You might want to look at the TracInstall#SettingupthePluginCache section to make sure Trac is not trying to write the egg cache to /tmp, as mentioned in comment:1.

[rblank]

The traceback in comment:7 seems to indicate that the exception comes from SQLite, and is due to temporary files created by the database. See:

http://www.sqlite.org/tempfiles.html

So this is probably not fcgi-specific. I'll try to see if the location of the temporary files can be configured.