Sybernet Installation

Sybernet Installtion for UNIX

Install Sybernet

Sybernet on UNIX may now be installed with your web browser. The utility program was completely rewritten to make this installation as smooth as possible.

Copy Sybernet.utility to your cgi-bin directory.
Point your browser to cgi-bin/Sybernet.utility.
Click on Install/Update.

Sybernet.utility requires read and write permission on several directories used by your web server. If this is unacceptable, please refer to the file oldREADME in this directory. You may also want to password protect this utility with your web browser.

Ideally, you should have decompressed this tar file from the same username that your CGIs run under. Alternatively, you can change the permission on the Sybernet directory so that read, write and execute permission is allowed on all files and all directories.

chmod -R 777 Sybernet

When we installed Sybernet under an Apache server running on Linux, we experienced problems with relative path names. This was solved by replacing all occurences of Sybernet.cgi with /cgi-bin/Sybernet.cgi. With a NetScape server the problem is eliminated with the following in your obj.conf file:

    <Object name="cgi">
    ObjectType fn="force-type" type="magnus-internal/cgi"
    Service fn="send-cgi"
    </Object>

The latter is consistent with the current documentation and implies you do not need to qualify the name Sybernet.cgi in your stored procedures.

Starting a Server Manually

The Sybernet.cgi is started automatically by your web server. They connect to the Sybernet server with an internet stream socket so the servers must be up and running at all times.

It's the server that hold connections and state information between the CGI and Sybase. The servers get all their configuration parameters from the file Sybernet.config in your cgi-bin directory except for the socket number that they are suppose to listen at. The socket number is passed as a parameter to the Sybernet server. It is the only parameter that it accepts; for example,

Sybernet.server 5555

will start a Sybernet server that listens at socket 5555. Make sure that if you start the servers in this manner that the socket numbers are valid. Note: The utility program is the safest way to start the Sybernet servers because it will not start a server on an invalid socket number.

A non-zero return result indicates one of the following errors:

CANTREADCONFIGFILE
SYNTAXERROR
CANTCREATESOCKET
CANTBINDSOCKET
CANTGETSOCKETNAME
CANTOPENLOGFILE
FORKFAILED

These errors are explained in more detail in the section on trouble shooting (below).

Let me know how you progress!

Denis

Denis D. Workman (denis@unix.sri.com)
SRI International
333 Ravenswood Avenue
Menlo Park, California 94025
USA

Trouble Shooting

Trouble Shooting the Sybernet CGI Servers

The following are error messages you might see when starting one or all of the servers. Once the servers have successfully initialized, future errors are written to the log file: Sybernet.sumlog. It is a good idea to always check this file when something has gone wrong.

CAN'T CREATE INTERNET STREAM SOCKET

A call to the "socket" system function failed. I have never seen this error, but if I did, I would ask our Unix Administrator what was wrong.

CAN'T BIND TO INTERNET STREAM SOCKET

This is one of the most common error messages you will see. This usually occurs just after the Sybernet servers have been issued a stop. Let them rest for a minute or two before restarting them. If this does no good, try a different value for SOCKETS.
Make sure that the sockets at SOCKETS through SOCKETS+SERVERS-1 are not in use by some other application.

CAN'T GET SOCKET NAME

A call to "getsockname" failed. This too is another question for your Unix Admin.

CAN'T OPEN LOG FILE

Check the security on the file "Sybernet.sumlog" in your cgi-bin directory. The Sybernet server appends log information to this.

CAN'T READ THE CONFIGURATION FILE

Check the security on the file "Sybernet.config" in your cgi-bin directory. The Sybernet CGI server needs to read this file.

Trouble Shooting the Sybernet CGI client

In all cases, see if there are any entries in the Sybernet CGI server's log file: Sybernet.sumlog in the cgi-bin directory. If there are none and the servers are alive, the problem usually points to the client: either the Sybernet CGI client or the browser.

CAN'T READ THE CONFIGURATION FILE

Check the security on the file "Sybernet.config" in your cgi-bin directory. The Sybernet CGI needs to read this file.

WRITING TO STREAM SOCKET FAILED

Check that the Servers are alive and well by selecting Server Status from the utility program.
See if the problem reoccurs. If it does, bring down the servers (or if you know which server is having trouble, that server) and restart them.

READING OK FROM STREAM SOCKET FAILED

The handshake that occurs between the Sybernet CGI client and the Sybernet CGI server failed. Check that the servers are alive, and restart them if necessary.
The version of the Sybernet CGI or Sybernet utility is different from the version of the Sybernet server. Make sure that the creation dates are similar.

UNABLE TO READ CONTENTS OF CONFIGURATION FILE

It read the configuration file fine, but it found entries it did not understand. Rebuild the configuration file with the Sybernet utility by selecting Configuration from the main menu and click on submit.

UNABLE TO OPEN INTERNET STREAM SOCKET

A call to the system function "socket" failed. Contact your Unix administrator.

SERVER_NAME ENVIRONEMENT VARIABLE IS UNDEFINED

NetScape is not passing SERVER_NAME to the CGI program.

INVALID SERVER_NAME WHILE OPENING SOCKET

The SERVER_NAME environment variable is invalid. Either NetScape is getting this wrong or you need to contact your Unix administrator.

CONNECTING TO STREAM SOCKET FAILED

A Sybernet server is not running. Start it.
Increase the number of Sybernet CGI servers. You can change the number of servers with the Utility program, but the servers must be stopped before you can change this number.

CONNECTION TIMED OUT WHILE PINGING SOCKET

This probably does not mean anything serious is wrong. All it means is that the Sybernet server did not respond to a status request. Most likely, it's busy processing another request. If this does not clear up in a reasonable amount of time (say, 5 minutes?) you might try checking in Sybase (using sp_who) and see if there is perhaps a process running that will not quit.