|
|
|
Concepts related to Ingres Net include the following:
|
|
|
A virtual node (vnode) is a name defined on the local instance to identify a particular remote instance. Assigning a vnode name is typically the first step in the process of establishing connection and authorization data for a remote instance.
Whenever local users connect to a database on a remote instance or run an application that accesses a database on a remote instance, they must do one of the following:
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 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:
Connection data is defined for each vnode, but can also be specified when using the dynamic vnode format.
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.
|
|
|
A listen address is a unique identifier used for interprocess communications. The format of a listen address is dependent on the network protocol and the hardware.
For descriptions of listen address formats for the protocols supported by Ingres Net, see the appendixes in this guide.
|
|
|
Connection data alone is not sufficient to access a remote Ingres instance. You must authorize users to access the remote instance.
A remote user authorization consists of either of the following:
An Installation Password enables the user to access the remote instance directly. Users retain their identity as defined on the local instance.
If an Installation Password is defined, a login account is optional.
A login account (set up by the system administrator) on the host machine of the remote instance. Users take on the identity of the login account through which they access the remote instance.
The main advantage of using an Installation Password is that users on the local node do not require a login account on the remote instance's host machine. They can access the remote instance directly provided they are recognized as valid Ingres 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 Ingres 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 Ingres administrator through Ingres Net.
Ingres Net requires the following remote user authorization information:
For more information, see the chapter "Establishing Communications."
|
|
|
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."