ImageMagick is installed, but scripts aren't able to access it

[Metro2]

I'm hoping that someone here has experienced this and can point me in the right direction.

I have a new server running WHM 10.8.0 / cPanel 10.9.0-R44 with the latest Fantastico release, RHEL 4, mysql 4.1.21-standard, PHP 4.4.4

Any script that uses ImageMagick (such as Gallery or Coppermine) gives errors related to ImageMagick as if it cannot access it. Photos cannot be uploaded, thumbs can't be created.

I have checked to make sure ImageMagick is installed, and safe_mode is OFF in php.ini.

I went through the debug / troubleshooting steps on a test Coppermine installation and I can't seem to find anything that indicates the source of the problem.

Does anyone know what I might be missing here?
Thanks very much!

 

[AndyReed]

I have checked to make sure ImageMagick is installed, and safe_mode is OFF in php.ini.

Did you install ImageMagick using /scripts/installimagemagick or manually from a *tar.gz file? Did you get any errors during the installation process? What version is currently installed? Make sure that the version you installed satisfy the nees of your Php applications. Run this command to find out:
/usr/bin/convert --version

 

[bunjo]

Is Ghostscript installed on your server? What is the output of rpm -qa | grep ghost ?

 

[codegirl42]

how do you install imagemagick using scripts/installimagemagick?

 

[Metro2]

Thank you for the replies!

Answers to your questions:

- I did not install ImageMagick. This was done by my data center, and they did my other server as well which does not have this problem.

- The version running is ImageMagick 6.0.7 08/16/06 Q16

- ghostscript 7.07 appears to be installed. A rpm -qa | grep ghost returns nothing at all.

Here is something that looks odd to me:

When I enter /usr/bin/convert --version it tells me I'm running ImageMagick 6.0.7 08/16/06 Q16

When I do a "locate delegates.xml" it tells me the file is in /usr/lib/ImageMagick-6.2.6/config/

Is it normal to see two different version numbers related to ImageMagick like that?

 

[bunjo]

- ghostscript 7.07 appears to be installed. A rpm -qa | grep ghost returns nothing at all.

Then it's not installed, and ImageMagick needs this to work. In WHM, go to Software - install a rpm and select ghostscript (about a third of the way down). Then reinstall ImageMagick. Ghostscript has to be installed before you install ImageMagick.

 

[Metro2]

Thanks bunjo, I installed the ghostscript RPM, re-installed the ImageMagick RPM (with a check mark next to force), restarted httpd and ran /scripts/upcp. Still no luck...

 

[Metro2]

RESOLVED! Heopfully this will help someone else someday:

Both Netenberg and my data center figured out the problem this morning. When I woke up there was an email from each of them alerting me that "exec" needed to be removed from the disable line in /usr/local/Zend/etc/php.ini

So when I changed this:
disable_functions = show_source, system, shell_exec, exec, passthru, popen, proc_open, copy

To this:
disable_functions = show_source, system, shell_exec, passthru, popen, proc_open, copy

All scripts that utilize ImageMagick began working properly.

In addition to that, Netenberg support mentioned that I should also remove system, shell_exec, passthru, and copy as well. I have removed copy, but I've been told that removing anything else is a security issue. So since things are working as they are now I think I'll leave it like this for now:
disable_functions = show_source, system, shell_exec, passthru, popen, proc_open
and see if any other problems come up.

I'd be interested to know if anyone has any opinions on that last bit about removing the other functions from the disable line in php.ini

So glad this is resolved! The strange thing is that over the past few years I've leased many cPanel/Fantastico servers and have never had to touch php.ini before to have ImageMagick work. Seems that all the ones before, including the second one I currently have at my data center, all came with "exec" and "copy" removed from the disable line already. I'm puzzled, but just very relieved right now.

Thanks for the input!

 

[akasharkbow]

Thanks so much!

Thanks for this! This was the exact problem I was having!

Cheers,

David J.

 

[sneader]

I think you've made your server less secure by enabling exec(). I believe best practice is to have it disabled. From reading on various hosting forums, most hosts have it disabled, or they have it enabled but also use other php security tactics to control the damage. Use Google to read up on the security concerns of exec(). I am not an expert on this topic, but have done significant reading. Also, for those that use Chirpy's cpanel setup service, he has that function disabled by default as well.

- Scott

 

[mtindor]

RESOLVED! Heopfully this will help someone else someday:

Both Netenberg and my data center figured out the problem this morning. When I woke up there was an email from each of them alerting me that "exec" needed to be removed from the disable line in /usr/local/Zend/etc/php.ini

So when I changed this:
disable_functions = show_source, system, shell_exec, exec, passthru, popen, proc_open, copy

To this:
disable_functions = show_source, system, shell_exec, passthru, popen, proc_open, copy

In addition to that, Netenberg support mentioned that I should also remove system, shell_exec, passthru, and copy as well. I have removed copy, but I've been told that removing anything else is a security issue. So since things are working as they are now I think I'll leave it like this for now:
disable_functions = show_source, system, shell_exec, passthru, popen, proc_open
and see if any other problems come up.

I'd be interested to know if anyone has any opinions on that last bit about removing the other functions from the disable line in php.ini

You have all of those disabled in disable_functions for a reason. Just about everybody who runs a hosting server ends up having to make up their mind whether or not they are going to disable particular php functions - they have to weigh what their userbase uses against security risks.

From all of my readings about Netenberg, it seems pretty common that they suggest that people just lessen their security to run Fantastico (or its addon scripts). That's ashame.

With that said, I also have one or two that I would _prefer_ to disable but I don't disable them because they would affect client scripts. But if a customer comes to me now and tells me that they need something else removed, I tell them to find another webhost then who doesn't care about security.

You really need to read up on what each one does and then make your decision after weighing risk vs benefit. Bottom line - disable everything you can without affecting customer websites and then remove anything that you must absolutely have to maintain the functionality your clients require.

If you aren't running mod_security _with a good set of rules like those which can be found at http://www.403security.org, be sure and do that... along with a good firewall like CSF. And if you aren't running suPHP, I'd highly suggest that you consider it. I'm of the opinion, and so are a lot of others, that to minimize your risk you have to approach it on many levels.

Mike

 

[akasharkbow]

This is all very good information, thanks so much! The problem on my server is exactly the same as Metro2's problem. I am using Gallery slideshow and even though ImageMagick works fine on it's own, Gallery can't access it because exec() was disabled.

Is there any known work around that will allow me to keep it enabled but still allow Gallery to use imagemagick?

Thanks so much!

David J.

 

[sneader]

You should be able to access ImageMagick through php classes. You can rebuild apache/php through EasyApache, and build in ImageMagick.

EDIT: Actually, I am wrong. This is not done via EasyApache, but rather via WHM > Software > Module Installers > PHP Pecl > Manage. Do a search for "imagick" then install it. Restart Apache via WHM for good measure.

But that won't help Gallery... as Gallery can only use IM via exec(). So, you'll have to tell Gallery to use GD.

- Scott

 

[akasharkbow]

BE could work but I was running into memory problems and 1/2 the thumbnails were not getting generated properly.

So what is the standard? How big of an issue is not having exuc disabled? Have I left open a huge hole?

Thanks again,

David J.