Q. Early this morning (i.e. 1 or 2AM), I made my first series of unsuccessful remote gpel login attempts, and was immediately discouraged by the fact that gpel3 "could not be found" via PuTTY, the client I had chosen for secure remote shelling from my WindowsXP machine.
Being that late at night (or early in the morning), I wasn't thinking clearly enough to simply try another host, and wasted significant time (upwards of an hour) seeking and downloading another client through my substandard internet connection (I incorrectly assumed the problem was with PuTTY) before realizing my short-sightedness and (duh) trying systematically to log in through the other 6 hosts.
Although (now at around 2:30AM) I was able to talk to these other hosts, even at this time (just under 7 hours before the specified deadline) I received the "Access Denied" error from each of the hosts except gpel3 - which, again, could not be accessed at ALL and may be having problems (just a heads-up).
I tried again this evening, wondering whether you may have activated my account at a later time (more like hoping, really, I'm not EXCESSIVELY naive), but of course the hosts still replied with "Access Denied," and gpel3 was unreachable.
A. I'm sorry that your first experience with the CS department UNIX machines was so frustrating. Fortunately, you have learned at least a little something from this experience, which is that one or more of the machines may be unreachable at any given time. You may get a message like "could not be found," "connection timed out," or "no route to host." This can be for many reasons, such as a student in the lab turning off or unplugging a machine (which students should NEVER do) or a hardware failure that takes a machine permanently out of service. The correct response, as you have determined, is to simply try another machine.
If you try all the machines and can't get a connection, then there may
be another problem, such as with the network itself. One simple way to see
if parts of the network are not available is with the ping
utility. This utility was originally written for UNIX but is available now
for other Operating Systems as well. You can try to ping any
machine for which you have a name or IP address.
Here are some ping examples. Note that you have to stop
pinging (typically by hitting Ctrl-C) to get the
summary information.
% ping www.google.com
PING www.google.com (216.239.41.99) 56(84) bytes of data.
64 bytes from 216.239.41.99: icmp_seq=1 ttl=51 time=45.1 ms
64 bytes from 216.239.41.99: icmp_seq=2 ttl=51 time=40.1 ms
64 bytes from 216.239.41.99: icmp_seq=3 ttl=51 time=39.9 ms
64 bytes from 216.239.41.99: icmp_seq=4 ttl=51 time=39.6 ms
--- www.google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3026ms
rtt min/avg/max/mdev = 39.677/41.220/45.134/2.278 ms
Yep, I can get to google, so my general network connection must be good.
% ping gpel3.cs.ou.edu
PING gpel3.cs.ou.edu (129.15.78.13) 56(84) bytes of data.
From meme (129.15.78.175) icmp_seq=1 Destination Host Unreachable
From meme (129.15.78.175) icmp_seq=2 Destination Host Unreachable
From meme (129.15.78.175) icmp_seq=3 Destination Host Unreachable
--- gpel3.cs.ou.edu ping statistics ---
5 packets transmitted, 0 received, 3 errors, 100% packet loss, time 4020ms
Hmmn, I can't get to gpel3, is it that machine or the CS network?
% ping gpel2.cs.ou.edu
PING gpel2.cs.ou.edu (129.15.78.12) 56(84) bytes of data.
64 bytes from gpel2.cs.ou.edu (129.15.78.12): icmp_seq=1 ttl=255 time=11.9 ms
64 bytes from gpel2.cs.ou.edu (129.15.78.12): icmp_seq=2 ttl=255 time=0.197 ms
64 bytes from gpel2.cs.ou.edu (129.15.78.12): icmp_seq=3 ttl=255 time=0.202 ms
64 bytes from gpel2.cs.ou.edu (129.15.78.12): icmp_seq=4 ttl=255 time=0.196 ms
--- gpel2.cs.ou.edu ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3026ms
rtt min/avg/max/mdev = 0.196/3.135/11.948/5.088 ms
I can get to gpel2, so it must just be a problem with gpel3, rather than the whole CS network.
Once you have figured out that the network is fine, if you still have problems, then you can try to determine if it is your software or perhaps your procedure.
In this case, I suspect it is your procedure. Try to log in again. Make
sure to use the correct username and password. Also, while PuTTY (and
similar software) should work fine, you have to make sure that you are
telling it to make an ssh connection, rather than a
telnet connection. Because telnet connections
are inherently insecure, they will be refused with no chance to log
in.