Wiki Testing/ServerInstallationGuide6 - Revision history

Yuan: /* User Support */

2008-01-04T13:33:42Z

User Support

← Older revision		Revision as of 13:33, 4 January 2008
Line 165:		Line 165:
	As a last resort, you can use		As a last resort, you can use
	the OPeNDAP technical support service. OPeNDAP provides technical		the OPeNDAP technical support service. OPeNDAP provides technical
	support by email: [support@opendap.org\|support@opendap.org].		support by email: [[support@opendap.org\|support@opendap.org]].

Yuan: /* Testing the Installation */

2008-01-04T13:33:27Z

Testing the Installation

← Older revision		Revision as of 13:33, 4 January 2008
Line 2:		Line 2:


	It is possible to		It is possible to test the server to see whether an installation has been properly done.
	test the server to see whether an installation has been properly done.
	The easiest way to test the installation is with a simple Web client		The easiest way to test the installation is with a simple Web client
	like Netscape. (A command-line web client called <font color='green'>getdap</font> is		like Netscape. (A command-line web client called <font color='green'>getdap</font> is
Line 9:		Line 8:
	and print it on standard output. Look for it in the		and print it on standard output. Look for it in the
	<font color='green'>/usr/local/bin</font> directory. If you try it out on a couple of URLs		<font color='green'>/usr/local/bin</font> directory. If you try it out on a couple of URLs
	you are familiar with, you'll quickly see how it works.) ~~\subj{Check~~		you are familiar with, you'll quickly see how it works.)
	~~out the Quick Start Guide for information about forming DAP URLs.}~~

	You can test the web server installation first, and when you are sure		You can test the web server installation first, and when you are sure
Line 135:		Line 133:
	</pre>		</pre>

	Refer to ~~\DODSuser~~ for a description of a data attribute structure.		Refer to [http://docs.opendap.org/index.php/UserGuide<cite> The OPeNDAP User Guide</cite>] for a description of a data attribute structure. You can compare the description against what is returned by the above
	You can compare the description against what is returned by the above
	URL to test the operation of the server.		URL to test the operation of the server.

	Check the list of services and helper programs in		Check the list of services and helper programs in
	([~~http:~~/~~/www <cite> dods-server,service</cite>~~]). From a web browser, you can access		([[Wiki_Testing/ServerInstallationGuide1\|Section 1.3]]). From a web browser, you can access
	all the DAP services, except the data service, which returns binary,		all the DAP services, except the data service, which returns binary,
	not ASCII, data. That one can only be easily tested from a DAP-enabled		not ASCII, data. That one can only be easily tested from a DAP-enabled
Line 145:		Line 143:
	service is configured the same way, the odds are on your side.		service is configured the same way, the odds are on your side.

	Using the <font color='green'>.html</font> suffix produces the ~~\ifh~~, providing a		Using the <font color='green'>.html</font> suffix produces the WWW interface, providing a
	forms-based interface with which a user can query the dataset using a		forms-based interface with which a user can query the dataset using a
	simple web browser. There's more about the ~~\ifh~~ in ~~\DODSuser~~ .		simple web browser. There's more about the interface in [http://docs.opendap.org/index.php/UserGuide<cite> The OPeNDAP User Guide</cite>] .

	==Error Logs==		==Error Logs==

	When troubleshooting an OPeNDAP data		When troubleshooting an OPeNDAP data server, the logs of the web server are quite useful. The Apache server
	server, the logs of the web server are quite useful. The Apache server
	keeps two logs, an Access log and an Error log. (You can find these in		keeps two logs, an Access log and an Error log. (You can find these in
	the <font color='green'>logs</font> subdirectory where you installed Apache.) The OPeNDAP		the <font color='green'>logs</font> subdirectory where you installed Apache.) The OPeNDAP
Line 168:		Line 165:
	As a last resort, you can use		As a last resort, you can use
	the OPeNDAP technical support service. OPeNDAP provides technical		the OPeNDAP technical support service. OPeNDAP provides technical
	support by email: ~~\DODSsupport~~.		support by email: [support@opendap.org\|support@opendap.org].

Yuan: New page: =Testing the Installation= It is possible to test the server to see whether an installation has been properly done. The easiest way to test the installation is with a simple Web client ...

2007-10-04T04:09:53Z

New page: =Testing the Installation= It is possible to test the server to see whether an installation has been properly done. The easiest way to test the installation is with a simple Web client ...

New page

=Testing the Installation=

It is possible to
test the server to see whether an installation has been properly done.
The easiest way to test the installation is with a simple Web client
like Netscape. (A command-line web client called getdap is
provided with libdap which can retrieve text from Web servers,
and print it on standard output. Look for it in the
/usr/local/bin directory. If you try it out on a couple of URLs
you are familiar with, you'll quickly see how it works.) \subj{Check
out the Quick Start Guide for information about forming DAP URLs.}

You can test the web server installation first, and when you are sure
the server is working well, test the OPeNDAP server.

==Testing the Web Server==

To begin, confirm that the web server works properly by simply sending a
URL for a simple web page, or without a file at all:

<pre>
http://yourmachine
</pre>

If you don't get anything with this, examine the document root
directory (htdocs), and make a request for a file in that
directory:

<pre>
http://yourmachine/somefile.html
</pre>

Debugging these early steps is essential to getting an OPeNDAP server
to work, but troubleshooting any problems you have with these steps is
an issue specific to the web server you are using.

Once you have a web server that can return a web page, you should
exercise the CGI configuration. Here is the simplest possible CGI
program:

<pre>
#!/usr/bin/perl
print "Content-type: text/html\n\n";
print "Hello World!\n\n";
</pre>

Put this text in a file, and try to execute it from the command line.
You may have to edit the first line in case your copy of Perl isn't
stored in the /usr/bin directory. Don't forget to make the file
executable. (Use the chmod command.)

When you can execute this from the command line, put it into the CGI
directory (and make sure that the permissions will allow the
httpd to execute it), and try to execute it with a URL like
this:

<pre>
http://yourmachine/cgi-bin/test-cgi
</pre>

If you are configuring your site to use suffixes instead of a
directory to identify CGI files, name it accordingly:

<pre>
http://yourmachine/test.cgi
</pre>

Entering one of these URLs in a web server should cause the "Hello,
World!" text to appear in the web browser window. If not, check the
permissions of the CGI program, then consult the documentation for the
web server.

If everything works so far, it's time to move on to testing the
OPeNDAP server installation.

==Testing the OPeNDAP Server==

You can run the handler programs locally, that is, without going over
the Internet. Sometimes this is the simplest way to make sure that
everything is running.

<pre>
./dap_nc_handler -o dds datafile.nc
</pre>

The program should print the dataset's DDS on standard output. Use the
-h option to see the list of options the handlers accept.

The simplest remote test is simply to ask for the version of
the server, sending a URL like this:

<pre>
http://yourmachine/cgi-bin/nph-dods/version
</pre>

The server will respond to this URL with some text containing release
numbers. If you enter this URL into a standard web browser you're
doing fine if you see a message like this:

<pre>
Core version: DODS/3.2.5
Server version: nc/3.2.2
</pre>

The dispatch script can respond to a number of requests without the
assistance of its helper programs, or the existence of any data.
Besides the version request, you can also ask for the help and info
messages:

<pre>
> getdap http://test.opendap.org/opendap/nph-dods/data/nc/test.nc.ver
> getdap http://test.opendap.org/opendap/nph-dods/data/nc/test.nc.info
> getdap http://test.opendap.org/opendap//nph-dods/data/nc/test.nc.help
</pre>

Now we need to test the requests that use the handler programs, such
as dap_nc_handler. These programs compose their output by
looking at data files, so testing these requires data to be in place.

To return the data attribute structure of a dataset, use a URL such as
the following:

<pre>
> getdap http://test.opendap.org/opendap/nph-dods/data/nc/test.nc.das
</pre>

The getdap program knows about the DAP protocol, so you can
also omit the .das suffix, and use the -a option to the
geturl command. This tells getdap to append .das
for you:

<pre>
> getdap -a http://test.opendap.org/opendap/nph-dods/data/nc/test.nc
</pre>

Refer to \DODSuser for a description of a data attribute structure.
You can compare the description against what is returned by the above
URL to test the operation of the server.
Check the list of services and helper programs in
([http://www <cite> dods-server,service</cite>]). From a web browser, you can access
all the DAP services, except the data service, which returns binary,
not ASCII, data. That one can only be easily tested from a DAP-enabled
client. However, if all the service programs work, and the data
service is configured the same way, the odds are on your side.

Using the .html suffix produces the \ifh, providing a
forms-based interface with which a user can query the dataset using a
simple web browser. There's more about the \ifh in \DODSuser .

==Error Logs==

When troubleshooting an OPeNDAP data
server, the logs of the web server are quite useful. The Apache server
keeps two logs, an Access log and an Error log. (You can find these in
the logs subdirectory where you installed Apache.) The OPeNDAP
server software writes any messages it issues to the error log.

You can make the error messages slightly more verbose by editing the
DODS_Dispatch.pm file (in /usr/share/dap-server). Find
the $debug variable, and set it to 1 or 2 instead of zero. Note
that these messages are, as of version 3.5, now written to the
dbg_log file which is usually in /usr/share/dap-server.
Check the DODS_Dispatch.pm file to determine the actual path.

==User Support==

As a last resort, you can use
the OPeNDAP technical support service. OPeNDAP provides technical
support by email: \DODSsupport.