[greenstone-users] Re: One more thing

From Anupama of Greenstone Team
DateThu Mar 25 14:57:51 2010
Subject [greenstone-users] Re: One more thing
In-Reply-To (63CB844B15B0D142BF448D6925EFE4AB08EE9A17-mermoz-st-etienne-archi-fr)
Hi Arnaud,

Thanks for the updated plugin, I will ask permission to commit it to
svn. I am sure it will be a helpful addition for other users as well.


> Here I had an error related to a X java environment variable not set.
As I
> wanted to launch my web server on an headless server I launched the make
> web-start command instead.

In fact, you can launch the gsicontrol.sh script to do the same. From
your Greenstone installation folder, type the following in an x-term:

1. source setup.bash
2. ./gsicontrol.sh web-start


> I had to add my client IP to allow directive in httpd.conf for this
to work.
> By default the httpd.conf.in authorizes only a local connection (well, I
> could have changed the httpd.conf.in too) and client GLI returned a 403
> response.
>

Some information you may find useful concerning this:

1. When you run the GUI version of the Greenstone Server Interface (GSI)
by launching gs2-server.sh, the GSI dialog has a File > Settings menu
that contains 4 options for server host address resolution. Besides
localhost and 127.0.0.1, it also has the option of your machine's
hostname and its specific IP number.
The same dialog also has a tickbox for "Allow external connections".
Ticking this will give access to more than the client machine of course.

2. gs2-server.sh is a Java shell that actually just runs the appropriate
commands in the gsicontrol.sh script. So you can run the same as (1)
above from the command-line too, by running the gsicontrol.sh script
(which interacts with the apache web server by modifying the httpd.conf
file by regenerating it from the httpd.conf.in template).

- If you run ./gsicontrol.sh (with no arguments) it displays the
commands publicly available. There's one or two hidden, but you can run
the hidden command "./gsicontrol.sh set-port" which will call the
internal configure-port-and-connection function, and this will allow you
to specify the HOST machine's port and IP, as well as turn on or off the
"Allow External Connections" to set which clients can access the machine.

- Alternatively (and this may be the better solution), you could modify
the "llssite.cfg" file in your toplevel greenstone installation to
specify the host machine IP and turn on/off the Allow External
Connections option. The relevant lines in llssite.cf are:

externalaccess=0
address_resolution_method=0
hostIP=aaa.bbb.ccc.ddd

"Allow External Access" is turned on by setting externalaccess to 1

Address resolution method:
0 for getting local IP and resolving to a hostname. For this, specify
the hostIP property in llssite as well
1 for local IP
2 for localhost
3 for 127.0.0.1

hostIP - here you can specify the IP number of the host. This will be
used in conjunction with the address_resolution_method property,
particularly values 0 and 1. (127.0.0.1 is included by default)

What you need to know is that the hostIP and externalaccess properties
in llssite.cfg modify the contents of the httpd.conf file that is
generated from the httpd.conf.in template, by changing the following
lines at the bottom of your
<your-greenstone2>/apache-httpd/linux/conf/httpd.conf.in file:

Order deny,allow
**CONNECTPERMISSION** from all
Allow from 127.0.0.1 **HOST_IP**

If you turn externalaccess of, it becomes:
Deny from All
Allow from 127.0.0.1. **HOST_IP**

So I think that if you modify the hostIP= line in llssite.cfg to contain
the hostIP AND client IP (separated by spaces) then it may perhaps have
the effect you desire.

However, before you make any changes, ensure the apache web server is
stopped.

Also note that if you ever want to use GLI on the server side, you'll
want to modify glisite.cfg as well to match those three lines in
llssite.cfg, if you want the same behaviour when GLI launches
gs2-server.sh. That's because GLI uses glisite.cfg as the config file to
launch gs2-server.sh/GSI with.


Regards,
Anupama


arnaud yvan wrote:
> Hi Anupama,
>
> thanks again. I thank your supervisor too, the Greenstone Team and the whole
> world of free and opensource software for this sharing philosophy is one of
> the greatest things I know :-)
>
>
>> I forgot an important set of steps in my previous email to you, which I
>> am inserting to the old list of instructions below (marked with !!!).
>> Please try the following:
>
>> 1. Go to the machine running the server and stop the Greenstone server.
>
>> 2. Now (still on the server machine) open the file
>> <your-greenstone-folder>/apache-linux/linux/conf/httpd.conf.in
>
>> 3. Look for the line specifying "PassEnv"
>
>> 4. Change the line to:
>> PassEnv **LIBRARY_PATH_VAR** LANG
>
>> The above passes your server's LANG environmnent variable onto your
>> Apache web server, so that the web server should now behave the same way
>> as your terminal when it comes to the language encoding.
>
>> !!! 5. Now delete the file
>> <your-greenstone-folder>/apache-linux/linux/conf/httpd.conf
>
>> !!! 6. Use a terminal to run:
>> - source setup.bash
>> - ./gsicontrol.sh configure-apache
>
>> The 2nd command will re-generate the apache config file
>> apache-linux/linux/conf/httpd.conf
>
>> 7. Now you can start up the server again by running ./gs2-server.sh
>> (Make a note of what port it's running on)
>
> Here I had an error related to a X java environment variable not set. As I
> wanted to launch my web server on an headless server I launched the make
> web-start command instead.
>
>> 8. Go back to the client machine and run GLI-client, connect to the
>> server and try to rebuild your collection of OGV files and Preview to
>> see whether the metadata looks fine now.
>
> I had to add my client IP to allow directive in httpd.conf for this to work.
> By default the httpd.conf.in authorizes only a local connection (well, I
> could have changed the httpd.conf.in too) and client GLI returned a 403
> response.
>
>> Does the above work?
>
> It works like a charm ! Thanks again.
>
> I slightly modified my plugin too :
> - my variables' names
> - I added a License variable too to reflect the metadata ffmpeg2theora (the
> only full-featured theora encoder I know) can handle
> - I also tried to find a link between the extracted metadata and the dc
> namespace (I think dc elements are used with OAI and Z39.50 protocols)
>
> Please, see attached the last version.
>
> Best regards,
> Yvan
>