>From: "Dan A. Dansereau" <address@hidden> >Organization: Utah State University >Keywords: 200012072340.eB7NeUo11794 McIDAS-X 7.7 Dan, re: login to your machine >call me collect at 535-755-7012 and I'll set it up >I mean 435-755-7012 I will have to do this when I get in to work (I am working from home right now). >From address@hidden Thu Dec 7 19:55:18 2000 >after some more wild shots in the dark, >when I change the locdata.bat to local-data instead >of a ip or machine name, everything works, And keeps on working? Your first note said that things worked the first time, but then stopped on new McIDAS-X invocations. If the 'mcidas' account can run everything through local invocations of ADDE services (i.e., when DATALOCs for datasets are set to LOCAL-DATA), then the setup problem must be with your remote ADDE server. This could be something as simple as directory permissions in the ~mcidas account since 'mcadde', the remote ADDE server user, shares the 'mcidas' directories. You allude to this below. >SO my guess is that the ADDE/mcadde has a problem This is my guess also, except that I would venture to guess that the problem is file permissions on ~mcidas or ~mcidas/data. 'mcadde' and 'mcidas' should be in the same group, and these directories should be rwx for owner and group. >the mcadde acount is setuid only ( no login ) No login is how it should be. >and points to the mcidas directory. Excellent. >Our system manager >has the fear of hackers - so most things are turned >off - rlogin etc. and most things go thru a ssh >(secure shell) could that be part of it ?? Are ports 500 and 503 blocked? These are the ports that ADDE uses (500 for uncompressed transfers and 503 for compressed transfers). If the ports are blocked, then each service request would fail. This would be consistent with what you originally reported. The quick and dirty way to check this is to: telnet <machine> 500 If the port is blocked, you will not get a connection. Now, some questions: o Did your sysadmin setup use of TCP wrappers? o does your system use NIS/NIS+; if so, the mcinet7.7.sh script will not setup your system for remote ADDE use; you will have to get your sysadmin to do this o do you have the program 'top' available to you (very useful); if so, crank it up in one window; set the user listing to be 'mcadde'; change the update rate to once per second; and then try to do a remote ADDE transaction to the machine. You if the ports are not blocked, you should see processes started up as 'mcadde'. If you never see these, then either the port(s) is blocked; your ~mcidas/.mcenv file has an error in it; or one or more directories are not accessible to 'mcadde' Tom >From address@hidden Fri Dec 8 11:32:01 2000 >Subject: RE: 20001207: McIDAS ADDE setup (cont.) Tom Look for the **** form my responses >after some more wild shots in the dark, >when I change the locdata.bat to local-data instead >of a ip or machine name, everything works, And keeps on working? Your first note said that things worked the first time, but then stopped on new McIDAS-X invocations. If the 'mcidas' account can run everything through local invocations of ADDE services (i.e., when DATALOCs for datasets are set to LOCAL-DATA), then the setup problem must be with your remote ADDE server. This could be something as simple as directory permissions in the ~mcidas account since 'mcadde', the remote ADDE server user, shares the 'mcidas' directories. You allude to this below. ********************* yes it keeps working ********************* >SO my guess is that the ADDE/mcadde has a problem This is my guess also, except that I would venture to guess that the problem is file permissions on ~mcidas or ~mcidas/data. 'mcadde' and 'mcidas' should be in the same group, and these directories should be rwx for owner and group. *********************** they are in the same group ( ldm/mcidas/mcadde ) and the RWX are set for all the files in the /var/data/?? correctly - I have manually check this by vi's in each of the directories from all of the accounts. ************************ >the mcadde acount is setuid only ( no login ) No login is how it should be. >and points to the mcidas directory. Excellent. >Our system manager >has the fear of hackers - so most things are turned >off - rlogin etc. and most things go thru a ssh >(secure shell) could that be part of it ?? Are ports 500 and 503 blocked? These are the ports that ADDE uses (500 for uncompressed transfers and 503 for compressed transfers). If the ports are blocked, then each service request would fail. This would be consistent with what you originally reported. The quick and dirty way to check this is to: telnet <machine> 500 ************************** the ports are on & seems to work but I get this message protocol version mismatch:client wants 1684632077, server knows 1 Connection to host lost. ************************** If the port is blocked, you will not get a connection. Now, some questions: o Did your sysadmin setup use of TCP wrappers? ************yes + the secure shell from ssh.org o does your system use NIS/NIS+; if so, the mcinet7.7.sh script will not setup your system for remote ADDE use; you will have to get your sysadmin to do this ************no NIS - and the mcinet7.7.sh generates the proper messages o do you have the program 'top' available to you (very useful); if so, crank it up in one window; set the user listing to be 'mcadde'; change the update rate to once per second; and then try to do a remote ADDE transaction to the machine. You if the ports are not blocked, you should see processes started up as 'mcadde'. If you never see these, then either the port(s) is blocked; your ~mcidas/.mcenv file has an error in it; or one or more directories are not accessible to 'mcadde' ************this does not happen - no 'mcadde' processes start! **************************************************************************** Hope this helps - I'll be gone from 12:00 to 2:30 Dan Dansereau
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly 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.