Remote and Network Computing

telnet and ftp

  1. telnet (host) - Login to remote host
  2. ftp (host) - Transfer files to/from remote host
These two commands have been for a long time the two fundamental commands of the Internet / remote computing.
Origin:

  1. telnet, 1971 (and here).
  2. ftp, 1971.

With telnet you get a command-line, with ftp you get a read-write file system.

(Read-only) ftp (File Transfer Protocol) was what people used to publish files and archives online before the Web (http - Hyper-Text Transfer Protocol). It is still in use, and most browsers should be able to read files through it.

Many people have discovered ftp through publishing web pages. They find their ISP uses a UNIX server, and their only use of UNIX is to periodically dump their web pages (edited in Windows) onto it. There are many graphical drag-and-drop ftp clients, and even programs that make the site into a full Windows drive.

These two core commands have recently been replaced by secure versions:

  1. ssh, 1995.
  2. sftp.

remote email

use POP3 protocol to talk to server: 
  mailhost.computing.dcu.ie
  mail.dcu.ie

Annoying DCU restrictions for you

At DCU, for security reasons, telnet and ftp are restricted for undergraduates:
You can telnet to/from your account locally, but not remotely.
You can ftp to/from your account locally, but not remotely.

Apparently these work remotely: 

telnet camac.dcu.ie = 136.206.2.1
ssh camac.dcu.ie
ftp camac.dcu.ie


And some or all of these may work remotely (otherwise, some or all of these may work once you are on camac): 

telnet makalu.computing.dcu.ie = 136.206.11.32 = servers subnet
ftp makalu.computing.dcu.ie

telnet eiger.computing.dcu.ie = student.computing.dcu.ie = 136.206.10.242 = student subnet
ftp eiger.computing.dcu.ie

Net access in the 1980s and today

When I was an undergraduate in the 1980s: Universities support their own dial-in access, since you can't buy such a service anywhere.
Now: Any commercial ISP can get you onto the Internet for free, so universities only need support telnet access and similar.

Then: Nobody in the phone company, TV, advertising, business, marketing, media, the press, the government or society at large has heard of the Internet. In the Computer Science department of the university, the Internet is for researchers and postgraduates, if they use it at all. It is not even mentioned when undergraduates are lectured about Computer Networks (a little-told story is how even many computer-networks researchers ignored the rise of the Internet). If undergraduates find out about it themselves and are interested, they may be given access by special permission. After you leave college, you try to piggyback onto old college accounts, friends and contacts still at college, and so on, because you can't actually buy Internet access anywhere. You have to fight hard to get onto this underground thing that no one has heard of.
Now: Governments actually promote the network, and encourage everyone in society, from children to old people, to use it. Net access comes to be seen as a basic right - something dimly felt in the 1980s but never articulated.

Then: Remote access is allowed because hardly anyone uses it anyway, and there are relatively few hackers on the network.
Now: Hacking is a plague, and there are many thousands of students, all online, many of whom will happily share and compromise their passwords. So remote access may now not be allowed! i.e. Things have got worse!

Accessing UNIX remotely and from Windows

Running UNIX GUI applications:
I use the following two to run a Windows GUI with a UNIX command-line underneath. My files on the UNIX server appear as just another read-write Windows drive. I can use Windows apps to edit them. And I have a UNIX command-line always open on which I can run scripts to process them:

FTP scripting

Of course, for repetitive tasks, drag-and-drop is not a better interface than being able to write automated scripts (this will be a theme of this course). You can write ftp scripts ("macros") and call them from Shell scripts:

HTTP scripting

You can also do HTTP GET or POST scripting from the command-line.
Some tools that do this:


  1. lynx

  2. wget

  3. cURL

Working remotely

Idea: Your files are "on the network" somewhere. You can access them and make changes to them from anywhere. All copies stay in synch.

This is what you actually have within DCU (can move from terminal to terminal, accessing files at central server). The idea is that you would have this at home (and when travelling etc.) as well.
Simplest solution - 1 copy of files
  1. Read files from server, and copy changed files back to server as you go along. Can do this with ftp now, but really need broadband to work with remote files. Need high-speed broadband to work with large remote files.

More complex solution - 2 copies of files - Work on machine which has synchronised mirror of server files - Have to keep copies in synch

  1. Synchronise over the network.
    Read files from server at start of session, copy changed files back at end of session.
    e.g. Say have broadband modem, always-on:
    1. When leave office, set synchronise program running with home. By time get home, files are synchronised. Work on them locally.
    2. When going back to office, start synch program again. By time get in, files are synchronised again.

    Or:

  2. Physically bring laptop (or flashdrive / external hard disk) to/from work to synchronise.