NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
>From: "Fingerhut, William A" <address@hidden> >Organization: Lyndon State >Keywords: 200206052016.g55KGcJ09679 McIDAS-X ADDE Bill, >We have not figured this out yet, but I wanted to ask you a related >question. > >Just to fill you in, first, telnet is disabled - but ssh is enabled. I >can not ssh to either port 500 or 503 either. So, we are trying to determine >why. When we figure out why, I'll get back to you. OK. >The question (was posed by our sys admin) is that if ports 500 and 503 >were open to everyone, then wouldn't this constitute a security hole? He says >that someone could login, kill the process and be in the machine. Could >you comment on this, please? If you setup /etc/services and /etc/xinetd.d/mcserv and /etc/xinetd.d/mccompress correctly, you can not login to either of these ports. The McIDAS mcserv process gets started and it listens to the port and relays traffic to appropriate ADDE servers. Some confusion might arise from my comment about telnetting to the port. All that the telnet shows is that something gets started by the connection attemp and then is listening. On your machine, nothing is getting started, or, at least, the correct thing is not being started. In order to further control access through ports 500 and 503, have your system administrator add the following line to /etc/hosts.allow: mcservsh: xxx.xxx.xxx.xxx Replace the xxx.xxx.xxx.xxx with as much of the local subnet as desired. Here are examples: mcservsh: 155.42.21.12 <- limits ADDE traffic to foxfire alone mcservsh: 155.42.21 <- limits ADDE traffic to 155.42.21 subnet mcservsh: 155.42 <- limits ADDE traffic to 155.42 subnet One thought, there may be another process loaded on your machine that is called 'mcserv'. Have your system administrator login to foxfire as 'root' and see if there is such an application -- that is not part of McIDAS -- and remove it/rename it if one is found. The other things that usually trip people up are: o incorrect entries in /etc/xinetd.d/mcserv and /etc/xinetd.d/mccompress: The entries should look something like: service mcserv { socket_type = stream protocol = tcp wait = no port = 500 user = mcadde server = /home/mcidas/bin/mcservsh server_args = -H /home/mcidas disable = no log_type = FILE /dev/null } service mccompress { socket_type = stream protocol = tcp wait = no port = 503 user = mcadde server = /home/mcidas/bin/mcservsh server_args = -H /home/mcidas disable = no log_type = FILE /dev/null } The things that might have to be changed are the fully qualified pathname for mcservsh (if, for instance the HOME directory of 'mcidas' is not /home/mcidas) or the specification of where the HOME directory is (the server_args setting). Note that the log_type will not be /dev/null if you want server transactions logged in system log files. o the entries in /etc/services for ports 500 and 503 are not setup correctly. NOTE: on RedHat Linux v7.x, /etc/services entries do not have to be changed for McIDAS use as long as the entries in /etc/xinetd.d/mcserv|mccompress are setup correctly. o the appropriate signal was not sent to xinetd after the mods were made o the .mcenv setup in ~mcidas is not correct I can login in and poke around if this starts to drag out. Tom