** Using WeBWorK **

I'm baffled by this. I have a new RedHat server, running Apache 1.3.34, and a shiny new WeBWorK install out of the CVS repository. When I try to generate a hardcopy of a set, I'm getting the errors

     * Failed to convert TeX to PDF with command 'cd
/var/www/webwork/webwork2/courses/ma115-001/html/tmp/hardcopy/work.qL0FU0qa 
&& 
/usr/bin/pdflatex --shell-escape >pdflatex.stdout 2>pdflatex.stderr hardcopy'.
[etc.]

The server's error_log is recording the errors

Use of uninitialized value in concatenation (.) or string at (eval 
930) line 1.
sh: line 0: cd: 
/var/www/webwork/webwork2/courses/ma115-001/html/tmp/hardcopy/work.qL0FU0qa: 
Not a directory

But if I look at it, this certainly appears to be a directory. (I can cd into it, file says it's a directory, and I can run the pdflatex command there manually without any trouble.) So I can't figure out why the cd command is failing. The directory tree to that directory is all accessible to the webserver, and the hardcopy.tex file is being created correctly. And the pdf generating command is failing on the cd; if I put in a command before that, e.g., env > /tmp/httpd.env && cd ..., the first command runs fine (and doesn't point out any obvious errors in the environment of the httpd daemon).

If anyone can shed light on this, that'd be great.

Thanks,
Gavin

<| Post or View Comments |>

No idea on this one. :-)

The last time something inexplicable happened on Red Hat it was due to selinux restrictions on the httpd user.

Any chance of figuring out where (eval 930) line 1 is?
-sam

<| Post or View Comments |>

For having no idea, you've given me exactly what I needed. The problem turns out to be selinux. The policy boolean httpd_disable_trans was set to 'disable'; toggling that to 'enable' results in things working.

It may be worth noting that the selinux throws some policy error to its audit log when httpd starts when the httpd_disable_trans policy is set to 'disable'. Had I checked that I might have had a clue about this earlier. Ideally I'll figure out a more scientific (and, possibly, secure) way around this (or, even better, get our systems guys to do so) at some point. However, in the meantime I at least have a work around.

Thanks, again,
Gavin

<| Post or View Comments |>

This is a different hardcopy problem but I thought I'd put it here rather than starting a new thread.

We just updated WeBWorK from CVS, and everything so far seems to work fine, except that when I request hardcopy of an assignment, I get an error message:

1 error occured while generating hardcopy:

* Failed to remove temporary directory '/opt/webwork2/courses/mn06spr1352/html/tmp/hardcopy/work.OlwtgJp7':

/bin/rm: cannot get current directory: Permission denied

A hardcopy file was generated, but it may not be complete or correct:

When I click on the link "download hardcopy", the resulting pdf file seems to be all correct.

I've gone through the global.conf.dist file and can't find anything relevant. There's no more information in the apache log files. File permissions look OK.

Thanks, Bob

<| Post or View Comments |>

<| Post or View Comments |>

After hardcopy generation is complete, WeBWorK attempts to remove the temporary directory in which the PDF was compiled. This error indicates that it was unable to do so.

What operating system are you running?

Does the temporary directory actually exist after hardcopy runs?

What are its user, group, and permissions, and the user, group, and permissions of the enclosing directory?

Do you have any additional access control in use, such as ACLs or SELinux?

If you log in as the web server user, are you able to delete it manually?

<| Post or View Comments |>

Thanks for the rapid response. Here's the information you're asking for:

I. What operating system are you running?

The Mandriva 10.2 (free version) release of Linux. (When it's time to upgrade, I think we're going with something else. Suggestions welcome.)

II. Does the temporary directory actually exist after hardcopy runs? What are its user, group, and permissions, and the user, group, and permissions of the enclosing directory?

Yes it exists. Its user and group are apache:wwdata. The web server is running as user apache, group apache. User apache is a member of the group wwdata (as verified by "id apache".)

Here's a directory listing from one of these directories (ls -l):

drwxr-sr-x  2 apache wwdata  4096 Jan  7 10:45 work.8wpO3NtB/

All ancestors in the directory tree up to (but not including) /opt are owned by apache:wwdata and have permission drwxr-sr-x except for /opt/webwork2, which has permission drwxrwsr-x.

III. Do you have any additional access control in use, such as ACLs or SELinux?

As near as I can tell, SELinux is not active. We haven't explicitly set up ACLs either. The apache server we're using was compiled locally, not the one from the distribution.

IV. If you log in as the web server user, are you able to delete it manually?

Yes.

I can't think of other relevant information. Hardcopy generation worked fine until the upgrade (modulo the timezone problem noted in a different post).

Thanks for your help.

Bob

<| Post or View Comments |>

This problem of being unable to determine the current working directory occurs in at least one other place. When a pg file with math fonts is loaded for the first time, we get the warning message:

Can't fetch initial working directory at /opt/pg/lib/WeBWorK/PG/ImageGenerator.pm line 68

The other possible place where this is biting us is when someone tries to get hardcopy of a pg file that uses the image function to load an external gif file. The new pipeline scheme fails, but doesn't give an informative error message. On-the-fly graphics generated by WeBWorK still work.

Although we back up database and course data daily, I foolishly didn't back up our working copy of WeBWorK before doing the upgrade, otherwise we would just fall back. Our last CVS upgrade was done in late September and fixed some previous problems we were having, otherwise I would just re-install a previous named version. (If there's an incantation for getting that version back from the CVS repository, please let me know! I see I need to learn more about CVS.)

Incidentally, on our emergency backup machine (a smaller, slower machine running Mandrake 10.1) there are no problems like the ones described. I suspect Mandriva 10.2 is the source of our problems, but with classes starting this is not a great time to make a change.

I "corrected" the problem with temp file removal by commenting out the command to remove the temporary files in the delete_temp_dir function in Hardcopy.pm (we can remove temporary files with a cron job) but this doesn't help the graphics problem, which is more serious. (Anyway, making local changes to WeBWorK source is probably not a great idea.)

I'll be grateful for any suggestion!

Bob

<| Post or View Comments |>

Try adding this into a WW module (for example, in place of the command to remove the temporary files in delete_temp_dir in Hardcopy.pm):

use Cwd;
warn "Current working directory is: ", getcwd(), "\n";

Then try generating some hardcopy. You should get a warning message at the bottom of the page (or at least in the Apache error log) listing the working directory.
-sam

<| Post or View Comments |>

Use of unitialized value in warn at /opt/webwork2/lib/WeBWorK/ContentGenerator/Hardcopy.pm line 541

in the error log for Apache. When I take out the getcwd() parameter to warn this goes away, but I get the rest of the parameters to warn.

If the problem is in Apache, I suppose it won't hurt to recompile Apache. (We need to upgrade to 1.3.34 anyway.) If I can concentrate this weekend (after scheduled dental surgery tomorrow) I'll try this.

Thanks,

Bob

<| Post or View Comments |>

It looks like the Apache process doesn't have a working directory set, which doesn't make sense to me. You might try looking at Mandriva's Apache init script, and see if any funny business is going on in there.
-sam

<| Post or View Comments |>

Thanks for your suggestions. I'm about to give up on this one, though. I've reviewed the WeBWorK install/update instructions. I've carefully checked file ownership/permissions, global.conf, webwork.apache-config, httpd.conf, and the apache start-up script (just the stock apachectl). I've also tried re-compiling apache and re-installing WeBWorK from CVS. Nothing seems to make a difference.

I, and some other people on this campus, have noticed some other apparent quality-control issues with Mandriva 10.2. I'm wondering if this isn't the problem here, maybe something funny about their perl package.

Of the problems mentioned, the only one we can't live with is the problem of hardcopy generation of pg files loading gif files. I observed that if external graphics files are png files, things work fine. (Apparently the gif to eps conversion tries to create some temporary files somewhere. There is a message to this effect in error_log.) The most time efficient solution for us is to convert gif to png and edit the pg files. (Shouldn't take too long using sed.) Then when the semester is over, we'll replace Mandriva with something else. I gather Rochester uses Debian?

Thanks again for your help.

Bob

<| Post or View Comments |>