Vector Instance
A Vector instance consists of a set of installed products that share a unique system-file location, ownership, and instance name, together with any data files created by these products. An instance is classified as either a server installation or a client installation.
Server Installation
A server installation consists of a DBMS server process (iidbms), a Name Server process (iigcn), a set of tools, and the files and logs necessary to run the DBMS Server.
If the server installation allows remote clients to access its DBMS servers, the server installation also includes the Ingres Net Communications Server process (iigcc).
Client Installation
A client installation contains a Name server process (iigcn), a Communications server process (iigcc), a Data Access Server process (iigcd), the API components that support client applications (JDBC Driver, ODBC Driver and .NET Data Provider) and the tools. A client installation does not run a DBMS server or store any data.
Installation Code
The installation code is an installer-defined, two-character code that identifies the installation, whether it be a server or client installation.
Vector default: VW
Vector in Hadoop default: VH
Client Runtime default: CR
The first character must be a letter; the second character can be a letter or numeral. If there is more than one installation on the same node, each installation must have a unique installation code.
Network Connections
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:
• Data Access Server
Provides network access to the DBMS Server for JDBC drivers and .NET Data Providers.
• JDBC Driver
How Communications Are Enabled
A server and client are able to communicate through Ingres Net as soon as the installation procedure is complete if an Installation Password and corresponding remote user authorization entry are set up on that server and client, respectively.
Otherwise, before Ingres Net can be used to connect installations, the necessary remote user authorizations, connection data, and passwords must be defined.
How to Establish User Access
The process of establishing access to Vector is as follows:
1. The system administrator defines user accounts in the operating system.
Accounts are needed for local users and for remote users who access the product through a local account.
Note: This step is optional:
• If an installation password is defined, in which case the user accesses Vector directly, without having to go through a local account.
• For remote users, if the DBMS Server is configured to use DBMS authentication.
Accounts can be set up before or after Vector is installed (except for the installation owner account, which is set up during installation, belongs to the system administrator, and is assigned maximum privileges to perform all operations).
2. The database administrator defines user objects.
A database administrator or system administrator starts Vector and defines user objects. Part of the user object definition is a user ID.
If OS authentication is used, the user ID must correspond to the user ID used to log on to the operating system.
Typically, the system administrator sets up a user object for the database administrator, who in turn sets up user objects for other users.
Requirements for Accessing Remote Instances
When the instance includes Ingres Net, users can connect to databases on remote instances as well as those on their local instance. To connect to remote instances, the following information must be specified either dynamically or in a server connection definition (also known as a virtual node, or vnode):
• Connection data
• Remote user authorizations
Server Connection Definitions (Virtual Nodes)
To connect to a remote instance, you can specify all the required information dynamically in the connection string (as described in Dynamic Vnode Specification--Connect to Remote Database).
If you do not use the dynamic method, you must define a Server Connection Definition (also known as a virtual node, or vnode), as described in Creating Server Connection Definitions (Vnodes).
A vnode is a name defined on the local instance to identify a particular remote instance. The definition contains connection data and authorization data for a remote instance.
Using vnodes is generally simpler for users because they only have to enter a single, user-friendly vnode name when they run an application, rather than detailed network-specific connection information. Another advantage of vnodes is that network changes can be updated for a vnode without notifying the user or changing the application.
Connection Data
Connection data refers to the information that the Communications Server in the local instance requires to locate and connect to the Communications Server on a remote instance. Connection data includes the following:
• The network address or node name of the remote instance’s host machine
• The listen address of the remote instance’s Communications Server
• The network protocol by which the local and remote instances communicates
Connection data can be specified dynamically when connecting or can be defined for each vnode.
It is possible to have more than one connection data entry for the same vnode. For example, if the remote instance has more than one Communications Server or can be accessed through more than one network protocol, this information can be included in the vnode definition by adding extra connection data entries.
Remote User Authorizations
Connection data alone is not sufficient to access a remote Vector instance. You must authorize users to access the remote instance.
A remote user authorization consists of either of the following:
• An Installation Password, which lets the user access the remote instance directly.
If an Installation Password is defined, a login account is optional.
• A user name and password, as either:
– An operating system user account on the host machine of the remote instance, or
– A valid Vector DBMS user and password, in which case DBMS authentication must be turned on for the remote server.
The main advantage of using an Installation Password is that users on the local node do not require an operating system account on the remote instance’s host machine. They can access the remote instance directly provided they are recognized as valid Vector users on the remote instance.
Note: Installation passwords must be used only when user privileges are the same on both local and remote machines. Using installation passwords between machines with different access privileges can lead to security access violations. For example, if a user is able to access the Vector administrator account on a client machine but not on the server machine, use of installation passwords allows the user to bypass standard security and access the database as the Vector administrator through Ingres Net.
Ingres Net requires the following remote user authorization information:
• Name of remote login (if applicable)
• Password (an Installation Password, a login account password, or a DBMS password)
Global and Private Definitions
Both connection data entries and remote user authorization entries can be defined for vnodes as either global or private. A global entry is available to all users on the local instance. A private entry is available only to the user who creates it.
Each user can create a private entry. Only a user with the GCA privilege NET_ADMIN (typically a system administrator) can create a global entry.
If both a private and a global entry exist for a given vnode, the private entry takes precedence when the user who created the private entry invokes the vnode.
The following figure shows how connections are made when both private and global entries are defined for a given vnode.
On installation_c, the system administrator has created a vnode (“Chicago”) with a global connection data entry specifying installation_a and a global remote user authorization specifying a login account (“Guest”) on that instance. User A has not defined any private definitions for vnode “Chicago” that takes precedence over the global definitions.
When User A invokes vnode “Chicago,” a connection is made to installation_a through login account “Guest.” User B has added a private remote user authorization to vnode “Chicago,” specifying the login account “User B.” When User B invokes vnode “Chicago,” the private authorization takes precedence over the global authorization, and a connection is made to installation_a through the login account “User B.”
User C has added a private connection data entry to vnode “Chicago.” The private connection data entry contains the listen address, node name, and network protocol of installation_b.
User C has also added a private authorization to login account “User C” on installation_b. When User C invokes vnode “Chicago,” the private definitions take precedence over the global definitions, and a connection is made to installation_b through the login account “User C.”
ingvalidpw and ingvalidpam Programs
In some Linux environments, Vector uses the ingvalidpw program to validate user passwords. It is not strictly a part of Ingres Net. The passwords may originate from any local application or from a remote application coming through Ingres Net or the Data Access Server.
Ingvalidpw is used depending on the requirements of the platform where the password is validated. For example, the DBMS Server uses the ingvalidpw program to validate shadow passwords on Linux or to enforce C2 security in some Linux environments.
The ingvalidpam program can be used instead of ingvalidpw to validate passwords through pluggable authentication modules (PAM).
For more information on both programs, see the Security Guide.
Net Configuration Parameters--Customize Ingres Net
Your Net installation can be customized by changing the values of the Ingres Net configuration parameters. Default values are assigned during installation.
You view or change the configuration parameters using Configuration-By-Forms (or Configuration Manager, if available).
The Net configuration parameters are as follows:
inbound_limit and outbound_limit
Defines inbound and outbound session limits.
Default: 64 inbound sessions and 64 outbound sessions
log_level
Defines the logging level (see Logging Levels)
Default: 4
Protocol
Specifies the name of the network protocol.
Default: Any protocol present at installation is indicated as active.
Listen Address
Specifies the GCC listen addresses for this installation.
Default: A GCC listen address is assigned for any protocol present at installation. The format depends on the protocol.
default_server_class
Specifies the server class assumed as the default when a server class is specified.
Default: INGRES
remote_vnode
(Optional) Specifies the vnode assumed as the default when a vnode is not specified.
Default: None.
local_vnode
Specifies the vnode name configured for the local installation.
Default: Name of host machine.
For more information, see the following chapters:
• Using Net
• Maintaining Connectivity
• Troubleshooting Connectivity
Last modified date: 12/06/2024