This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>From: Robert Mullenax <address@hidden> >Organization: UCAR/Unidata >Keywords: 200403190340.i2J3enrV010796 McIDAS ADDE ident port 113 Hi Robert, >I looked at the .TXT files on both machines (home and Universal..RH WS 3 >and RH 9) and they looked fine, but I just deleted them anyway and redid >them. Good. This is the quickest way to test if there is a problem with the name/IP mapping in the files. >I now >can access newpsn.nsbf.nasa.gov, but the response is slow (30 second >delay). What was the setting you talked about that could cause this? I had to talk with our system administrator, Mike Schmidt, to refresh my memory about what is going on. The following reflects the conversation he and I just had: What is happening is that the server (newpsn in your case) is first doing a forward and reverse name lookup for the requesting client, and then it is trying to contact the ident (auth) server on the client to verify its identity. The ident server connection is using port 113, so if this port is blocked on the client side, the connection will fail by timing out, and the timeout period is 30 seconds. One solution to the problem is to open port 113 on the client machine(s). This will work even if there is no service that will respond on that port (so there is no security hole). The server will succeed in connecting to port 113, but it will not find a ident server, so it will fail quickly, and the transaction will continue. Mike seems to recall that there might be a configuration option on tcp wrappers on the server side that would either turn the timeout period way down (to 1 second instead of 30, for instance), or not do the ident/auth checking. He took a quick look at man pages on Linux, but did not see anything that looked promising. You may want to check further. >I just did a stock McIDAS install. The slowness doesn't happen when >connecting from uldbldm.nsbf.nasa.gov to newpsn.nsbf.nasa.gov. uldbldm is >a Solaris 8 SPARC box. It seems to me that any box that has McIDAS compiled >with gcc/g77 responds slowly to newpsn.nsbf.nasa.gov. The slowness has nothing to do with the set of compilers used to build the McIDAS distribution. One community machine I used for testing on Saturday used gcc/g77 to build McIDAS. The reason it had fast access to newpsn was it did not have port 113 blocked. >The only machine >that gets a quick response is the Solaris 8 SPARC box. I also tried >a couple of gcc/g77 Solaris x86 boxes. Again, it is not a compiler-related issue, but, rather, it is related to ident (auth) processing on the client side. >Thanks, No worries. Tom -- NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publically available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us. >From address@hidden Mon Mar 22 13:18:26 2004 Okay, thanks. I will see about port 113. There is still something weird going on with newpsn that is ADDE related, I think (not access from external but in getting data), but I don't have enough info yet to formulate a question. Thanks, Robert