[ Previous | Next | Table of Contents | Index | Library Home | Legal | Search ]

Commands Reference, Volume 3


invscoutd Command

Purpose

Launches a permanent Inventory Scout server daemon.

Syntax

invscoutd [ -o] [ -pPortno] [ -bBufsize] [ -dMaxdbsize] [ -tTimeout] [ -vVerblev] Logfile

Description

The invscoutd command implements a permanent Inventory Scout server daemon on one machine in a user's local network. The usual client is a Java applet running in the user's Web browser, which was downloaded from a central Inventory Scout CGI application.

Daemon initialization involves reading command line options and several local inventory scout companion files. Once in operation, each client-server transaction involves reading from a well-known socket for a text string and returning a text report over the same socket.

Protocols

Client connections to the daemon's socket use the Internet TCP/IP protocol. In a transaction, the invoking client applet sends an "action" request, as a URL-encoded text string, to the server daemon. The request is by any ASCII control character (x00 to x1F), which triggers the processing of the request.

Some requests require the client to pass additional arbitrary data. In these cases, the additional data immediately follow the termination byte for a length specified in the action request.

With one exception (ACTION=PING), the server daemon always returns a pseudo MIME format text report written back over the same socket connection. The pseudo MIME format is used even for error results. The daemon terminates the returned text and the transaction itself by closing the socket, resulting in an end-of-file (EOF) indication to the invoking client. The client should close the socket at its end of the connection as soon as the EOF is received.

Action Requests

The action request string is a standard URL-encoded string. For example:

"ACTION=actionword&NAME1=value1&NAME2&NAME3=word%xx+word+word\0"

.

Results

The daemon returns a text result in a pseudo MIME format. Specifically, it returns a header consisting of one or more Name=Value pairs, each on a line by itself. The first Name=Value pair always is the "result" code in the form RESULT=number. The result code always is returned for every action, except the PING action.

Internal scout result codes applicable only to the Java applet client are not documented below.

An optional free-form text report may follow the header lines depending on the result code. If there is a free-form text report, the header is first terminated by an empty line, such as two adjacent linefeeds.

In any event, the result report is terminated by an EOF indicator after reading the last of the report text from the socket. The EOF also signifies the end of the transaction itself.

Table 1-1.

Action Requests
ACTION= Description
PING The daemon immediately closes the socket, causing an immediate EOF in the client. This is the only action that does not return a result code or text of any kind. Example:

"action=ping\0"
 
<EOF>
ECHO The daemon returns a text report consisting of the original unparsed request string followed by a linefeed. A password (MRDM) is not required but will be echoed if provided, along with everything else. Additional data (DATALEN) is not required but will be echoed if present, as is, after the request string. For the ECHO request, DATALEN will be silently truncated to a maximum of 2000. Example:

"action=ECHO&MRDM=yadayada&datalen=9\0Hi There!"
 
"RESULT=0\n"
"\n"
"action=ECHO&MRDM=yadayada&datalen=9\n"
"Hi There!"<EOF>
URLDECODE The daemon returns a text report of the request string after parsing, and an exact copy of any subsequent data if any. A password (MRDM) is not required but will be parsed and returned if provided. Additional data (DATALEN) is not required but will be parsed and returned if provided; however any actual additional data beyond the request string will be discarded. Each numbered line of the report exhibits one parsed Name=Value pair from the original string. Example:

"action=UrlDecode&subaction=yadayada\0"
 
"RESULT=0\n"
"\n"
"  0: ACTION       UrlDecode\n"
"  1: SUBACTION    yadayada\n"
<EOF>
TESTPWD The daemon returns RESULT=0 if the MRDM password is valid. Otherwise it returns RESULT=2. Additional data (DATALEN) is not accepted and will be discarded if present. Example:

"ACTION=TESTPWD&MRDM=thepassword\0"
 
"RESULT=0\n"
"\n"
<EOF>
VERSIONS The daemon reports the current version numbers of the inventory scout itself and the scouts logic database. A password (MRDM) is not required. Additional data (DATALEN) is not accepted and will be discarded if present. Example:

"ACTION=VERSIONS\0"
 
"RESULT=0\n"
"\n"
"1.2.3.4\n"
"5.6.7.8\n"
<EOF>
LOGICDB The daemon updates the scouts logic database. Both a valid password (MRDM) and additional data (DATALEN) are required. The additional data is the new logic database, compressed and signed at IBM with the inventory scout private key. This action will authenticate the signature using the local inventory scout public key prior to replacing the old database. If successful, the returned report will include the new logic database version number. Example:

"ACTION=LOGICDB&MRDM=yadayada&DATALEN=17042\0"
"...17042 bytes of binary data..."
 
"RESULT=0\n"
"\n"
"1.2.3.4\n"
<EOF>
MCODES The daemon executes the Microcode Survey Option (none of the command line options of the stand-alone version are supported). A valid password (MRDM) is required. Additional data (DATALEN) is not accepted and will be discarded if present. Example:

"ACTION=MCODES&MRDM=xyz\0"
 
"RESULT=0\n"
"\n"
"Report Line 1\n"
"Report Line 2\n"
    :
    :
"Report Line N\n"
<EOF>
VPDS The daemon executes the VPD Survey Option (none of the command line options of the stand-alone version are supported). A valid password (MRDM) is required. Additional data (DATALEN) is not accepted and will be discarded if present. Example:

"ACTION=VPDS&MRDM=xyz\0"
 
"RESULT=0\n"
"\n"
"Report Line 1\n"
"Report Line 2\n"
    :
    :
"Report Line N\n"
<EOF>


Table 1-2.

Result Codes
Result= Description
0 Complete success.
1 Daemon aborted due to memory allocation error. This can happen in either the parent server daemon or one of the service children.
2 Service child daemon aborted because the required password (MRDM=password) was missing or not valid.
3 Service child daemon aborted because the action name-value pair (ACTION=keyword) was missing or not valid.
4 Service child daemon aborted because it was unable to reset its user ID to "invscout".
21 Service child daemon aborted due to overflow of socket input buffer. The text report part of the result is a native language error message. Client must reduce the length of the request string, or kill and restart the daemon with an increased buffer size.
22 Service child daemon aborted due to socket read error. The text report part of the result is a native language error message including the system's I/O errno string. A logfile entry will also contain the system's errno string.
23 Service child daemon aborted due to socket read timeout. The text report part of the result is a native language error message. Client must send a control character termination byte after the end of the request string, and must always send as many data bytes as specified in the DATALEN parameter. The timeout period may be changed with the -t command line argument.
24 Service child daemon aborted due to premature EOF while reading request string. The text report part of the result is a native language error message. Client must send a termination byte after the end of the request string before closing the socket connection.
25 Service child daemon aborted due to missing or invalid DATALEN parameter for an action that requires it. The text report pair of the result is a native language error message. Client must send the length of the data for all actions which pass additional binary data beyond the URL-encoded request string. Most such actions also require that the DATALEN value be limited to a specific maximum size.
26 Service child daemon aborted due to regular file I/O error, such as a permissions error, out of disk space, and so on. The text report part of the result is a native language error message. In most cases, the I/O problem must be corrected on the server machine before the client can attempt the action again.
27 Service child daemon aborted because it was unable to retrieve the version number of the logic database for an activity that required it.
28 Service child daemon aborted because it was unable to retrieve the path name of a standard inventory scout file for an activity that required it. Such files include the logic database and the public key.
29 Service child daemon aborted because in the LOGICDB action the downloaded data format was invalid.
30 Service child daemon aborted because in the LOGICDB action the downloaded data could not be authenticated.
31 Service child daemon aborted because in the LOGICDB action the downloaded logic database could not be uncompressed.
32 Service child daemon aborted because in the LOGICDB action the old logic database file could not be overwritten by the new file.

Implementation Specifics

The invscoutd command only applies to the POWER-based platform. Currently, the server does not provide host-to-network data conversions, so it will communicate incorrect data to little-endian and byte-swap clients.

Flags

Specify any arguments, beginning with a hyphen (-), before the required logfile argument. Space is not allowed between a flag and its value.

-bBufsize
Inventory Scout commands are specified as URL-encoded strings read from a TCP/IP socket into a 1024 byte fixed length buffer. This flag can change the buffer size to Bufsize bytes if future protocol changes require a larger read buffer.

-dMaxdbsize
This flag changes the maximum size of a downloaded logic database file from the default 50000 to Maxdbsize. The daemon will abort an ACTION=LOGICDB transaction if the client applet specifies a DATALEN value greater than the maximum permitted size.

Logfile
The only required command line argument is the Logfile name. Depending on the specified verbosity level, the log lines may contain startup and shutdown banners, traces of each call, detailed internal program traces, and error statements. Depending on specified verbosity level, startup banners may also be written to stderr. The Logfile should be a fully qualified path name starting at the root directory; relative file names are presumed relative from the system's root directory, not the working directory.

-o
This flag overwrites an existing logfile. If this flag is not specified, new logfile lines are appended to any existing logfile.

-pPortno
This flag changes this server's port number from the default 808 to Port.

-tTimeout
The client applet writes a control character termination byte at the end of the URL-encoded request string to indicate the end of the request. If the invscoutd daemon does not receive the termination byte within a timeout period, it aborts the transaction and closes the socket. Similarly the client must send all bytes of the additional data specified in the DATALEN parameter with sufficient speed to prevent timeout between read blocks. This option changes the default timeout period from 30 seconds to Timeout seconds.

-vVerblev
The amount of detail written to the logfile and stderr depends on the verbosity level of the daemon. Each level incorporates the messages in the lower levels; increasing the verbosity level increases the number and types of messages that are written. The verbosity level is an integer ranging from 0 to 25. This flag changes the verbosity level from the default 18 to Verblev.

Table 1-3.

Verbosity Levels
Level Description
0 All error and status messages disabled.
5 Only fatal error messages are written. Fatal errors result in the death of the server. Usually, similar messages are written to both the Logfile and stderr.
10 All error messages are written. These include nonfatal errors such as protocol errors, as well as fatal errors. Nonfatal error messages are usually written only to the Logfile.
15 This level includes startup and shutdown banner messages. Simple banner messages are usually written to both the Logfile and stderr.
18 This level includes call trace status messages. Every client call results in a single trace message. This is the default level for the invscoutd daemon. Trace messages are written only to the Logfile.
20 This level includes program trace messages. Program traces are fairly detailed program execution status messages typically used for debugging purposes. This level is not suitable for normal production execution because over time, it floods the Logfile with large amounts of text. Trace messages are written only to the Logfile.
25 This is the maximum level and includes extensive program debug messages. This level is not suitable for normal production execution. Trace messages are written only to the Logfile.

Exit Status

This command returns the following exit values:

0 Indicates successful initialization
Non-zero Indicates unsuccessful initialization

Security

The daemon must execute as effective user ID 0 (root). However service children of the daemon reset their user ID to the authentication user ID "invscout". The daemon will not execute unless the user "invscout" has been created on the host system.

By default, an accompanying cleartext password is required from the client for most operations. If the client's password does not match the system password for the authentication user ID "invscout", the action exits with a return code. The authentication user ID cannot be changed.

The LOGICDB action will fail if the data passed from the client can not be authenticated with the IBM inventory scout public key on the local host.

Files


/etc/security/password Host system password file
/var/adm/invscout/invsd.puk Name of the inventory scout public key file.
/var/adm/invscout/invs.log Conventional name for the log file. The actual name is specified on the command line.

Related Information

The invscout command.


[ Previous | Next | Table of Contents | Index | Library Home | Legal | Search ]