29 – Linux Networking and Remote access

December 5, 2009 – 10:17 pm

Please note… This information no longer exists at the referenced locations.  This is only a copy of what was available in 2003.

Basic Linux Training™

Linux Networking and Remote access

Stefan Waidele jun.

Table of Contents

Disclaimer

This is a lesson provided for free. I have shared my knowledge about networking as well as I was able to. Yet, there might be mistakes, typos, misunderstanding on my part, omissions and many other things that might cause the information in this document to be wrong.

Security has not been taken in to consideration at all! This document only tries to give readers a start in using Linux-networks in a home environment. Where you go from there is your choice, but if you start using any of this seriously, tighten it up!

Comments and corrections by e-mail are welcome Stefan@Waidele.net

IP-Addresses and Hostnames

If we talk about Linux networking, we are talking about IP networks. IP stands for Internet Protocol, and so, if we are looking into Linux-networking on a LAN (Local Area Network), we look at the same techniques that are used to drive the ‘big Internet’.
This brings advantages as well as disadvantages. The bad thing about it is that we cannot simply ‘browse’ the network plugged together on an ad-hoc basis like it is the case with pure windows LANs. We have to take into consideration some things that might not be important to us, but on a large (read: world-wide) scale, they are vital.

In a network, each computer (in fact each NIC – Network Interface Card) has to be identified or addressed.
I would like to choose a large office-building’s telephone system as an analogy: We have telephone numbers, we have extensions and we have people speaking languages on the lines.

In the world of IP-Networking, each NIC is addressed by a 4-Byte number, which is written with each byte separated by a dot. Most of those numbers are unique (world wide). So if you want to have access to information on Linux, you might try surfing to http://198.182.196.56 and find out that this IP address is registered by www.Linux.org. Those longer names are for humans to remember. They correspond to an ‘ip-number’. In order to get to the actual content, your computer will need the numbers, not the name!
Since not all computers are linked directly to the Internet, and since there is only a limited number of ip-addresses, some of them are set aside for internal use in ‘private networks’. ‘Private’ here means that they are not publicly accessed. They can be run by individuals, companies or even the government. They are still private.

So, when installing Linux, you might be asked for an ip-address. You might just make up one, but then you would be taking the risk that this number is taken by your favorite Internet site and so you could not access it. So you better pick one of the numbers that start with 192.168.x.. With x being anything from 0 up to 255. This will be your ‘network’ – comparable to the area-code in a telephone number. For instance, we take the 1, thus the network-part of our ip-addresses will be 192.168.1. The ip-address of the network will be 192.168.1.0. The computers on that network will have numbers ranging from 192.168.1.1 through 192.168.1.254. There is another ‘special’ address, which gets to all hosts on the net: 192.168.1.255, the broadcast-address.

There is one more special-address, which is 127.0.0.1 which always refers to the localhost, which is the computer you are logged into. (Not the one you are sitting in front of. Small difference, but you will understand when you get to the part with Remote access).

Name resolution

While some people are great with remembering phone numbers, most people are not. And since we have computers, it is obvious that people start using their computers to store their directory. So, let’s put together a file:

# IP-Directory stored at /etc/hosts
198.182.196.56       www.linux.org
207.46.134.155       www.microsoft.com
149.101.1.32         www.usdoj.gov

192.168.0.81         eighty-one
192.168.0.2          gate

127.0.0.1            localhost

And while this file is still nice and small I can look up the addresses I need by displaying it on screen (less /etc/hosts). If it gets larger, I might do something like: grep Microsoft /etc/hosts and get the result quicker. But what if any of those numbers change? Something automated had to be invented!

This is where the Domain Name Service (DNS) comes in handy. Using the host command we can look up any domain-name like www.Linux.org and get the ip-address:

stw@eighty-one:~> host www.linux.org
www.linux.org. has address 198.182.196.56

This will only work if you are connected to the Internet. So you still need the /etc/hosts for those names you need to look up when you are not connected, and those of your own private network, if you do not run your own DNS.

Automated lookup

What is even better is that all network-programs do that kind of lookup automatically. Thus it is not important if you type wget http://www.Linux.org or wget http://198.182.196.56, both will get you the same page.

The file /etc/nsswitch.conf tells the system where to look up the domain-names. A line like

hosts:          files dns

tells the resolver to first look up the file /etc/hosts and after that to query the DNS-Server specified in /etc/resolv.conf. Please be aware that this file might be changed if you are connecting to the Internet by dialup, since you will want to query your ISPs DNS-Server when connected.

Client and Server

When hearing the terms client and server, one might think about big server-machines and thin-clients. While these associations are correct when looking at the hardware side of computing, we are looking at the concepts here. So free yourself from that point of view. One machine can be server and client. It can serve itself and/or other machines, while it can be served by itself and/or other machines. We are not looking at machines, we are looking at processes.

Servers are providing some kind of service to clients. We have already encountered the DNS. A DNS-Server provides us (our applications – the clients) with the corresponding IP-address to the name we give it. A NFS (Network File System) server provides disk-space. We ask it to store or retrieve files, and the server does that for us. A SMTP (Simple Mail Transfer Protocol) server sends mail for us, while the POP (Post Office Protocol) server stores incoming mail for us to collect. The X11-Server handles graphical output for the programs. Thus, a program displaying windows on an X11-System, is a (you guessed it) X-Client!

Are you ready for the wild stuff?

All these things were pretty straight forward: Client asks, Server does. But a Server can be another server’s client. If a DNS-Server does not know the answer to our query, it might ask another, higher-level DNS-Server. A mail server can store its files on a NFS-Server, thus being client.
It can get really twisted with X11: VNC is an application that uses an X-Server for displaying output, thus an X-Client. But on the other hand, it is an X-Servers for other programs, which display their windows inside that VNC-window.
An application-server provides computing power, but uses its client’s X11-Desktop to display the output. So the server is the client and the client is the server. It just depends which part of the whole you are looking at.

Port numbers and protocols

Since one machine can run many different servers, there has to be some way to tell which network-requests are for which server-process. Each server has its port-number and all traffic directed to this port is handled by that specific application.

This compares with the extensions used on the phone numbers. While calling extension 80 might get you to the public-relations, extension 25 might be the messaging system and extension 22 lets you talk to the boss.
Same thing with the port numbers. Assuming 192.168.0.1 is our server-machine, 192.168.0.1:80 will get us to the web-server-program, 192.168.0.1:25 will get us to exim/postfix or sendmail and 192.168.0.22 lets us login safely as root, using ssh. Those port-numbers can be looked up in /etc/services

The port-number defines the kind of application that will handling the client’s request. There are many different web-servers (AOL, Apache, MS-IIS, Netscape), but only one will be installed to listen on port 80. There are different mail-server-programs (exim, postfix, sendmail), but only one will be installed to listen on port 25.
Like with the phone-extensions: You will get through to the right office, but you do not know who will answer your call. But you can be sure that the person picking up the phone is capable of helping you out (at least in an ideal world, it would be like that :-)

While the port-number specifies the kind of application you get to, the protocol specifies how the requests and responses have to be made. Think of it as the language that is spoken by the server and the client. Like in a real office-building, the same language is spoken on many phone-lines, the same protocol might be used by different applications listening on different ports. One example is HTTP being used by the web-server on port 80, by the CUPS-Print-server on port 631, by the webmin-gui on port 10000 and more.
But the FTP server will not understand HTTP and vice-versa.

Frequently used services

Some of the services often used (and provided) by Linux-machines

  • HTTP: HyperText Transfer Protocol for the World Wide Web
  • SMTP: Simple Mail Transfer Protocol for sending E-Mail
  • POP: Post Office Protocol or
    IMAP: Internet Mail Access Protocol for retrieving and reading mail
  • CUPS: Common Unix Printing System or
    LPD: Line Printing Daemon
  • X11: windowing system for graphical display
  • DNS: Domain Name Service
  • FTP: File Transfer Protocol
  • NFS: Network File System (Unix flavor)
  • Samba: SMB, Server Message Block (Windows flavor of disk-space-and-printer-sharing)
  • MySQL, PostgreSQL and others: Databases
  • SSH: Secure SHell
  • DHCP: Dynamic Host Configuring Protocol (Automated network setup)

In Linux, basic tasks like printing, e-mail and windowing are implemented as network services. That might make it a little harder to get them going, but in return, once you have set up a service to use on your own machine, it is only a matter of permissions to use that same setup from all machines on your network.

The inetd

Not all services are used all the time. So instead of starting the server-process at boot-time using memory and CPU-cycles (read: wasting time), those servers can also be started whenever something is being sent to their ports. This is done by the inetd. Take a look at /etc/inetd.conf and you might find some services you know.

Remote shell access

If you have two machines connected via the network, you can run one machine from the other. Just login remotely! While telnet used to be the way to do it, it has been replaced by ssh for security reasons.

Just type ssh username@host-ip-address and you will get a login prompt for that machine. (Connecting for the first time you will be asked to authenticate the remote machine). After logging in, you are working on that machine. You can do everything you could do if you where sitting on that machine’s console. (Except for console-switching, which is local).

Attention! You can easily do some damage by confusing machines: I once did a server-reinstall by saving the data over the network on a client-machine’s hard-drive. Then I repartitioned and formated the hard-drive. Then I inserted the installation-disk and typed ‘reboot’. Only after that I realized that I did not fdisk the server-machine like I intended, but the client-machine. I did not lose any data, since it was still on the server, but I had to reconfigure the client before the morning shift arrived to work on it :-(

So before doing anything important, check where you are. Before doing dangerous stuff, press <Ctrl>-D many times, making sure you are logged in where you are sitting. (BTW, the same danger is present if you are using a KVM-Switch)

Remote graphical access

$DISPLAY

If you are logged into another machine with ssh and you happen to start an X-application, you will probably get an error. This is because the forwarding of the X11-protocol has to be activated. So you have to add -X to the ssh-command-line.

ssh -X username@host-ip-address is everything you need to display the graphical output of the remote program on your local X11-Server (read: The screen you are looking at). Try it out, it’s cool!
This is the point were it gets hard to tell which program is running on which machine. This is the reason why applications like emacs, YaST2 (SuSE’s setup tool), and also bash have the hostname in their window-title or in the prompt. The human mind needs orientation, especially in the confusing environment of networks :-)

There are some circumstances under which this automatic X-forwarding does not work. (Or, if you are using telnet to connect, even though everybody told you not to :-) Then you will have to do some work by yourself. On The X-Server (local machine) you have to run the command xhost +remoteip once to grant the X-Client (remote machine) the right to access your screen.
On the remote machine, you will have to set the environment-variable DISPLAY by export DISPLAY=localip:0 (The ‘:0′ is the screen number used by X11. If you need to put a different number after the colon, you will know it and you will understand why. All those who do not know or do not understand should be fine with ‘:0′ :-)

All commands executed from that shell after setting DISPLAY will use the specified X11-Screen.

XDMCP

Using ssh and DISPLAY, we could run our favorite desktop-environment from that shell. This would allow us to start programs with the mouse. But the problem would be that the local panel could not be distinguished from the remote. To avoid that kind of confusion, there is the remote X11 login, using a display manager like xdm (Unix-standard) kdm (from KDE) or gdm (from Gnome).

On the remote machine, [xkg]dm needs to be running and to be configured to accept remote logins. Since X11 sends passwords for login unencrypted and is not a very secure protocol, this is not usually set up by default during installation.

XDM

To allow remote X-logins with xdm, you need to change the file /etc/X11/xdm/Xaccess (use locate Xaccess if it is not located there. Uncomment the line

#*                    #any host can get a login window

by removing the first ‘#’.
If you are using XFree86 Version 4, you need to change the file xdm-config also (in the same directory)

! SECURITY: do not listen for XDMCP or Chooser requests
! Comment out this line if you want to manage X terminals with xdm
DisplayManager.requestPort:  0

needs to be changed into

! SECURITY: do not listen for XDMCP or Chooser requests
! Comment out this line if you want to manage X terminals with xdm
! DisplayManager.requestPort:  0

There is only one ‘!’ difference. The most complicated thing is that in this file the exclamation-mark is used for comments and not the ‘#’.

After restarting xdm, your application server is all set.

KDM

KDM is the KDE-replacement of XDM. The config file is (on my SuSE8.1) in /etc/opt/kde3/share/config/kdm/kdmrc – there should be the following section:

[Xdmcp]
Enable=true
Xaccess=/etc/X11/xdm/Xaccess
Willing=/etc/X11/xdm/Xwilling

Please note that the xdm-configuration files are also used.

In SuSE, it is possible to configure kdm in /etc/sysconfig/displaymanager and run SuSEconfig after. Be aware that SuSEconfig will not overwrite any handmade kdmrc. Note the output.
Other distributions might also have these configuration tools.

GDM

The GDM-Configuration is located in /etc/gdm/gdm.conf. There is a section called [xdmcp] where you will find a line that reads ‘Enabled=false‘. Change that to ‘true‘ and you are ready to go. (Debian Woody)

Accessing the XDMCP-Server

Accessing the XDMCP-server means logging in. On the client machine (local) you need to have X11 installed and configured. Nothing more. You need no applications, no window-managers, nothing except that X11 needs to display that grey grid we all have seen before the desktop-environment takes control of the background.
From the command-line, type

/usr/X11/bin/X -query 192.168.0.81 :1

and you will get the remote-machine’s X11-Login.

VNC

VNC stands for Virtual Network Computing and is made up of two parts. The server is being remotely controlled by the viewer. There are viewers for Linux, Windows and Java, which will run on any platform as long as there is a java-enabled web-browser. There are servers for Linux and Windows. This makes VNC a cross-platform tool and thus quite different from the X11-remote-access described earlier.

When running the Linux VNC-server, you might want to tweak the vncserver script. Change the line starting with $geometry to something like $geometry = "950x650"; so the VNC-desktop fits nicely into a 1024×768 screen with all the windows-decorations around it. The script ~/.vnc/xstartup is run on server-startup and is a good place to start the window-manager or desktop environment of choice.

#!/bin/sh
# Sample ~/.vnc/xstartup

xrdb $HOME/.Xresources
xsetroot -solid grey
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
startkde &

Use the vncviewer to access the server.

Assignments

Terms and Concepts:

Define and add these to your glossary:

  • IP-Address
  • DNS
  • /etc/hosts
  • /etc/resolv.conf
  • localhost
  • Client-process
  • Server-process
  • ssh vs. telnet
  • xhost & $DISPLAY
  • XDM & XDMCP

Online:

Copyright © 2003 Stefan Waidele jun.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included here: “GNU Free Documentation License” or at www.gnu.org.
Address comments and inquiries to Stefan@Waidele.net

Sorry, comments for this entry are closed at this time.

Proudly powered by WordPress. Entries (RSS) and Comments (RSS). Silver Light 3-Column theme by Bob, modified by Ms. Crafty.