20001207: McIDAS ADDE setup (cont.)

>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