Welcome to Linux Knowledge Base and Tutorial
"The place where you learn linux"
Child Fund

 Create an AccountHome | Submit News | Your Account  

Tutorial Menu
Linux Tutorial Home
Table of Contents

· Introduction to Operating Systems
· Linux Basics
· Working with the System
· Shells and Utilities
· Editing Files
· Basic Administration
· The Operating System
· The X Windowing System
· The Computer Itself
· Networking
· System Monitoring
· Solving Problems
· Security
· Installing and Upgrading
· Linux and Windows

Man Pages
Linux Topics
Test Your Knowledge

Site Menu
Site Map
Copyright Info
Terms of Use
Privacy Info
Masthead / Impressum
Your Account

Private Messages

News Archive
Submit News
User Articles
Web Links


The Web

Who's Online
There are currently, 75 guest(s) and 0 member(s) that are online.

You are an Anonymous user. You can register for free by clicking here



Current HOWTO: IngresII-HOWTO


7. Ingres/Net

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.

7.1. User Authentication

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.

7.2. Login Account Passwords

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.

7.3. Installation Passwords

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.

7.4. ingvalidpw

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.

7.5. Setting up the Client

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.

7.6. Setting up the Server

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.

7.7. Using Net

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

The Linux Tutorial completely respects the rights of authors and artists to decide for themselves if and how their works can be used, independent of any existing licenses. This means if you are the author of any document presented on this site and do no wish it to be displayed as it is on this site or do not wish it to be displayed at all, please contact us and we will do our very best to accommodate you. If we are unable to accommodate you, we will, at your request, remove your document as quickly as possible.

If you are the author of any document presented on this site and would like a share of the advertising revenue, please contact us using the standard Feedback Form.

Help us cut cost by not downloading the whole site!
Use of automated download sofware ("harvesters") such as wget, httrack, etc. causes the site to quickly exceed its bandwidth limitation and therefore is expressedly prohibited. For more details on this, take a look here



Security Code
Security Code
Type Security Code

Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Help if you can!

Amazon Wish List

Did You Know?
You can get all the latest Site and Linux news by checking out our news page.


Tell a Friend About Us

Bookmark and Share

Web site powered by PHP-Nuke

Is this information useful? At the very least you can help by spreading the word to your favorite newsgroups, mailing lists and forums.
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters. Articles are the property of their respective owners. Unless otherwise stated in the body of the article, article content (C) 1994-2013 by James Mohr. All rights reserved. The stylized page/paper, as well as the terms "The Linux Tutorial", "The Linux Server Tutorial", "The Linux Knowledge Base and Tutorial" and "The place where you learn Linux" are service marks of James Mohr. All rights reserved.
The Linux Knowledge Base and Tutorial may contain links to sites on the Internet, which are owned and operated by third parties. The Linux Tutorial is not responsible for the content of any such third-party site. By viewing/utilizing this web site, you have agreed to our disclaimer, terms of use and privacy policy. Use of automated download software ("harvesters") such as wget, httrack, etc. causes the site to quickly exceed its bandwidth limitation and are therefore expressly prohibited. For more details on this, take a look here

PHP-Nuke Copyright © 2004 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.
Page Generation: 0.12 Seconds