4

I'm trying to get exiftool to work on my dedicated server. The issue is that PHP exec seems to run different than when a command is run as a user. Oddly enough, PHP shows up as the same user I log in with, but it does not behave the same with system commands.

Oddly enough everything works great on my localhost, but not on my server.

So as mentioned, running exiftool commands logged in via ssh is fine.

But running in a php testing script (note I've installed exiftool on each tested directory, and it runs through ssh), nothing is accessible, though it runs as user orangeman...

And it fails

Here is an update - having been on this all day:

On the shell:

-bash-4.1$ which exiftool -a
~/perl5/bin/exiftool
/usr/bin/exiftool
~/perl5/bin/exiftool

In PHP shell_exec('exiftool -a');

/usr/bin/exiftool

And here is what that file links to:

lrwxrwxrwx    1 root root          33 May 15 02:10 exiftool -> /home/orangeman/perl5/bin/exiftool

I've also tried creating symlinks of various sorts, tampering with the main $PATH variable via putenv(); in php ... I'm truly in the dark here. Works on localhost, not on dedicated server.

I've updated this with a bounty - its a serious issue in development.

I'm on a dedicated server, and the problem is as outlined above.

UPDATE Per @gcb suggestion, I was able to print out the error that is occurring when php's exec() function runs the system command with no effect.

PHP

<?php
exec('exiftool 2>&1', $output, $r);
var_dump($output, $r);
?>

Output:

array(2) {
  [0]=>
  string(230) "Can't locate Image/ExifTool.pm in @INC (@INC contains: /bin/lib /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at /bin/exiftool line 33."
  [1]=>
  string(59) "BEGIN failed--compilation aborted at /bin/exiftool line 33."
}

UPDATE

@gcb's solution worked. Thank you very much.

Orangeman555
  • 1,179
  • 2
  • 21
  • 45
  • Is php in a chroot? Does it have permissions to actually see those directories? – Zoredache May 14 '14 at 19:06
  • 'which php' returns '/usr/local/bin/php'. I'm not familiar with a 'chroot' but if that is a possibility what would be a work-around? – Orangeman555 May 14 '14 at 19:08
  • You would put the files/programs you need inside the chroot. As for what it is, see the wikipedia entry. http://en.wikipedia.org/wiki/Chroot – Zoredache May 14 '14 at 19:11
  • `/usr/bin/exiftool` is not a directory. `/usr/bin` is a directory, while `/usr/bin/exiftool` (if it exists) would be a file. – that other guy May 14 '14 at 19:17

4 Answers4

5

So you do not have a php problem now, but a perl one. your include path is bad.

Answer here.

You either have to install the ExifTool libraries in the
standard location (ie. somewhere in the @INC directories
listed in your post), or add the location to the include path,
something like this:

Code:
#!/usr/bin/perl
BEGIN { unshift @INC, "PATH_TO_DIRECTORY_CONTAINING_LIBRARIES" }
use Image::ExifTool;

You should be able to add "Image/ExifTool.pm" to the path you add
to find the ExifTool module.

- Phil

I still think using my suggestion #3 from the previous answer will fix it. If not and you really want to know the reason, create a new perl script that just outputs the contents of @INC and run it via the shell and via php. you will see the difference, then you need to find which login script is not being honored in php and open a bug against php for shell_exec not respecting it...

though the easier solution for your problem (as it does not look like you are too interested in explanations) is to just set the PERLLIB var before calling the script.

So, just do:

  1. find / -name ExifTool.pm This will tell you where the lib is installed. let's say this returns /example/perl/Image/ExifTool.pm
  2. append PERL5LIB=/example/perl/ to your exec() call.
  3. exec("PERL5LIB=/example/perl/ /var/www/myscript/execscript.sh {$param}"); #and
konsolebox
  • 72,135
  • 12
  • 99
  • 105
gcb
  • 13,901
  • 7
  • 67
  • 92
  • "...as it does not look like you are too interested in explanations" ... not so! I'm very interested. I've been on this almost a week. This seems like the most likely answer. I'm inspecting it now. I unzipped in a temp directory and run the "make" ... assuming it would install properly. Apparently it did not install in the standard way. I've been researching that this morning based on your observation. I'm not experienced in perl at all, so this has been slower for me. – Orangeman555 May 18 '14 at 20:23
  • @Orangeman555 thanks. about learning, i honestly do not think you should have to learn perl to solve this. if you want to improve, learn linux (file system structure, file permission, stdout vs stdout i.e. buffers and streams, and about one shell or another, i suggest bash) and learn about your chosen work environment (php, apache, i'm assuming) learn where to search for error logs, etc. eventually you will see that everything follows the same pattern and it gets easy :) cheers. – gcb May 18 '14 at 23:22
2

0) you should look on your error log. usually under /var/log/apache/error

it will have messages such as "access denied" or something else.

1) you are clearly not getting enough output of that command to see any error. so try to run it with exiftool 2>&1. this will redirect stderr to stdout, so errors will appear on the output. not sure if that is relevant or php already does that. you may also want to use passthru instead of exec

2) safe-mode exec dir

your file may be out of your safe mode exec dir. read this up:

http://www.php.net/manual/en/ini.sect.safe-mode.php#ini.safe-mode-exec-dir

3) all else fails, run the command as a login shell, which should have the same scripts loaded as when you login in via ssh. just replace exec with shell_exec

...i'm pretty sure looking at the error log will solve your mistery.

gcb
  • 13,901
  • 7
  • 67
  • 92
  • I'm checking your suggestions now. Will get back to you - thank you very much. – Orangeman555 May 18 '14 at 04:22
  • WONDERFUL suggestion. I've updated the original post with the results. I didn't know how to get error logs out of shell, so that is huge progress. Now we see its throwing an error that we obviously do not get when logged in via the shell, so what is this showing? – Orangeman555 May 18 '14 at 04:28
1

One possibility is that on the command line, your $PATH had been set/modified by both your $HOME/.bashrc and your $HOME/.bash_profile because your command line is a log-in shell. When PHP is invoked by the Web server, it runs as "orangeman" BUT only as a shell, not a log-in shell, so its $PATH may not be the same, which is what you're seeing here. Have you tried putting export PATH="what:you:want:your:PHP:path:to:be" in your $HOME/.bashrc?

aqn
  • 2,542
  • 1
  • 16
  • 12
  • I had tinkered with that - I'm not sure I did it right. Should this be done the PHP script while its running, or is there a perminant way to set this for the system? – Orangeman555 May 15 '14 at 02:58
1

I believe this is happening because you have a private installation of perl for you user.

Basically @INC is an array which perl uses for locate its library, and it does not contain the path for your installation library.

There are a couple of ways to change @INC which you can find on the below link:

http://perlmaven.com/how-to-change-inc-to-find-perl-modules-in-non-standard-locations

I hope this helps.

Tiago Lopo
  • 7,619
  • 1
  • 30
  • 51