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.