Can't get ghostscript running

OnoSendai

Hi folks,Can you help me?I can't get ghostscript running to generate pdf-previews. In administration / configuration it says it can't find ghostsript.Problem is probably due to us not using a proper server but a NAS (a Synology Diskstation DS412+) .. it's a small Museum with small budget. :/ (Though so far everything has been working fine.)I've downloaded the binaries of ghostscript and had tried to change the path in external_applications.conf to its respective location as well as I've tried to just put the binaries to /usr/bin/gs.Both didn't work.Can this be due to the usage of a NAS and / or to using binaries of ghostscript?edit: Besides just throwing the binaries on the NAS, I now also got ghostscript properly installed through synology's ipkg package service. I can open ghostscript in console with the command 'gs', yet CA still can't find it.edit #2: I've installed other tools too, to narrow it down. ImageMagick and pdftotext (xpdf) work fine on the NAS (can start from console), but CA still won't find them even though I've adjusted the correct path to their binaries in external_applications.conf. Do I need to reload the conf-file somewhere perhaps? Rebooting the NAS doesn't help.  Greetz!1. EDIT: SOLUTION FOUNDFor those, who might have similiar problems, our problem here was due to a faulty setup of CA_BASE_DIR in setup.php and a missing entry of open_basedir in php.ini, where I had to add the folder of binaries of ghostscript and other plugins, so that php can access it.2. EDIT: FINAL REMARKI would not recommend using a NAS for installing CA on it. The very basic things (like apache and mysql) work flawlessly, but once you want to add more functionality to it, you would likely run into problems due to the different architecture of the NAS. I've turned an old PC into a Server and installed CA on that, works like a charm.

stefan

Well, the user that runs the web server has to be able to execute the binaries. Maybe there's some restriction in place that forbids this? Also, the webserver/PHP setup has to allow exec() calls from PHP scripts. 

There's no need to reload the configuration. It should go into effect right away (if the file mtime changes, we flush the cache for that particular config file).

OnoSendai

Hi Stefan,Thanks for your reply. I've copied the binaries into the CA-folder itself and even chmoded their permission to 777; But still didn't work. So this excludes the possibility of faulty permission-settings, right?Now I'm looking up how to check for the PHP setup and exec() calls-issue. Never worked with that before. Any quick hints perhaps?edit:Forgive me, if this is a silly way to test (I don't have any experience in PHP or server-setup so far).But I've tried executing a PHP exec() call with the following script:<?phpecho exec('pwd');?>which responded correctly. And if I try <?phpecho exec('/opt/bin/convert');?>it answers with ''-' for standard input or output.'That means, the web-application can call PHP exec()s, right?Thx & Greetz

seth

Try using exec to call gs. My bet is that there are resource limits preventing gs from running in the web server context. 

OnoSendai

I changed it to this:<?phpecho exec('/opt/bin/gs -dSAFER -dBATCH -dNOPAUSE -sDEVICE=png16m -dGraphicsAlphaBits=4 -sOutputFile=test.png test.pdf ');?>And it worked perfectly. Resulted in a small png of respective pdf, in the folder web (Which is the NAS' folder for web applications and in which CA is installed too).It also worked fine if I changed the executed binaries to those within the folder of CA, like /volume1/web/S_CA/S_plugins/gs (a temporary folder).I've more than tripple checked by now whether I got the path correct in external_applications.conf and executed the binaries etc.Besides, ImageMagick is installed properly but is said to be missing by CA too.Can I check CA's priviliges somewhere?

stefan

This is what CA does to check if ImageMagick is installed:

exec($ps_imagemagick_path.'/identify 2> /dev/null', $va_output, $vn_return);

if (($vn_return >= 0) && ($vn_return < 127)) {

return true; // yup, is installed

}

return false; // nope

Where $ps_imagemagick_path is the config setting. 

CA doesn't have privileges. It's a set of PHP scripts run by a web server. The user that runs the web server executable has privileges but you seem to have ruled out that those are off. I don't know what's going on. The idea of running CA on a NAS is very intriguing though!

stefan

Ah, one more thing:

How did you run your PHP test scripts? Through the web server or the command line interpreter? There's a big difference because they're usually separate setups with separate sets of config files. Try it via web server if you haven't yet, i.e. place the script in the web root and navigate to it via browser. 

seth

Also check what the return value is in your test. They're supposed to be certain values but they're not always standardized and perhaps it's returning a value outside of the range we're expecting on the NAS.

OnoSendai

Was off for the weekend, here we go again.@Stefan: Yes, I called the php-script through the browser. After opening the script, the png file is being created in the root web folder and the tab calling the script is stuck (I guess because gs is running and awaiting further commands, right?). @Seth: In the browser it returns the last line, which is:Page 1Calling it through command line it returns:DiskStation> /opt/bin/gs -dSAFER -dBATCH -dNOPAUSE -sDEVICE=png16m -dGraphicsAlphaBits=4 -sOutputFile=test.png test.pdf GPL Ghostscript 8.71 (2010-02-10)Copyright (C) 2010 Artifex Software, Inc.  All rights reserved.This software comes with NO WARRANTY: see the file PUBLIC for details.Processing pages 1 through 1.Page 1DiskStation> I just noticed, it is ghostscript 8.71. Could this be the cause? I used to install ghostscript through synology's own package manager on the NAS, which is 'ipkg'. There they must have the old version in their repos. I'm trying to install the new version of ghostscript now.edit: I've changed the gs binaries in /opt/bin/ to the newest version, but to no avail. Results are exactly the same: can call the script through browser, same png-picture produced, same return values (which state the new version though) ...

stefan

gs 8.71 should work. We recommend 9 but it should still work.

Try running a "/opt/bin/gs -v 2> /dev/null" and check the return value afterwards (echo $? in bash). That's what CA does to determine if ghostscript is installed. If the value is >= 0 and < 127, it should be detected.

OnoSendai

Okay, did it; and that's the output:DiskStation> /opt/bin/gs -v 2> /dev/nulGPL Ghostscript 8.71 (2010-02-10)Copyright (C) 2010 Artifex Software, Inc.  All rights reserved.DiskStation> echo $?0DiskStation> So, it recognizes it? edit: @stefan: Sorry, I noticed just now your reply from before, where you posted a script for testing for ImageMagick. I somehow overlooked that.So, after executingexec('/opt/bin/identify 2> /dev/null', $va_output, $vn_return);echo $vn_return;I get 0in the browser.edit2: Don't know if it's a connected issue, but when I upload a jpg to CA by typing in the IP in the browser, a preview is generated and displayed. When I do the same through our DynDNS, the jpg is uploaded successfully but without a preview. Also, calling the php-script for testing (where I've pasted the codes above into) works only via IP, but not through DynDNS. (The CA-install works through both, IP and DynDNS)

stefan

Yeah, it should be detected. No idea why it isn't. The detection code is really simple.

It's unlikely that your second problem is related but you never know. How does it look when the jpg is uploaded without preview? Is the file still processed okay and the previews are just not being displayed? Do they show up when you navigate to the same record via IP afterwards? And what exactly happens when you try to access your test script via DynDNS?

Also, does this mean your NAS is on the internet? Or are you using DynDNS to resolve a local hostname?

Lots of questions :-)

OnoSendai

jpg-preview: I've attached two screenshots. One showing the missing preview via DynDNS (but once I click on the picture it shows it maximized), and the other one showing the preview via IP. And it's the same behavior regardless of whether I upload the jpg via IP or DynDNS. It's just the preview via DynDNS which is missing, otherwise it seems to work correctly.

Accessing test-script via DynDNS: My bad about that, I tried it again and it works. I must have typed a wrong URL before. Sorry for the foolish mistake. -.-

NAS on the internet or using it to resolve to local hostname... Sorry, what do you mean by 'NAS on the internet'? A colleague of mine has setup the web-server on the NAS. We use it to resolve to our current IP, so I guess it's the second option of what you asked for. Don't know if that answers your question though.

stefan

Ok so it's processed correctly but for some reason the image URLs are off. While that's certainly ugly and should be fixed, it has nothing to do with the original problem where your ghostscript and imagemagick are not being detected correctly.

In your PHP test script you have 

exec('/opt/bin/identify 2> /dev/null', $va_output, $vn_return);echo $vn_return;

and you get a return val of 0, which should mean it ought to be detected. All we do is check the return value. Is your external_applications.conf set like this?

imagemagick_path = /opt/bin

The only other thing I can think of is that for some reason your external_applications.conf is not readable or somehow fails to parse without giving an error message. Or do you by any chance have a external_applications.conf in app/conf/local? That one would override the one in app/conf.

Also, I noticed your UI is in German. Can I ask which museum you're working for? We're always psyched about new users here in Germany (I'm in Berlin) ;-)

OnoSendai

The external_applications.conf has these lines:ghostscript_app = /opt/bin/gsandimagemagick_path = /opt/binHere you can have look at it:http://pastebin.com/V2yPwERv and its path is this:/volume1/web/S_CA/app/conf/external_applications.confthe test-script file is here:/volume1/web/S_test.phpSo both are definitely under the same parent-directory (Don't know if that's important though).But I've just noticed something else: I got other CA-installs in the web folder as well:/volume1/web/ca/volume1/web/ca2Both were used for testing. Perhaps they interfere somehow?? I'm backing them up right now and will delete them once done to exclude that possibility as well. Though I've replaced already their external_applications.confs with the one from my working CA-install (S_CA) which got the /opt/bin paths. No change though. And in all three of the CA-installs there are no files in /app/conf/local.edit: Deleted the sql-databases and the other two CA-installs; nothing changed.Where the heck can the fault be? Shall I try a fresh install? Shall I sacrifice a goat for the IT-gods?As for where we are: Austria also speaks german. ;) More precisely, I'm working in Freistadt, near Linz, Oberösterreich:http://www.museum-freistadt.at/ Liebe Grüße und Danke für den guten Support. ;)

OnoSendai

One more thing:I tried opening the test script in the folder of CA and copied it into /app/conf and tried to call following URL through the browser:http://10.0.0.101/S_CA/app/conf/S_test.php (With the IP being our intern IP of course).It didn't work and the web-server said it couldn't find it (no 404 though, see screenshot 1.png)But if I create another folder in web and place it there it works. http://10.0.0.101/test/S_test.php (see screenshot 2.png)Thought I don't know if that's anyhow connected, I'm just trying out everything....

OnoSendai

I've attached a screenshot of the CA-configuration page; because it seems odd to me that it says available at PDFWand but at the same time, that it can't find ghostscript. Also the CA version:Application version 1.4Schema revision 97Release Type GITif that's of any help

stefan

Okay, a few things:

Clearing out lingering CA installs will certainly help with your sanity but they shouldn't interfere unless they use the same database.

Executing a script from app/conf won't work because there's a .htaccess file in there that prevents direct access for everything in that directory. Otherwise you could pull up the configuration files as plain text in a browser.

The PDFWand plugin is always available because we actually don't need any external tools to do very basic PDF processing. The tools (ghostscript, pdftotext) are all optional.

I can't really think of anything else to try right now. Sacrificing a goat might not be a bad idea. 

I created a small test script myself that pretty much mimics what CA does to figure out if gs is installed and prints a couple of things. Can you try putting this in the CA root and running it via browser? Here's the github gist: https://gist.github.com/skeidel/78e94bfb9528e91db6d2</div><div> </div><div>My guess is that caIsValidFilePath for some reason returns false in your case.

OnoSendai

Thanks for the clarification about other CAs, .htaccess and the goat.As for the script, there is some weird behavior: It doesn't print out anything at all, because it gets stuck at every command (the require.. $po.., $pe... line 3 - 8) before the first if. I've 'debugged' it by stating print-commands before and after every command. The prints after the commands didn't get executed (unless of course I commented out the respective commands).I'm googling about potential problems of faulty PHP-execution on NAS now.edit: Here's the php-info file about the setup on the NAS, if that's of help:http://tinyurl.com/n4chfql update: I digged into debugging in PHP and managed to display the following error:Warning: require_once(./setup.php): failed to open stream: No such file or directory in /volume1/web/S_test.php on line 6 Fatal error: require_once(): Failed opening required './setup.php' (include_path='.') in /volume1/web/S_test.php on line 6update2: I changed relative path require_once(./setup.php); to absolute require_once('/volume1/web/S_CA/setup.php'); and it worked for finding the setup.php. Now though it displays following error:Warning: include_once(./themes/default/views/system/configuration_error_html.php): failed to open stream: No such file or directory in /volume1/web/S_CA/setup.php on line 235 Warning: include_once(): Failed opening './themes/default/views/system/configuration_error_html.php' for inclusion (include_path='.') in /volume1/web/S_CA/setup.php on line 235 Fatal error: Configuration files are missing for hostname '10.0.0.101'! Please check the CA_BASE_DIR configuration setting in your setup.php file.It seems that relative paths don't work well. Logically, once again I changed the relative path in this warning to the absolute one and then I got these (two broken images were included there as well):

An error in your system configuration has been detected

General installation instructions can be found here. For more specific hints on the existing issues please have a look at the messages below.

Configuration files are missing for hostname '10.0.0.101'!Please check the CA_BASE_DIR configuration setting in your setup.php file.

We seem to get closer.... I'll check further.update3:Ok. A problem seems to lie with the initial configuration and the path-definition of CA. I'm following this thread here:http://www.collectiveaccess.org/support/forum/?p=/discussion/519/problem-with-setup-php-many-thanks-for-your-help Before I had in my setup.php these lines:define("CA_BASE_DIR", pathinfo(preg_replace("!/install|/viewers/apps!", "", $SERVER['SCRIPT_FILENAME']), PATHINFO_DIRNAME));# define("CA_BASE_DIR", "/volume1/web/ca/");Notice the /volume1/web/ca/ That's the old installation of said colleague who did the initial setup. I didn't see that line to change. Now I changed it to:#define("CA_BASE_DIR", pathinfo(preg_replace("!/install|/viewers/apps!", "", $SERVER['SCRIPT_FILENAME']), PATHINFO_DIRNAME));define("CA_BASE_DIR", "/volume1/web/S_CA/");Now I got:ghostscript path from external conf: /opt/bin/gsWarning: file_exists(): open_basedir restriction in effect. File(/opt/bin/gs) is not within the allowed path(s): (/usr/local/bin/CoreImageTool:/var/services/tmp:/etc.defaults:/usr/bin/php:/usr/syno/synoman:/etc:/var/run:/volume1/@tmp/php:/var/services/web:/var/services/photo:/var/services/blog:/var/services/homes:/var/services/web/ca:/volume1/web/ca/app/tmp:/usr/bin/mediainfo:/usr/bin/ffmpeg:/usr/bin:/usr/bin/gm:/usr/local/bin) in /volume1/web/S_test.php on line 15 ghostscript path doesn't existI'll try to fix it further, but I'm leaving the office right now. Let's see if I can get to it later again.

stefan

The automatic CA_BASE_DIR detection is a little quirky in custom scripts sometimes. I'm used to that by now and usually set it by hand (like you did) and forgot to mention it. Sorry about that. The script was just a quick hack.

If you can edit the PHP config, try to either remove open_basedir or add /opt/bin to the list (see http://php.net/manual/en/ini.core.php#ini.open-basedir). This is most likely the root cause of your problem. 