>From: alan anderson <address@hidden> >Organization: St. Cloud State >Keywords: 200005172010.e4HKAp409087 McIDAS-X MCGUI configuration >upcguiprocs.tcl Alan, re: login to troubleshoot >The machine(s) in question are the student use terminals, not waldo. >I have not looked at the Gui on waldo since we seldom run mcidas on it. >I specifically keep our students locked off from it as it is our ingest >machine. OK. >Machine in question is ... Thanks. I logged onto the machine both as 'mcidas' and as a student and three things that contributed to problems: o there were three files in the student's mcidas/data directory that should not be there: FRAMED.001, TERMCHAR.001, and GRAPHICS. These fiels are created on a per-session basis and kept in a subdirectory of the users .mctmp directory. I removed them in a cleanup effort. o there are REDIRECTions for ASUS1* and FSUS2* in the user's mcidas/data/LWPATH.NAM pointing to /var/data/ldm/surface/front. Since there is no such directpory, I removed the REDIRECTions. You may want to edit the LOCAL.NAM copy of EXAMPLE.NAM in the ~mcidas/data directory and remove these REDIRECTions there (so new users will not run into the same problem). o I found a bug in ~mcidas/bin/upcguiprocs.tcl that was causing plots/contours to be put on the current frame instead of on the frame specified by the various McIDAS strings (e.g., ?SFRM, ?UFRM, ?NFRM, ?PFRM). I am simply amazed that I never ran into this problem before. I guess that it just goes to show that I always overlay analyses on top of satellite images. So, the copy of upcguiprocs on 184.108.40.206 in the ~mcidas/bin directory has the fix for the problem you have been seeing. You should propogate this module to your other machines running McIDAS-X. >I will check waldo also, but for now it is not the problem. >From address@hidden Thu May 18 10:05:02 2000 >I snooped around on waldo and have the same problem trying >to telnet in to waldo from other machines here. Looked at >the help stuff installed for Solaris, but did not find >anything. Shutdown our ldm and rebooted waldo, same problem >persists. The problem is not related to the LDM in any way. >Just as you had found, it accepts the initial connection and >then immediately closes the connection. Do you or perhaps >Mike S have any suggestions? I am betting that telnet services were shut off in /etc/inetd.conf. Edit this file as 'root' and make sure that the telnet line is not commented out: telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd If it is, uncomment it and then send a HUP signal to the inetd process: kill -HUP <process_id_of_inetd> You would do the above IF you want to allow logins from other machines, of course. Tom >From address@hidden Thu May 18 14:45:56 2000 >I checked the file you list above and found telnet was NOT commented out. >It was listed as a line the same as you printed above. >I can telnet out from waldo, and I know we could telnet into waldo earlier, >so this service was working at one time, but I do not know when it stopped >being useable. The operating system has not been changed, nor any other >changes made that I am aware of. >Thanks Alan
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.