lsbinstall

Name

lsbinstall -- installation tool for various types of data

Synopsis

/usr/lib/lsb/lsbinstall [-c | --check | -r | --remove] { -t type | --type=type } [-p package | --package=package] operand...

Description

The lsbinstall utility may be used to install certain types of files into system specific locations, repositories, or databases. This command may be used during a package post installation script to add package specific data to system wide repositories. A user may need appropriate privilege to invoke lsbinstall.

The operand (or operands) name an object of type type (see below) that belongs to a package named package. The combination of package name, object type and object name should be unique amongst all objects installed by lsbinstall. The lsbinstall utility may rename an object if another package already owns an object of the same type with the same name.

Note: If a namespace collision is detected by lsbinstall, it is unspecified how the object is renamed, although typical implementations may prepend the package name to the object in some way (e.g. package.obj-name). The lsbinstall utility may maintain a database of the mappings it has performed during installation in order to ensure that the correct object is removed during a subsequent removal operation.

Scripts installed by lsbinstall should not make use of the script name in order to decide on their functionality.

Note: It is appropriate for such a script to use the script name in error messages, usage statements, etc. The only guarantee made by lsbinstall is the effect that an installation (or removal) should have, not where a script is installed, or how it is named.

The -p pkg or --package=pkg is required for all object types unless explicitly noted below.

If the -c or --check option is specified, lsbinstall should test to see if there is an existing object of the type specified already installed. If there is, lsbinstall should print a message to its standard output and immediately exit with a status of zero. If there is no object of the type and name specified already installed, lsbinstall should exit with a non-zero status and take no further action.

If the -r or --remove is specified, the named object of the specified type should be removed or disabled from the system, except as noted below. The behavior is unspecified if the named object was not previously installed by lsbinstall.

Note: lsbinstall may rename objects during installation in order to prevent name collisions where another package has already installed an object with the given name. Using lsbinstall --remove will remove only the object belonging to the named package, and not the object belonging to another package.

Also note that the intent of the --remove option is to prevent the effect of the installed object; it should be sufficient to disable or comment out the addition in some way, while leaving the content behind. It is not intended that --remove be required to be the exact reverse of installation.

Object Types

The -t type or --type=type option should support at least the following types:

profile 

install a profile script into a system specific location. There should be one operand, that names a profile shell script. The behavior is unspecified if this name does not have the suffix .sh.

The sh utility should read and execute commands in its current execution environment from all such installed profile shell scripts when invoked as an interactive login shell, or if the -l (the letter ell) is specified (see Shell Invocation).

service 

ensure a service name and number pair is known to the system service database. When installing, there must be at least two operands. The first operand should have the format %d/%s with the port number and protocol values (e.g. 22/tcp), and the second operand should be the name of the service. Any subsequent operands provide aliases for this service. The -p pkg or --package=pkg option is not required for service objects, and is ignored if specified. If any of the -r, --remove, -c or --check options are specified, there should be a single operand identifying the port and protocol values (with the same format as above).

It should not be an error to attempt to add a service name to the system service database if that service name already exists for the same port and protocol combination. If the port and protocol combination was already present, but the name unknown, the name should be added as an alias to the existing entry. It should be an error to attempt to add a second entry for a given service name and protocol, but where the port number differs from an existing entry.

If the -r or --remove is specified, the system service database need not be updated to remove or disable the named service.

inet 

add an entry to the system's network super daemon configuration. If none of the -r, --remove, -c or --check options are specified, the first operand should have the format:

"%s:%s:%s:%s:%s:%s"
Otherwise, the first operand should have the format
"%s:%s"
The fields in the first operand have the following meaning, in order:

svc_name 

The name of this service. If the name does not contain a /, this should match the name of an already installed service (see also getservbyname()). If the name contains a / character, the behavior is unspecified.

Rationale: This version of the LSB does not specify getrpcbyname() nor the existence or format of the /etc/rpc file. Therefore, installation of RPC based services is not specified at this point. A future version of this specification may require names containing a / character to be Remote Procedure Call based services.

protocol 

The name of a protocol. The name should be one of those listed in /etc/protocols. If this attribute is not specified (i.e. a null value is passed), the system should use an implementation defined default protocol.

socket_type 

One of the following values:

stream 

the service will use a stream type socket.

dgram 

the service will use a datagram type socket.

seqpacket 

the service will use a sequenced packet type socket.

This field is not required for the -c, --check, -r, or --remove options.

wait_flag 

If the value of this attribute is wait, once the service is started, no further requests for that service will be handled until the service exits. If the value is nowait, the network super daemon should continue to handle further requests for the given service while that service is running.

Note: If the service has the socket_type attribute set to dgram, the wait_flag attribute should be set to wait, since such services do not have any distinction between the socket used for listening and that used for accepting.

This field is not required for the -c, --check, -r, or --remove options.

user[.group] 

The name of a user from the user login database, optionally followed by the name of a group from the group database. The service started to handle this request should run with the privileges of the specified user and group. This field is not required for the -c, --check, -r, or --remove options.

server [arg ...] 

The name of a program to run to handle the request, optionally followed by any arguments required. The server name and each of its arguments is separated by whitespace. This field is not required for the -c, --check, -r, or --remove options.

If the implementation supports additional controls over services started through the inet super daemon, there may be additional, implementation-defined, operands.

Rationale: Systems that use the xinetd super daemon may support additional controls such as IP address restrictions, logging requirements, etc. The LSB does not require these additional controls. However, it was believed to be of sufficient benefit that implementations are granted permission to extend this interface as required.

Examples

lsbinstall --package=myapp --type=profile myco.com-prod.sh

Install the profile shell script for myco.com-prod.sh, part of the myapp package..

lsbinstall --package=myapp --check --type=profile myco.com-prod.sh

Test to see if the profile shell script for myco.com-prod.sh, as part of the myapp package, is installed correctly.

Exit Status

If the -c or --check option is specified, lsbinstall should exit with a zero status if an object of the specified type and name is already installed, or non-zero otherwise. Otherwise, lsbinstall should exit with a zero status if the object with the specified type and name was successfully installed (or removed if the -r or --remove option was specified), and non-zero if the installation (or removal) failed. On failure, a diagnostic message should be printed to the standard error file descriptor.