%s Error, can't open or read zdat files (CGI)

[kscheiderich]

Hi there,

I've got a site that uses multiple search pages. We have a log-in that sets up repository ID's associated with users, then our user_panel.php and search.php files reference which search page the user should be sent to and routes the zoom search that way. So there are different indexed sites within my site essentially.

I'm trying to set up some new repositories on my site (different search pages) and I'm getting an error when I try to search these new indexes. My old indexes work just fine and the new ones are set up identically so I can't track down the issue. I believe the old one's were originally created with zoom v5 enterprise (although they've been updated just fine using zoom v6 an v7). The new ones I've tried were first indexed using v6 and v7 enterprise and I get the same result. I get a garbled page with %s on the page title and a number of messages in the middle of the page if you scroll down referencing zoom config error, unable to open zdat files, etc. (see image below)

To reproduce error:
www.cabledocs.com
user: new
pass: test
Run any query

To see what the expected behavior is on a working search:
www.cabledocs.com
user: oldtest
pass: test
Run any query

If anyone can help me identify the root cause of the error it would be much appreciated so I can get this fixed. Thanks so much for any help at all!

Thanks,
Kevin

[David]

My guess is that your PHP script isn't actually executing the CGI.
Instead the PHP script includes the CGI file as if it was a text or HTML include file.

The CGI is a binary executable. So dumping it out as text in a browser will result in the garbage random text that appears in your screen shots.

I don't have access to your search.php script which I assume is meant to execute the CGI. So hard to know where it is going wrong.

[Ray]

There is an example in the FAQ here on how to properly include the CGI within a PHP script.
http://www.wrensoft.com/zoom/support...i.html#ssi_cgi

[kscheiderich]

Thanks for the info! Below are the contents of my search.php file. If you can take a look and see where it might be going astray it would be much appreciated. It's just weird, because it seems to execute the cgi just fine on my existing search pages. Only when I try to create new search pages do I have this issue. Do the search.cgi files generated from older versions of zoom need a different script method to execute the cgi files than ones generated from newer versions of zoom?

Thanks for any help you can give!


<?php
//ini_set('display_errors', 1);
include("include.php");
//include("lib/session.php");
require("lib/class/super_admin_class.php");
require("lib/class/user_class.php");
// ************** VSPL *****************************
$serach_keyword=$_GET['zoom_query'];
$username=$_SESSION['username'];
$repositry_id=$_GET['repository_id'];
$sql_search_stat="insert into search_stat (username, repositry_id, search_keyword) values ('$username', '$repositry_id','$serach_keyword')";
$query_search_stat=mysql_query($sql_search_stat) or die ("Stat Error".mysql_error());
// ************** VSPL *****************************


$user = new user;

$test=$user->get_user_by_repository_id($_SESSION['username'], $_GET['repository_id'], $link);

if (empty($_SESSION['gl_flag']) || empty($test)) {

$to_go = getHostUrl("user_login.php");

header("location:$to_go");

exit();

}

$admin = new super_admin;

$ud=$admin->get_repository_by_id($_GET['repository_id'], $link);

$uPath = $ud['directory_path']."/";

$cPath = "http://205.186.138.71/".$uPath."search.cgi?zoom_query=".str_replace( " ","%20",$_GET['zoom_query'])."&zoom_per_page=".$_GET['zoom_per_page']."&zoom_and=".$_GET['zoom_and']."&zoom_sort=".$_GET['zoom_sort']."&zoom_page=".$_GET['zoom_page'];
$cFilePath = $uPath . 'search.cgi';
//print_r($cPath);
//ob_start();
//passthru($cPath, $out);
//$data = ob_get_clean();
$ch = curl_init($cPath); // initialize curl handle
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
$data = curl_exec($ch);

//var_dump($data);
$data = preg_replace('/^.+\n/', '', $data);

$data=str_replace("https://www.cabledocs.com","http://www.cabledocs.com/display.php?repository_id=".$_GET['repository_id']."&file=",$data);
$data=str_replace("/sample/bin/pdf/",$uPath."pdf/",$data);
$data=str_replace("search.cgi?","https://www.cabledocs.com/search.php?repository_id=".$_GET['repository_id']."&",$data);
$data=str_replace("search.cgi","https://www.cabledocs.com/search.php?repository_id=".$_GET['repository_id'],$data);
$data=str_replace("[USER]",$_SESSION['username'],$data);
$data=str_replace('<input type="submit" value="Submit" class="zoom_button" />','<input type="hidden" name="repository_id" value="'.$_GET['repository_id'].'" /><input type="submit" value="Submit" class="zoom_button" />',$data);

print($data);
//var_dump($data);
?>

[David]

You are using a fixed IP address in the path, 205.186.138.71. Wouldn't a host name be better for long term maintainability.

I haven't tried using curl_exec before. Our recomended method of calling the CGI from PHP can be found on this page,
http://www.wrensoft.com/zoom/support/faq_ssi.html

I also seems you are calling a different copy of the CGI per repository. So maybe one of the copies is the wrong CGI version, or doesn't have file execute permissions set correctly.

[kscheiderich]

Yes, we have a different search.cgi file in each of the repository or search index folders. Can we just use one and reference that one search.cgi file for any index built?

When you say maybe one of the copies is the wrong CGI version, what do you mean by that? On two of my repositories I have search.cgi files that are dated 7/17/2009, and on another the search.cgi file is dated 12/23/2011. Both seem to work with those search indexes on the site with the current scripting. The new ones I'm trying to create I've tried using both zoom v6 and zoom v7. Is it possible I need to create these indexes using zoom v5?

In terms of the file execute permissions, the search.cgi file permissions are set to -rwxr-xr-x, 755. Is this correct?

Thanks!

[David]

When you say maybe one of the copies is the wrong CGI version, what do you mean by that?

We have 32bit and 64bit versions of the CGI.
We have Windows, Mac, FreeBSD & Linux versions of the CGI.
We have multiple versions of the CGI which correspond to the different releases of Zoom over the last 10 years.

For example the Windows CGI (which is a binary executable) won't run on Linux.
The 64bit CGI won't run on 32bit systems.
The V7 CGI won't work with V5 index files.
etc..

Do you have Telnet /SSH access to the machine. Can you run the CGI from the command line without error?

In your case it might be better to keep a separate CGI per set of index files.

[Ray]

In addition to the above, you should first diagnose the problem by checking the CGI directly, rather than through your script.

For example, the repository CGI's you have setup are at URLs like:
http://205.168.138.71/some_repository_id_path/search.cgi

(replace the path to whatever your script is actually using, stored within $ud['directory_path'] so we can't tell what it is)

You need to enter this URL into your browser and be able to get this working properly before you attempt to use any script to call it and capture its response, etc.

Right now, you should find the URL above (with the path specified) is returning the gibberish you are seeing. So it's not executing correctly.

Then the conclusions are simply either:
1) You are using the wrong CGI
2) The web server is not configured to run the CGI correctly and it's serving up the binary content of the executable.

My guess is the latter. Note that most servers are only configured to execute CGI's from some folders (usually "cgi-bin") so if you put .cgi files in other folders, even after granting it execute permissions, it will not execute properly and will behave like you see. You need to make sure the folders you are using are setup as "cgi-bin" folders on the web server configuration level.

[kscheiderich]

Thank you Ray! Your point #2 was the culprit "2) The web server is not configured to run the CGI correctly and it's serving up the binary content of the executable."

Fixed the problem by adding an .htaccess file that allowed cgi execution in the desired directory.

Again, thanks for your amazing support! You guys have a really great product with zoom!