Ingres/Net is not part of the SDK. You only get it with the full version of Ingres. It allows applications (Ingres utilities and user programs alike) to access Ingres databases on other installations (usually on different machines as well). On the machine where the application runs, a client Ingres installation must be set up. We covered the installation of the client in subsection Client Installation. (Naturally, the client can also be a full Ingres installation.)
In this section you will see how to set up Net on both the client and server to provide remote access to the DBMS server. For a complete description of Ingres/Net I suggest you consult the Ingres/Net User Guide.
Before starting with Net, however, we need some information on how Ingres authenticates its users.
We saw earlier that only valid Ingres users can access an Ingres installation. Ingres keeps information on its users in the iidbdb database. But how does Ingres authenticate users?
In case of local access, the answer is simple: Ingres asks the operating system who the user is.
There is an exception to this rule: certain users may be granted the privilige to impersonate other Ingres users when starting an Ingres utility or application. That is why it is not necessary for every Ingres user to have an OS account. This privilege, however, can only be granted as all-or-none: if you give it to somebody, he/she will be able to impersonate any other Ingres user, including the ingres account. Therefore, never grant it to anyone.
Leaving the authentication of users to the operating system works fine for local access. But what about users who want to use the database from a remote machine? They do not log in to the machine the database resides on (the server), therefore the server's operating system will not authenticate them (they may not even have an OS account on the server machine).
There are two possible ways Ingres can authenticate these users. We will cover them in the next two subsections.
The first solution to the remote user authentication problem is to require that the client provides a local (to the server machine) user name and password. Then the Ingres server authenticates these through standard OS facilities, just like the operating system would do with real local accounts.
In this case, you do not have to set anything in Net on the server. The only thing you will need is the ingvalidpw Ingres utility. It will check (by using the getspnam and crypt OS functions) if the user's name and password are valid on the server machine. On how to install ingvalidpw, see subsection ingvalidpw.
The other way of authenticating remote users is that the server accepts their user ID on the client machine. In this case, the remote users do not have to be known to the OS on the server.
How will the server validate clients in this case? It is obvious that we need some kind of authentication: anybody can create an ingres account on a client machine, then he/she could connect to the installation as the ingres super-user.
This is where the installation password comes in: you set an installation password on the server. You then set this password on the client machines for those accounts that you want to allow to access the server under their name on the client.
The Ingres server can then authenticate the client by simply checking its installation password.
As ingbuild apparently does not bother installing ingvalidpw, you have to build it yourself.
Login as root, set the environment as that of ingres, then simply type
# mkvalidpw |
This script builds and installs ingvalidpw.
You will use the netutil utility to set up Net on the client side, and, in the case of installation passwords, also on the server. Let us see the client side first. Log in as the account you want to grant access to, or ingres, if you want to set up general access. Then type:
$ netutil |
You can see three tables on netutil's screen. Let us see what fields each of them contains:
Virtual Node Name: this is the name by which you identify the remote Ingres installation, similarly as you would define an ODBC data source name. The name is of local scope and has nothing to do either with the server machine's name or the remote installation's code.
Login/Password Data: one or two entries of the following:
Type: can be Global, or Private. If Private, the entry will only pertain to the current account. If Global, it will be used for all users on the client machine, except for those with a Private entry.
Login: the user account on the server machine. In case of an installation password, it should be *.
Password: the password on the server machine (the above user's password, or the installation password).
Connection Data: at least one entry of the following:
Type: can be Global, or Private. The same applies as in Login/Password Data.
Network Address: the server machine's address.
Protocol: the network protocol. On Linux, it is probably tcp_ip.
Listen Address: listen address of the communication server as set up by cbf. By default, it is the same as the installation code.
If you want to use an installation password, you have to configure Net on the server, too. In netutil, create a virtual node with the following data:
Virtual Node Name: must be the machine's name.
Login/Password Data
Type: Global.
Login: *.
Password: enter the installation password.
Connection Data: you do not have to enter any data here.
After you have configured Net with netutil on the client, and, if necessary, on the server, use netutil's Test menu option to see if the connection works. If it does, you can access a remote database in the following manner (let us suppose the name of the database is test, the virtual node name for the remote Ingres installation is ingserv1):
$ sql ingserv1::test |