SECTION 18 -- NET
<> 18.001 What do I do if I can't connect?
This is the question every NET DBA dreads. There can be so many reasons.
First, try a remote login to the server system. If this fails then the
problem is in the underlying communications.
Some other things to check:
o Are the communications servers running on the client system?
o Did they get a successful listen on the protocol you want to use?
Check in errlog.log in the INGRES client installation.
o Are the authorisation details for the user correct in netu?
o Has the password been changed on the remote user? Then you must
update the netu information to match.
o Has the remote user got a password? NET insists on passwords.
Remember a password of 'return' is not the same as no password.
o Are the vnode details correct in netu?
o Has the user got a private vnode of the same name as a global one?
This will be used, the global one is 'hidden' from the user.
o If there is any doubt about any of the netu information, delete and
re-enter it. Note that netu accepts unprintable characters but
won't display them when you 'show' details.
o Are the communications servers running on the server system?
o Did they get a successful listen on the protocol you want to use?
Check in errlog.log in the INGRES server installation.
o Is the 'ingvalidpw' program correctly installed on the server
system?
o Are the listen details in the iirungcc.opt file correct? They must
match the netu information on the client system.
If you can't work it out turn on the NET diagnostics at both the client
and server systems. Set II_GCCxx_LOGLVL to a higher value, see the NET
User's and Administrator's Guide for details. You need to restart the
communications servers for this to take effect.
At least this will tell you how far the connect request got. You should
be able to work out if it left the client and if it arrived at the
server. This will usually isolate the problem to either the client
system or the server system.
If it looks like the communications server on the client sent it OK,
but it never arrived at the remote communications server, you are going
to need help from a network person. Plan on working late.
<> 18.002 How do I configure NET?
There are 2 ends to think about: the client end and the server end.
The tools are the `mkrungcc' script at the server end, and the `netu'
utility at the client end.
At the server end, you have to set up information for the NET
comminication servers using the mkrungcc script. This asks a lot of
questions and encodes the answers in the file iirungcc.opt in
$II_SYSTEM/ingres/files. It also sets up some INGRES environment
variables at the installation level.
Using mkrungcc you set up things like: (i) the number of communication
server processes; (ii) which protocol(s) each will use; (iii) the
listen addresses for each server and protocol, and (iv) the number of
inbound and outbound connections per server. When this has been done,
iistartup will automatically use these details to start your
communication servers at startup time. To change the details just run
mkrungcc again and the new details will be picked up at the next
restart.
At the client end, you also need to set up information using the
mkrungcc script since you need communication servers at both ends. An
annoying feature with the later versions of NET is that a communication
server won't let you make outgoing connections unless it can set up a
successful listen for incoming connections. So if you have a system
where it's used purely as a client and nothing else--where there are
never any incoming connections--you still need functional listen
addresses for the communication servers to use. If a listen fails then
the communication server `blacks' that protocol and won't allow
outgoing connections on it.
Assuming you have the communication servers running on the client
system, you also need to set up client information using the netu
utility. This is a command line question-and-answer tool. You set up
2 kinds of information in netu: (i) vnodes and (ii) authorisations.
The netu information is stored away in $II_SYSTEM/ingres/files/name and
changes should be visible right away. You don't need to do a restart.
"vnodes" are virtual names for target server systems, and the vnode
data you are asked for includes: (i) the real node name of the target
machinel (ii) the protocol to get there, and (iii) the communication
server listen address to aim for. The vnode name is what goes on the
command line to tell INGRES the database is remote, e.g.:
$ isql gnu::mydb
Vnodes can be global or private, commonly the DBA sets up global vnodes
which everyone uses. In theory users could set up their own private
vnodes if they didn't like the global ones but they usually don't
bother.
Authorisations are the information used to actually log you in on the
server system: (i) user name on the target system and (ii) password for
that user. These can also be global or private. Global authorisations
are only useful if everyone wants to be seen as the same user on the
target system, not often the case. Users need to set up their own
private authorisations or (more likely) the DBA does it for them.
The netu utility has an poor method of error reporting. Look out for
the message: `0 rows changed'. This means it didn't do anything and
it isn't going to tell you why.
Hint: set up global vnodes and private authorisations. This is the
only way that makes any sense 99% of the time.
<> 18.003 What is the 'ingvalidpw' program for?
The communications server needs to get at your Unix password
information. On some Unix variants this is not so easy, the encrypted
passwords are stored in the protected file /etc/shadow which only
superuser can read.
The ingvalidpw program does this. It is installed with `setuid root' so
it can read the shadow file. The name server then uses it to validate
username/password combinations for incoming connection requests.
<> 18.004 How can I restart NET without restarting INGRES?
It can be a nuisance to do a full restart of INGRES just to pick up a
minor change to the NET configuration.
Use the iirungcc utility. If there are communications servers running
this will ask if you want to shut them down, then it will start up the
communications servers again using the new configuration.
<> 18.005 How can I shut down the communications servers?
They get shut down automatically by the iishutdown script.
If you need to shut them down manually, use iinamu to get a list of
communications servers like this:
$ iinamu
> show comsvr
> quit
Then use netu to shut down each communications server using the
server_id numbers listed by iinamu.
<> 18.006 Which INGRES processes do I need on a client system?
If you are using a system purely as an INGRES client, and never want to
create or access local databases, then you don't need a full INGRES
service running. You only need a name server and communications
server(s).
One way to do this is to install using iibuild -c. Then iistartup will
only start the processes you need. Alternatively:
$ iirungcn; iirungcc
Whichever way you do it, you save a lot of startup time and main memory
as you don't need DBMS, archiver, or recovery processes. This makes
room for lots more users on the client.
<> 18.007 How do I configure different protocols?
The mkrungcc script tries to figure out which protocols are available
when you run it. For each available one it prompts for server listen
information.
Sometimes it needs a little encouragement. If it doesn't prompt when a
protocol is clearly available and should be supported, you'll have to
tinker with the script a bit. On Unix it may use the pkginfo
command to probe for the presence of OSI and X.25, but if the package
names are slightly different than when the script was written it will
get confused.
A single communications server can listen on multiple protocols. You
don't need a server for each protocol unless you particularly want to
do it that way.
<> 18.008 What is the address and listen information in netu?
This depends on the protocol. Some examples:
For TCP/IP, the address is usually the node name of the target system
as in /etc/hosts (or equivalent). The listen information is used to
calculate port numbers to use. It must match the listen information set
up with mkrungcc on the target system.
For OSI, the address is a communications initiator path set up using
your communications configurer. This will also contain TSAP numbers, so
the listen information in netu is not used. You can set it to
anything.
With DECnet, the address is either a DECnet address or the name of
a node in the NCP database. The listen address is the name of the
network object in the remote node's NCP database, usually II_GCC_0. The
remote machine will translate this object name into a process id and
form a logical link between the two GCC servers. Whereas all
Unix installations have a 2 character code for II_INSTALLATION (see
below) on VMS this only occurs when more than one instance of Ingres
is installed on a machine. Normally the installation code is left
blank. To connect to a different installation the listen address should
be II_GCCxx_0 where xx is the installation code. It is also possible
(but usually unnecessary) to have more than one GCC server, in which
case the listen address is II_GCC_n where n=0,1...
Other protocols do it differently. Check in the NET User's and
Administrator's Guide.
<> 18.009 How does NET figure out its TCP port numbers?
When NET is using the TCP/IP protocol, it uses the listen information
to work out a port number for the communications server to listen on.
The listen information is in the form 'ab' or 'abN', a 2-character
identifier followed optionally by a number. When you give this to
mkrungcc, it's put through an algorithm to generate a unique port
number. When you give it to netu it's put through the same algorithm,
so the client can figure out the TCP port numbers on the target
system.
There's usually no good reason not to use the default, which is the
2-character INGRES installation id with a number on the end for multiple
communications servers.
Note: you can also give numeric TCP port numbers directly and bypass
this mechanism.
<> 18.010 Can I have 2 installations running NET on the same system?
Yes, provided you use different listen information. How to do this
depends on the protocol.
For TCP/IP you can use listen information based on the unique
2-character INGRES installation ID. This guarantees unique port
numbers for the communications servers in each installation.
For OSI you need to use different TSAP numbers in the communications
responder paths for the 2 different installations.
For DECnet specify the listen address as the name of the DECnet object
as described in 18.008 above.
For other protocols the principle is the same. See the NET User's and
Administrator's Guide for details.
At the client end you need to tell netu about the different listen
information, e.g. for TCP/IP:
vnode protocol address listen
gnu_test tcp_ip gnu xx
gnu_prod tcp_ip gnu yy
Or for OSI:
vnode protocol address listen
gnu_test iso_oslan gnutest notused
gnu_prod iso_oslan gnuprod notused
In this case the 2 communications initiator paths 'gnutest' and
'gnuprod' contain the TSAP numbers of the different INGRES
installations on the remote server system.
<> 18.011 How can I use different protocol routes to access the same server?
Suppose a client and a server are connected by both TCP and OSI, which
is not that uncommon in some environments. How do you tell NET which
to use for your connection?
Actually this is quite easy. Just set up 2 global vnodes, e.g.:
vnode protocol address listen
gnu_tcp tcp_ip gnu II gnu_osi
iso_oslan gnupath notused
Then you can choose which protocol route by using the appropriate
vnode:
$ isql gnu_tcp::mydb # goes via TCP/IP route
Or: $ isql gnu_osi::mydb # goes via OSI route
<> 18.012 Can NET use all of my LAN boards?
It's common for larger systems to have several LAN boards, and each of
these will have its own network address. Can NET handle this?
This isn't too difficult. The netu utility has a 'merge' option for
vnodes to cater for this. It allows you to give additional network
addresses for a vnode. These are used in a round-robin fashion as
connections are made by the client, which spreads the connections
evenly across the communications boards on the remote server system.
E.g. for TCP/IP:
vnode protocol address listen
gnu tcp_ip gnu1 II
gnu tcp_ip gnu2 II
In this case gnu1 and gnu2 are entries in /etc/hosts (or equivalent)
which contain the different Internet addresses for the remote server.
Or for OSI:
vnode protocol address listen
gnu iso_oslan gnupath1 notused
gnu iso_oslan gnupath2 notused
In this case gnupath1 and gnupath2 are 2 communications initiator paths
set up with the communications configurer, they contain 2 different
network addresses for the remote server.
<> 18.013 Can I use NET over a LAN bridge?
Yes, no problem.
But watch out for performance. LAN bridges typically run at speeds like
64 kbaud, which is a whole lot slower than the LANs at either end. They
can become a bottleneck as the traffic levels rise.
<> 18.014 What about NET over WANs?
NET supports X.25 on some ports. This allows WAN connection over
long-haul X.25 networks.
However you must consider whether you really want to run NET traffic
over a slow network. NET was designed for LANs where message size is
not an issue. And each SQL interaction will pick up multiple network
turnrounds. In practice it is very, very hard to get reasonable
performance. (Don't even think about 9600 baud lines.)
If you want to do this, accept that the whole application design has to
be geared around the network bandwidth. Reasonable response times
dictate 1-2 SQLs only in many cases. You may also be forced into
(possibly nasty) compromises: shorter table and column names, heavy use
of database procedures, shorter names for these and their parameters,
all queries made repeat. Anything to cut down the network load.
<> 18.015 What if I change my password on my NET server username?
This password is also known to netu on each client that connects via
NET to that server. It's stored in the local authorisations on each
client.
You have to go round the network and change the password on all the
clients too (assuming you can remember where they all are).
<> 18.016 What do communication servers do?
When a communication server starts up, it gets its listen information
from the iirungcc.opt file in $II_SYSTEM/ingres/files. This has a line
for each communications server that gets started by the iirungcc
utility. It will look something like this:
II_GCC_TCP_IP=ab;export
II_GCC_TCP_IP II_GCC_TCP_IP=ab1;export
II_GCC_TCP_IP;II_GCC_ISO_OSLAN=gnu_ab;export II_GCC_ISO_OSLAN
This information starts 2 communications servers. Server 1 listens on
TCP/IP with a port number calculated from 'ab'. Server 2 listens on
TCP/IP with a port number calculated from 'ab1', and also on OSI using
the responder path 'gnu_ab'. This path has already been set up using
the communications configurer, and contains the TSAP numbers which are
used to listen on.
The main functions of a communications server are:
o It attempts a listen on each protocol defined by its line in
iirungcc.opt. The result is logged in errlog.log whether successful
or not. If a listen fails then the communications server won't let
you use that protocol for outgoing connections as well.
o It listens for incoming connection requests from the network. When
one arrives passes it's passed to the name server for validation,
and then gets a local DBMS connection for it.
o It listens for outgoing connection requests from local client
processes for the network. When one arrives it gets a network
connection for it.
o Incoming messages from the network are converted from network
format to local data format, then forwarded to the corresponding
local DBMS connection.
o Outgoing messages for the network from local client processes are
converted from local data format to network format, then forwarded
to the corresponding network connection.
The communications server stays in the message path. On the client your
SQL is passed to the local communications server, which forwards it to
the remote communications server. This then forwards it to the DBMS
server. The results go back down the same route.
If the client and server systems have the same hardware format then the
data isn't converted to/from network format. Conversion is only done
for heterogenuous connections.
<> 18.017 Will my applications run over NET unchanged?
Yes, the SQL will run across NET exactly as it runs locally. If the
client and server systems are the same type of hardware, and run the
same version of INGRES, you should not even need to recompile.
For a 4GL application use the -d flag to redirect the connection:
$ my4glapp -dgnu::mydb
You may have problems if you use a local filesystem from the application
Also check out things like hard-coded path names. Small differences in
the environment are another problem area.
If your application fires off background activities, you need to think
whether these are best run on the client or the server. Use something
like uux to start remote batch or reports. Most environments/protocols
will provide some kind of remote execution facility.
DBA things are usually better done on the server system. A number of
DBA-type functions won't run over NET, e.g. ckpdb.
<> 18.018 Will my applications perform over NET unchanged?
If your application is very well designed and built, and the SQL
technique is good, then yes.
Unfortunately, many real world applications aren't like this. They
break the golden rules:
1. Omit Needless SQL
2. Only Get The Data You Need
The cost of extra SQL or fetching large data sets will slow down a
local application. Over NET it can make an application unusable. In
practice most applications need to be modified to get the right
performance over NET. The network changes the trade-off between design
and programming ease, and performance.
There are some kinds of things that are inherently unsuitable for NET:
o Heavy batch processing which brings a lot of data to the program
for processing. Run these on the database server system.
o Long reports which again must by their nature fetch large amounts
of data. Run these on the database server system and use remote
printing or file transfer to get the results to the right place.
o Database browsing where large data sets may be fetched. Impose
limits in the browsing function so this can't happen. Or initiate
a batch process on the database server system.
o Tablefields which bring back many rows to the client. Don't.
<> 18.019 What's the GCA protocol?
This is the application-level dialogue rules for a conversation between
an INGRES client and server process. It's the same whether the
connection is local, or remote via NET.
It's not the same as a communications protocol. You still need TCP/IP
or OSI or whatever, GCA is a level above these and runs over them. They
are used to transport the GCA conversation.
In some ways it's not a compact protocol. For example: a simple SELECT
will cause 4 or 5 GCA messages to be exchanged. This might cause up to
10 network packets. You can start to see why careless SQL can cause
heavy NET traffic.
<> 18.020 Does NET present any special security problems?
An INGRES/NET client stores the passwords needed to access a remote
system in a local encrypted file. It must decrypt the password to
transmit it to the server to authenticate access. It is therefore
conceivable that a sufficiently well informed and industrious
"intruder" could analyse the executable code and determine how to
decrypt the local password file.
Usually the effort and expertise required will be sufficient
discouragement, but if a system contains especially sensitive or
valuable data then it will naturally be attractive to precisely the
kind of people who have the skills and inclination to penetrate it.
Some precautions can be taken:
o The first precaution is to check that the local password
file on Unix clients is secured so that only `ingres' processes
can read it. If it is not, then the following will fix it:
chown ingres $II_SYSTEM/ingres/files/name
chmod 700 $II_SYSTEM/ingres/files/name
o If the user has no need to access the remote host by any
means other than NET then that user's login shell can be set to
something harmless like /etc/date. NET will still be able
to access the system but it will be impossible to actually
log in as that user.
o If the user DOES need to log into the remote system, assign the
user a separate ID to be used just with NET and give it an unusable
shell like /etc/date. Such additional IDs would not require a
home directory or other significant resources. The password of
just the NET ID would need to be stored on the client.
<> 18.021 Can I run INGRES clients without NET?
There's an undocumented facility which may allow you to do this,
sometimes referred to as INGRES/LAN or direct connect.
You set II_DBMS_SERVER to the address of a remote DBMS server process:
$ II_DBMS_SERVER='gnu::1234'
$ export II_DBMS_SERVER
Now all INGRES connections from this shell will go to server id 1234 on
the remote server system with the TCP node name 'gnu'.
Performance will often be better as you are bypassing the NET
Communication Servers at both ends, reducing path lengths and process
switching.
It has a number of limitations. Some of these are:
o It only works with TCP/IP protocol, because it's a side-effect of
INGRES processes communicating via TCP loopback sockets.
o It probably only works for UNIX clients and servers.
o Since you bypass the NET Communication Servers you don't get data
format conversions. So both the client and server systems must have
the same hardware format: same byte order, same float format,
same char set, etc.
o You have to give the DBMS server port numbers directly, and these
change every time the server is reloaded or a new DBMS server
starts. You will need to set up a mechanism to propogate the
server ids to all the client systems.
o It follows that there's no load balancing since you bypass the
Name Server on the remote server system. You have to arrange
the mapping of client connections to DBMS server processes
yourself.
o This is an undocumented facility and it may cease to work at any
time in the future without any warning or apology from Computer
Associates.
If you decide to use this for real work you'll need to check your
support status with your supplier's Technical Support.