Allowing Connections

Day 6

Earlier I explained how to make a connection and send a file to another Connect:Direct node, in this case a 3rd party. I didn't explain the steps that the remote node administrator makes in order to allow your connection to him.

First I will explain how this was done to allow in this case a remote connection to a UNIX Connect:Direct node. In the next post I will explain how this is done in the opposite direction i.e. from the UNIX machine to the local Windows Connect:Direct node.

Most of the configuration of Connect:Direct on a UNIX machine is done by editing files. The files we will be talking about today are the netmap.cfg & userfile.cfg files. Conceptually the information in the Windows Connect:Direct configuration is very similar to that stored in the UNIX Connect:Direct files. It is just the presentation of the information that is different. This is a common theme when dealing with Connect:Direct on different platforms.

Here is the netmap entry for the Windows Connect:Direct node NICKE in the UNIX Connect:Direct configuartion file netmap.cfg :
NICKE:\
:comm.info=192.168.10.10;1364:\
:comm.transport=tcp:\:contact.name=:\
:contact.phone=:\
:descrip=:

The netmap is used to associate a network address with a Connect:Direct node name. So here you can see that the node name NICKE is associated with the ip-address 192.168.10.10 and the port 1364.  The lines in bold are the important ones; the other lines are descriptive.

The format of the configuration entry is important. You can see that field names are followed by an "=" sign and then the value for that field.
Each of these field/value pairs are surrounded by colons, and that each line ends with "\" except the last line of the configuration entry.

I talk about configuration entry, as the same format is used by other Connect:Direct UNIX configuration files such as the userfile.cfg which I'll talk about next.
*@NICKE:\
:local.id=appusr1:\
:pstmt.upload=y:\
:pstmt.upload_dir=/home/appusr1/data/outbound:\  
:pstmt.download=y:\
:pstmt.download_dir=/home/appusr1/data/inbound:\
:descrip=:

Above you can see that it does indeed have a similar format to the netmap.cfg file, but the meaning is different. Here the first line says any user ("*") from ("@") the remote node name "NICKE" is associated with the following information.  While this might be OK for testing, in practice you should use a specific remote Connect:Direct user.  In a later post I'll go into more detail about that.

When a file is transferred from NICKE to CD.REMOTE the file is stored somewhere on the file system and is owned by some user on the system. In this case the owner of the files will be "appusr1", and the file will be stored under the "/home/appusr1/data" directory.

So you can see that the netmap entry is used to make the connection between Connect:Direct nodes and the userfile entry is used to say who can connect and where the files should live and who they will be owned by.

You can think of the following entry for the local user as default values for the above definition which is often referred to as a "proxy" user definition.
So if you do not override a field in the proxy definition the value will be taken from the local user definition pointed to by the "local.id" field in the proxy definition.
appusr1:\  
:admin.auth=n:\
:pstmt.copy.ulimit=y:\
:pstmt.upload=y:\
:pstmt.upload_dir=:\
:pstmt.download=y:\
:pstmt.download_dir=:\  
:pstmt.runjob=y:\
:pstmt.runtask=y:\
:pstmt.run_dir=:\
:pstmt.submit_dir=:\
:pstmt.copy=y:\
:cmd.submit=y:\
:cmd.stopnmd=n:\
:cmd.trace=n:\
:cmd.chgproc=n:\
:name=:\
:phone=:\
:descrip=:\
:snode.ovrd=y:

I will not explain all the fields as the "Connect:Direct for UNIX Administration Guide" does a good job of that.

I will say that it is a good idea to lock down the proxy definition with specific upload/download/run/submit directories, and that the local user associated with the proxy definition should not be a privileged user such as root or the user who acts as the administrator of Connect:Direct.

So the next post will describe how to allow transfers in the opposite direction on the Windows Connect:Direct node NICKE.

Connect:Direct in the family

Day 1

You have to help family and friends. So the scene was set on that Friday the 13th. I’m not superstitious by the way! I received an urgent email from my brother Lee in the United States asking if I could help him with a Connect:Direct (C:D) connection between his company and another. He didn’t know anything about C:D apart from that I knew a lot more than he did.

He had received some good information from his corresponding number in the other company that he was trying to connect to. The problem was that they had given him too much information, and that it didn't make much sense to him. Lee’s C:D was on a Windows machine, and the box he was trying to communicate with was running the UNIX version of C:D. My brother saw no correlation between the configuration items he had been given and the C:D for Windows that he had.

The fact that the two C:D’s were running on different platforms was also thought to be part of the problem. I reassured my brother that this was normal for C:D UNIX to communicate with C:D for Windows or C:D for mainframe etc.

Learning anything new can be daunting. The trick is to not try to take everything in at once. In this case Lee really didn’t need to worry about all the configuration parameters he had been given as most of them were defaults. The key thing he needed to think about was exchanging the right information with his 3^rd party in order to make the connection.

Lee had been given a node name, an ip-address, a port number, a user name and a destination directory to copy files to.

It is important to ensure that you have network connectivity before trying to configure C:D as you can spend a lot of time before realising that there is nothing wrong with the C:D configuration, and that you had a network issue from the start. There may be firewalls that have to be navigated that may perform NAT (Network Address Translation) etc. So you need to be sure that the ip-address being used for you to put in your configuration is an address that you can “see” from your C:D server. There is no point specifying an address that can not be routed to.

At my work we can test the connectivity using a perl script. Lee didn’t have perl on his Windows machine and wasn’t in the mood to install it at that time. I explained that he could use the “telnet” program to open the appropriate port on the remote server to just see if there is anything listening on that port. I told him to type in “telnet 192.168.9.9 1364” at the Windows command prompt.

There are 4 possible outcomes from running this command “failed”, “refused”, “timeout” & “connected”. I told him that we needed to be able to prove the connectivity to the remote node before continuing.

In the next post I help Lee configure his C:D for Windows using the Requester program.