|Summary:||Debian 9 vs. Plack vs. /tmp -- attention to PrivateTmp for apache2|
|Product:||Koha||Reporter:||Janusz Kaczmarek <januszop>|
|Component:||Architecture, internals, and plumbing||Assignee:||Bugs List <koha-bugs>|
|Status:||RESOLVED DUPLICATE||QA Contact:||Testopia <testopia>|
|Priority:||P5 - low||CC:||jsterben, liz, mtj, philippe.blouin, pongtawat|
|Change sponsored?:||---||Patch complexity:||---|
|Text to go in the release notes:||Version(s) released in:|
Description Janusz Kaczmarek 2017-11-21 17:11:38 UTC
Beware: in Debian 9 apache2 comes with PrivateTmp enabled by default. As a consequence, there are issues when Plack is enabled for an instance, but in Koha there is an interaction between Plack enabled and Plack blacklisted stuff through /tmp directory. Plack-ed scripts will write temporary files in "real" /tmp directory (as pointed by Koha::UploadedFile::temporary_directory, i.e. File::Spec->tmpdir) whereas Plack blacklisted scripts will understand /tmp as private tmp of apache2, i.e. /tmp/systemd-private-?????????-apache2.service-????/tmp. This happens for instance for stage-marc-import.pl -- in step 2 the script won't find the marc file uploaded in step 1. The simplest instant solution to this would be to disable PrivateTmp for apache2 (this article gives a clue: https://www.maxoberberger.net/blog/2017/10/debian-9-private-tmp.html), but maybe there is a better option? (When Plack is disabled everything seems to work fine apart of the fact that the private tmp of apache2 is being used.)
Comment 1 Liz Rea 2018-02-08 23:22:34 UTC
For Debian Stretch (9), with plack enabled, you will need to do the following for the noted functions to work (as root or sudo, of course): #> vi /etc/system/multi-user.target.wants/apache2.service Change PrivateTmp:true to PrivateTmp:false #> systemctl daemon-reload #> systemctl restart apache2 #> systemctl show apache | grep PrivateTmp Result should be: PrivateTmp=no Ideal solution is to deal with the fact that when we fork the process, we can't read the old process's tempfiles, but this does solve the immediate problem.
Comment 2 Pongtawat 2018-07-13 15:15:07 UTC
*** This bug has been marked as a duplicate of bug 20428 ***
Comment 3 Blou 2018-07-26 12:31:00 UTC
Bug 20428 states that it's necessary for 18.05+ only, while we have had this issue with 17.05.06 (+custom). I thus applied Liz's fix with great success. I just wanted to specify that on MY Stretch, the file to modify is in vi /etc/systemd/system/multi-user.target.wants/apache2.service (note the /systemd/ that's different from Liz's solution). In case someone else needs this in the future. Big thanks.
Comment 4 John Sterbenz 2020-03-05 19:28:44 UTC
I second this big thanks. An OS upgrade to ubuntu 18.04 (koha 18.11) started a problem in which staging MARC records for load would upload the file but then cause failure after options were set and "Stage for import" was clicked ("Failed to submit form: error"). Bug 15032 seemed like the right place to start--it wasn't. Someone graciously pointed me here and this appears to be the fix I needed (with Philippe's directory modification).