Re: [greenstone-users] Using a remote Greenstone forbuildingcollections

From Michael Dewsnip
DateTue, 20 Dec 2005 16:45:12 +1300
Subject Re: [greenstone-users] Using a remote Greenstone forbuildingcollections
In-Reply-To (438C7701-8000304-argon7-be)

I've finally managed to have IIS installed here; this was surprisingly
difficult because the university doesn't like IIS installations because
of their security issues.

I've been able to get gliserver running with IIS, at least from the
browser (I'll do some more testing in the future). I didn't encounter
your problem but I did encounter some that Stefan reported:

- gliserver needs to be renamed to, in order to associate
Perl with it
- gsdlCGI constructor needs to be changed as Stefan describes

(I will look at creating a version of gliserver that works with both
Apache and IIS).

Here's what I did to configure IIS (v5.1):

- Created a new Virtual Directory called "gsdl" for "E:\Program
Files\Greenstone", "Read" and "Browse" only
- Open gsdl, right-click on "cgi-bin", choose Properties. Create
Application called "Greenstone", click Configuration, remove all
extensions. Add extension for ".pl": "E:\Program
Files\Greenstone\bin\windows\perl\bin\perl.exe" "%s" %s (quotes are very
important here).

Compare this against what you've done and hopefully you'll find the
cause of your problem.



Argon7 List User wrote:

> Thanks for your tips...
> 1) I've changed the call to the gsdlCGI constructor as you suggested,
> but nothing changed... :o(
> 2) Concerning perl and module crypt::unixcrypt, I can't see any error
> messages in IIS logs (I don't know where I'm able to see if
> returns such an error)... the only thing that i see is
> this "502" error..
> Even the gli-client tells me:
> "gliserver args: cmd=download-collection-configurations
> Server returned HTTP response code: 502 for URL:
> http://<mydomain>/gsdl/cgi-bin/
> at
> at
> org.greenstone.gatherer.remote.RemoteGreenstoneServer.downloadFileInternal(
> at
> org.greenstone.gatherer.remote.RemoteGreenstoneServer.downloadFile(
> at
> org.greenstone.gatherer.remote.RemoteGreenstoneServer.access$400(
> at
> org.greenstone.gatherer.remote.RemoteGreenstoneServer$RemoteGreenstoneServerDownloadCollectionConfigurationsAction.perform(
> at
> org.greenstone.gatherer.remote.RemoteGreenstoneServer$"
> but when I run the script directory on the command line, it does not
> complain about anything: i receive messages telling me that no "cmd",
> "un" and "pw" has been specified. I even tried with
> "cmd=download-collection-configurations" + a valid un and pw: it
> worked, and I received a lot of data in which I recognised stuff from
> my collection.
> so, my script seems to be ok...
> i've re-(re-)check my IIS server and can't see anything wrong about
> its configuration... i'm lost... :o(
> I even placed a very simple script in the gsdl/cgi-bin
> directory and tried to access it thru a web-browser: no problem at all!
> What else can I check?
> Thanks for your help...
> -- J:o(
> Stefan Boddie wrote:
>> Hi,
>> Do you get a message like the following?
>> ---
>> CGI Error
>> The specified CGI application misbehaved by not returning a complete
>> set of HTTP headers. The headers it did return are:
>> Can't locate Crypt/ in @INC (@INC contains: C:/Perl/lib
>> C:/Perl/site/lib .) at
>> C:\...\gsdl\cgi-bin\ line 7.
>> BEGIN failed--compilation aborted at C:\...\gsdl\cgi-bin\
>> line 7.
>> ---
>> I just tried to run under IIS5 and that's what I got.
>> That is, the UnixCrypt module was missing from my perl installation.
>> I'm using ActiveState's ActivePerl so I used their package manager to
>> install Crypt-UnixCrypt. That solved the first problem.
>> The next problem was that the script seemed to go into a loop and
>> never return when I ran it. I eventually found that it was configured
>> to be run from the command line, and was waiting forever for input
>> from STDIN. I'm not sure if this is just a problem with the CVS
>> snapshot I have or if it'll affect you too. If it does you should
>> edit and replace the line near the top of the file that
>> reads
>> my $gsdl_cgi = new gsdlCGI("+cmdline");
>> with
>> my $gsdl_cgi = new gsdlCGI();
>> Once I did that it seemed to run ok, and I could at least get it to
>> complain when I sent it bogus arguments in the URL. I'm not really
>> sure what gliserver is meant to do, so I haven't tested it any
>> further than that. Perhaps someone who knows more about it can help
>> you out.
>> Regards,
>> Stefan.
> _______________________________________________
> greenstone-users mailing list