Request Tracker 3

[Colin Walters]

On Mon, 2005-01-31 at 13:16 -0500, Kanwar Ranbir Sandhu wrote:

> In RT, you can define a separate log file instead of having everything
> dumped to /var/log/messages.  I haven't tried yet, but I'm assuming if I
> disabled the separate log file, this error would disappear.
>
> I would rather keep /var/log/rt.log.  It makes reading the log a lot
> easier since it will only contain messages pertaining to RT.

Right.  Can you try moving the log into /var/log/httpd?  I can't think
of another solution short of installing the policy sources and adding
the permissions.  My guess is that it is actually this permission that
is stopping the program; the others are likely harmless.

> Actually, it's just /tmp.  

Is your /tmp a symlink elsewhere?  Or do you actually have a symlink
in /tmp named "tmp"?  Are you *sure* it's really /tmp?  Do an 
"ls -di /tmp" to see if its inode number is 12.  Then do 
"ls -di /usr/tmp".

> FastCGI dumps its temporary files there while
> it's running.  The location can be changed, but in the past (on FC1)
> when I've tried using /var/log/httpd/fastcgi, I just get a bunch of
> errors about FastCGI not having permission to write to that directory (I
> believe the only way I managed to fix that was by changing permissions
> on /var/log/httpd to 777).

Better to use an ACL than mode 777; e.g. 
"setfacl -m 'apache:rwx' /var/log/httpd".

> The command you mentioned above won't work in this case, will it?  I'm
> assuming that context is meant only for directories under /usr.

It only changes the type of the /usr/tmp symlink.  My guess is still
that your program has some code (or a library it uses does) that
tries /usr/tmp first, and is getting permission denial on that symlink
because it should be usr_t, not tmp_t.