6. Accessing VectorH

You start or shut down VectorH on the master node using the ingstart or ingstop commands. VectorH on the slave nodes is started and stopped automatically.

1. Log on to your system through the system administrator account for the instance and source the environment script.

The ingstart command checks whether you have sufficient operating system resources to run the product components. If so, ingstart starts all servers that are part of your instance.

Enter the following command:

The instance is stopped.

During installation, a script is generated that automatically starts Vector as a service unless you used the Install VectorH Using the Ingbuild Distribution (Express Installation).

The generated script to start Vector for Linux as a service is installed under /etc/init.d. The service is named actian-vectorXX, where XX is the instance ID, the value for II_INSTALLATION, specified during installation (default is VW for Vector and VH for VectorH).

Run the following as root:

where XX is the instance ID.

Use the following commands:

where XX is the instance ID.

Ingres Net must be installed to allow a Vector client to access databases on another instance.

Any installation configuration in which the client and server processes do not reside in the same instance or on the same machine must use Ingres Net. With Ingres Net on each Vector instance in your network, you can access databases on your local node and on remote nodes.

Ingres Net is included in the Client component when installing Vector. If the Client component is installed, then Ingres Net is automatically started when you start your Vector instance.

The following components are automatically installed with Ingres Net:

Each Vector user must be defined in the master database. For example, the installation owner creates a user in iidbdb:

Vector can use either of the following methods to authenticate users:

• Through the operating system (OS) account and password together with the corresponding user object definition in the master database.

• By passing the user name and password directly to the DBMS Server for DBMS authentication against the list of Vector users and their passwords. If dbms_authentication is enabled for the server (which it is by default for new installations), the user does not have to be defined as an operating system user.

Ingres Net can be configured to allow users access to remote nodes directly (through an installation password) or by providing a user name and password. The user name and password can be authenticated by the DBMS (if the server has DBMS authentication enabled), or against a local OS user account. The password is encrypted when sent across the network.

Vector allows DBMS level authentication in addition to the other supported methods (which include operating system authentication, installation passwords, and Kerberos authentication). The DBMS authentication feature removes the need to add an operating system user every time a new user needs to access a database.

A user who is appropriately defined in the database can access the database using a valid Vector user name and password. The user does not have to be defined at the operating system level or in a global directory.

DBMS authentication must be enabled for the DBMS Server on which the database resides. It is on by default (dbms_authentication=on in config.dat). Such authentication can be enabled at the server level only, not at the database level.

Database administrators can configure DBMS authentication for each user by using new WITH options on the CREATE USER and ALTER USER statements or by using Actian Director or accessdb.

A user can be defined on the CREATE USER statement as either WITH DBMS_AUTHENTICATION='REQUIRED' or WITH DBMS_AUTHENTICATION='OPTIONAL' (the default).

A user who is defined WITH DBMS_AUTHENTICATION='REQUIRED' must connect to the database using his DBMS user name and password. All other connection attempts will fail. Such a user cannot connect to a server configured as dbms_authentication=no.

System administration users must be defined as DBMS_AUTHENTICATION='OPTIONAL.' All users with the “security” privilege, including the installation owner, are forced to be DBMS_AUTHENTICATION='OPTIONAL'.

If a user is created or altered with DBMS_AUTHENTICATION='REQUIRED', the user must also have a DBMS password, or an error is issued. A user defined with no DBMS password can connect to dbms_authentication enabled servers only through a local connection, installation password, or Kerberos authentication.

Users can set and modify their own DBMS passwords if they have the CHANGE_PASSWORD privilege (the default). DBMS passwords are encrypted on disk and when passed over the network.

DBMS authentication is backward compatible. An older remote client will work with new remote dbms_authentication enabled servers if the DBMS password (defined by the CREATE USER statement and stored in iiuser catalog) is compatible with the vnode password.

When an existing installation is upgraded, existing user definitions are modified to DBMS_AUTHENTICATION='OPTIONAL'.

For more information, see the CREATE USER, ALTER USER, and CONNECT statements in the SQL Reference Guide.

A password can be specified as part of the user definition. The usage of the user password depends on whether DBMS authentication is enabled.

If DBMS authentication is enabled, the user name and password supplied by the connection attempt must match the user name and password defined in the user definition. If no password is supplied by the connecting application, the connection attempt fails.

If DBMS authentication is not enabled, the DBMS password operates as a second level of password after the initial connection is established (using the configured GCF security mechanism, such as authentication against an OS user and password). In this case, the application sends the DBMS password in the clear, after the connection is established. If the application does not provide a DBMS password, the DBMS server asks the client to prompt for one; if prompting is impossible, the connection attempt fails.

Note: If a user with the Security privilege starts a session using the –u flag to impersonate another user, the real user’s password—not the impersonator’s—is required.

A user with the CHANGE_PASSWORD privilege is permitted to change their own password; to do so, however, they must supply their old password. A user with the maintain_users privilege can change the password of another user in addition to changing the method of password validation or removing the password.

The syntax for connecting to a database depends on whether the target database server is local or remote.

The following connection examples assume that the configuration parameter dbms_authentication=on for the server.

A user logged in locally (on the server machine) can connect as follows:

This assumes that the user is defined WITH DBMS_AUTHENTICATION='OPTIONAL'. Even if the user has a DBMS password, neither password prompt nor DBMS password validation occurs. If the user is defined WITH DBMS_AUTHENTICATION='REQUIRED', the connection attempt fails because no user name or password was supplied.

A user can also connect, either as himself or as another Vector user, using DBMS authentication. He can use the +user option or the local-vnode syntax:

Note: If dbms_authentication is not enabled on the server, the last two examples will work, except that fred would have to be an OS user, and the password would have to be fred's OS password. If fred has a DBMS password defined, with dbms_authentication off, the server requests a password prompt for the DBMS password (thus, the +user=fred example might get two password prompts).

The +user option does not conflict with the effective user option (‑u). For example, if user fred has DB_ADMIN privileges for the database, he can connect and authenticate as himself, but then run the session with a different effective user:

The user (fred) is prompted for his password, and fred and password are authenticated by the DBMS. After the session is established, the effective user (ralph) is set.

If connecting to a remote server where dbms_authentication=on, a user can use either a vnode or dynamic vnode syntax:

Prompts for password. Because the +user flag is used, the [username, password] syntax cannot be specified on the dynamic vnode.

Connections established through API-based applications such as ODBC, JDBC, and .NET Data Provider directly specify a user name and password. A DBMS password sent by such an application to a dbms_authentication enabled server is meaningless and ignored.

When establishing a connection from a Vector instance to a non-UTF8 server that does not support transliteration (such as an Ingres instance that uses a native character set), you must declare the character set used for the connection.

The character set specified must match or be compatible with the character set of the target server instance. So if you are connecting from a Vector client on Linux to an Ingres instance on Windows, you can specify WIN1252, which matches the character set on the Ingres for Windows installation.

The character set can be declared in a vnode or in the connection string by using the connection attribute “character_set” (or the shorter “charset”), using the following format:

where port is the listen address of the instance on the remote node.

For example, the following dynamic vnode specification starts the terminal monitor and uses the WIN1252 character set to connect to the inventorydb database: