PHP script not executing pdflatex - php

I have a PHP script which accepts data from an incoming POST request, downloads the data to a file, and then runs a shell script. Only some parts of the shells script are executed --- don't know why. The request is
https://knode.work/processLatex.php
where the body is the JSON {data: SOURCE} and SOURCE is LaTeX source text. Here is the PHP script:
<?php
$post_data = $_POST['data'];
if (!empty($post_data)) {
$dir = '/var/www/html/files/';
$file = 'foo';
$filename = $dir.$file.'.tex';
$handle = fopen($filename, "w");
fwrite($handle, $post_data);
fclose($handle);
chdir($dir);
exec("sh texit.sh");
echo("Done!!");
}
?>
And here is the shell script:
/usr/bin/pdflatex foo.tex
/usr/bin/pdfatex foo.tex
rm yuuk.txt
rm *.out *.log *.aux
The /usr/bin/pdflatex lines are not executed, but the other lines are. What the heck? Are not all lines equal?
((Could there be a permissions problem?))
Below is a listing of the ./files directory. I created foo.pdf by running pdflatex foo.tex as root.
-rw-r--r-- 1 root root 207383 Aug 13 17:31 foo.pdf
-rw-r--r-- 1 www-data www-data 11372 Aug 13 18:35 foo.tex
-rw-r--r-- 1 root root 84 Aug 13 17:40 texit.sh
So perhaps the problem lies in the ownership of foo.tex versus that of pdflatex (re comment below) by RiggsFolly. Here is the dope on pdflatex:
lrwxrwxrwx 1 root root 6 Aug 21 2017 /usr/bin/pdflatex -> pdftex
Also, I set everything up as root, e.g.,
drwxr-xr-x 6 root root 4096 Aug 13 18:36 html
What should I do?

Related

Search & replace issue on mPDF, CAM'PDF on Ubuntu 18.04

On Ubuntu 18.04 I have a problem with editing PDF files - specifically search & replace strings.
I tried:
PHP mPDF Overwrite () do nothing.
perl CAM :: PDF 1.60 changepagestring.pl do nothing
sed, do nothing.
Does not work with compressed or decompressed PDF, Does not even work with PDF generated from mPDF.
UPDATE: after reinstalling libsodium mPDF works fine with PDF files generated fromm mPDF. For other PDF files issue still exist.
Also tried in var / www folders user / group www-data: www / data and in other folders / home e.g.
Any idea for bulk search & replace because I have over 1000 files to process?
The text in the files is readable. Check.
P.S. Search / Replace from the program and online service works with the same files.
Permission on files 0755 i 0777
root#sasa-ubuntu-1:/var/www/website.local/wp-content/test/2018/12# ls -la *.pdf
-rwxr-xr-x 1 www-data www-data 847451 Oct 18 12:21 clean.pdf
-rwxrwxrwx 1 www-data www-data 395527 Oct 17 21:41 My-First.pdf
-rwxr-xr-x 1 www-data www-data 838307 Oct 17 23:30 My.pdf
-rwxr-xr-x 1 www-data www-data 838167 Oct 18 12:24 New2.pdf
-rwxr-xr-x 1 www-data www-data 838167 Oct 18 01:20 New.pdf
-rwxrwxrwx 1 www-data www-data 270340 Oct 17 16:39 Test2.pdf
-rwxrwxrwx 1 www-data www-data 274022 Oct 17 16:39 Test1.pdf
-rwxr-xr-x 1 www-data www-data 838000 Oct 18 00:55 Test2.pdf
-rwxrwxrwx 1 www-data www-data 205679 Oct 17 23:44 test.pdf
Perl script allways return "Could not find title" nevermind of readability of file when I print $page variable (see images)
use CAM::PDF;
my $pdf = CAM::PDF->new('test.pdf'); # existing document
my $nump = $pdf->numPages();
#print $nump;
my $page = $pdf->getPageContent(1);
print $page;
# $page now holds the uncompressed page content as a string
# replace the text part
if ($page =~ s/Wagner/SoundTech/g) {
$pdf->setPageContent(1, $page);
}
else {
die "Could not find title\n";
}
$pdf->cleanoutput('Test2.pdf');
A lot of files ends on this way.
The string that I try to find is "Wagner International Music Examinations" or only "Wagner"
mPDF and CAM-PDF are properly installed without warnings and erros and with all dependencies, I hope.
Ubuntu 18.04
mPDF version 8.0
PHP 7.2
Perl 5.26.1
CAM-PDF version 1.60
mPDF occasionally have bug with Overwrite() function, I found on their github community.
Any suggestion or another way for bulk search & replace in PDF files?
Here is a hack that currently works almost for your case (I will come back later and try improve this):
use feature qw(say);
use strict;
use warnings;
# the PDF uses a non-standard encoding so it does not help to use UTF-8
# use open qw(:std :encoding(UTF-8));
use utf8;
use CAM::PDF;
my $fn = 'test.pdf'; # uncompressed file..
my $save_fn = 'test2.pdf';
my $pdf = CAM::PDF->new($fn);
my $nump = $pdf->numPages();
my $match = 0;
my $replace = '[(\x{a9} SoundTech International Music Examinations)]TJ';
for my $i (1..$nump) {
my $page = $pdf->getPageContent( $i );
# replace the text part
if ($page =~ s/\[\(\x{a9}\).*?\]TJ/$replace/g) {
$match = 1;
$pdf->setPageContent($i, $page);
}
}
if ( $match ) {
$pdf->cleanoutput($save_fn);
say "Save $save_fn ..";
}
else {
say "No match";
}

PHP is listing files with readable permissions but cannot file_get_contents or require_once

It is a Drupal site, where includes/module.inc runs a loop over files in the registry and attempts require_once(). For a number of files this is failing, even though the file permissions are correct and the file should be readable.
I've added debug code to the loop to output to check file perms and contents:
// Debug code
print "$file perms:" . substr(sprintf('%o', fileperms($file)), -4) . "<br>";
print "$file contents:<br>" . htmlspecialchars(file_get_contents($file)) . "<hr>";
// Original Code
require_once $file;
It outputs the file permissions as well as well as the file contents before attempting the require_once. Different pages are failing on different files, the homepage for instance is outputting:
./sites/default/modules/cck/includes/content.token.inc perms:0755
./sites/default/modules/cck/includes/content.token.inc contents:
[filecontent]
./sites/default/modules/filefield/filefield.token.inc perms:0644
./sites/default/modules/filefield/filefield.token.inc contents:
[filecontent]
./sites/default/modules/getid3/getid3.install perms:0644
./sites/default/modules/getid3/getid3.install contents:
[NO FILE CONTENT]
So for some reason ./sites/default/modules/getid3/getid3.install allegedly has the permission to be readable, but isn’t.
Different paths show different files as being problematic:
/
./sites/default/modules/getid3/getid3.install perms:0644
/admin
./sites/default/modules/webform/components/date.inc perms:0644
/user
./sites/default/modules/cck/includes/content.crud.inc perms:0755
EDIT:
Note above that ./sites/default/modules/cck/includes/content.token.inc is readable but ./sites/default/modules/cck/includes/content.crud.inc gives error, here's the directory listing for those files (including --context to check for SELinux)
# ll --context
total 168
drwxr-xr-x 4 root root ? 4096 Sep 28 05:50 ./
drwxr-xr-x 8 root root ? 4096 Nov 6 2013 ../
-rwxr-xr-x 1 root root ? 72264 Nov 6 2013 content.admin.inc*
-rwxr-xr-x 1 root root ? 26307 Sep 28 03:13 content.crud.inc*
-rwxr-xr-x 1 root root ? 7181 Nov 6 2013 content.devel.inc*
-rwxr-xr-x 1 root root ? 3868 Nov 6 2013 content.diff.inc*
-rwxr-xr-x 1 root root ? 15914 Nov 6 2013 content.node_form.inc*
-rwxr-xr-x 1 root root ? 12550 Nov 6 2013 content.rules.inc*
-rwxr-xr-x 1 root root ? 6246 Nov 6 2013 content.token.inc*
drwxr-xr-x 3 root root ? 4096 Nov 6 2013 panels/
drwxr-xr-x 3 root root ? 4096 Nov 6 2013 views/
The modified date of crud is me commenting the code for testing after the errors occurred, but it is back to as it was now.
EDIT 2:
It seems that trying to access robots.txt directly is also forbidden. Not sure if this is the same problem, but again the file looks like it should be perfectly readable.
# ll robots.txt
-rw-r--r-- 1 6226 6226 1521 Aug 6 18:07 robots.txt
EDIT 3:
Looks like the problem was AppArmor, which I suppose is similar to SELinux. Changing from aa-enforce to aa-complain resolved the issue.
Perhaps some selinux cmd like might get this running :
semanage fcontext -a -t httpd_httpd_sys_content_t '/var/lib/myapp(/.*)?'
restorecon -R -v /var/lib/myapp
Where /var/lib/myapp is your ./ directory
Looks like the problem was AppArmor, which I suppose is similar to SELinux. Changing from aa-enforce to aa-complain resolved the issue.

Run phantomjs from php

I;m trying to run phantomjs from php. To check correct path and permissions, as first I execute this commands:
$output = shell_exec('ls /opt/phantomjs-1.9.2-linux-x86_64/bin/ -l');
echo "<pre>$output</pre>";
Result:
-rwxrwxrwx. 1 root root 38526976 Sep 7 11:17 phantomjs
drwxrwxrwx. 2 root root 4096 Feb 10 15:44 savedpages
-rwxrwxrwx. 1 root root 803 Jan 19 18:36 saveonepagelin.js
-rwxrwxrwx. 1 root root 4074 Jan 19 19:00 test.js
But when I run:
$output = shell_exec('/opt/phantomjs-1.9.2-linux-x86_64/bin/phantomjs --version');
echo "<pre>$output</pre>";
Output is empty :( why? Thanks!
My first guess would be a permission problem. Is the www-data user (or whichever user your server is called) allowed to run the program?
Do you get anything returned if you place $output in var_dump() instead?
I.e.
$output = shell_exec('/opt/phantomjs-1.9.2-linux-x86_64/bin/phantomjs --version');
var_dump($output);
I got the same error, and I try to modify the dir where I execute the phantomjs and set the mode with 777, then it worked. I guess the root cause if the owner of the php-fpm doesn't have right to write image into the dir.
my code for refer:
$output = passthru('phantomjs echarts-convert.js -options ' . $options . ' -outfile line.png');
echo $output;

fopen clears file instead writing

I'm trying to write into a text file via PHP. My problem is that PHP always just clears the file instead of writing in it.
$fp = fopen('status.txt', 'w+');
fwrite($fp, "test");
fclose($fp);
I guess this depends on some permission issues. But I can't figure out what to change. At the moment the permission of the PHP file is:
-rwxrwx--- 1 www-data www-data 1980 Feb 18 11:25 test8.php
the permission of textfile is:
-rwxrwx--- 1 www-data www-data 0 Feb 18 11:25 status.txt
I'm using apache2 on my Raspberry Pi. The PHP script and the text file are stored in Apache main directory /var/www/

mkdir fails in the /tmp directory

I'm trying to create a folder in php and the code kind of fails each it is used with /tmp/... as path:
exec("mkdir -p /tmp/test/ 2>&1", $output, $return_code);
// $output is empty, $return_code is 0
//mkdir("/tmp/test/"); // Alternative to above
is_dir("/tmp/test/"); // returns true
is_readable("/tmp/test/"); // returns true
But if i check the /tmp-Folder there is no such directory and all subsequent write or read operations on the folder fail, because the folder does not exist. The permissions for /tmp are correct (root:root with 777) and i can do sudo -u http mkdir -p /tmp/test without problems. If I use tmp/test for example, the code will run fine and create a folder within the directory of the php-skript (Which lies in a folder which belongs to me, not the http-user ... )
Any ideas as to why php fails to create a folder under /tmp/ but reports it as being there?
Edit:
To specify read- and write-actions: Those actions are not from within my own script, but rather external skripts which get called by the php-script to execute different tasks. Once all of them succeeded, the folder gets zipped and copied somewhere else.
Edit:
Right after running exec("mkdir -p /tmp/testfolder");
[daishy#littlezombie tmp]$ pwd
/tmp
[daishy#littlezombie tmp]$ ls -al
insgesamt 8
drwxrwxrwt 21 root root 440 3. Aug 18:56 .
drwxr-xr-x 20 root root 4096 10. Jun 16:49 ..
drwxrwxrwt 2 root root 40 3. Aug 09:42 .font-unix
drwxr-xr-x 2 daishy users 60 3. Aug 14:40 hsperfdata_daishy
drwxrwxrwt 2 root root 60 3. Aug 09:42 .ICE-unix
drwx------ 2 daishy users 60 3. Aug 12:35 kde-daishy
drwx------ 2 daishy users 140 3. Aug 18:49 ksocket-daishy
drwx------ 3 root root 60 3. Aug 18:54 systemd-private-5rIfGj
drwx------ 3 root root 60 3. Aug 09:42 systemd-private-HGNW9x
drwx------ 3 root root 60 3. Aug 09:42 systemd-private-od4pyY
drwx------ 3 root root 60 3. Aug 09:42 systemd-private-qAH8UK
drwxrwxrwt 2 root root 40 3. Aug 09:42 .Test-unix
drwx------ 4 daishy users 80 3. Aug 16:55 .Trash-1000
-r--r--r-- 1 root root 11 3. Aug 09:42 .X0-lock
drwxrwxrwt 2 root root 60 3. Aug 09:42 .X11-unix
drwxrwxrwt 2 root root 40 3. Aug 09:42 .XIM-unix
Edit:
As it turns out, this is not a problem with php, but rather with systemd / apache. In short: systemd creates a private tmp-folder for apache while running, which resides under /tmp/systemd-private-XYZ. So the real /tmp is not viewable by the php-skript, but rather the private one.
See http://blog.oddbit.com/post/private-tmp-directories-in-fedora for more infos.
As it turns out, this is not a problem with php, but rather with systemd / apache. In short: systemd creates a private tmp-folder for apache while running, which resides under /tmp/systemd-private-XYZ. So the real /tmp is not viewable by the php-skript, but rather the private one.
To disable this behavior, you can set PrivateTmp=false in /usr/lib/systemd/system/httpd.service
See http://blog.oddbit.com/2012/11/05/fedora-private-tmp/ for more infos.
Don't do that. Use PHP's awesomely called function, tmpfile(). From the docs:
$temp = tmpfile();
fwrite($temp, "writing to tempfile");
fseek($temp, 0);
echo fread($temp, 1024);
fclose($temp); // this removes the file

Categories