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 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 St.Waidele@LinuxBasics.org
But since this is now a wiki-page, you might as well improve it yourself :)

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.

Tip: If you want to run a DNS on your own network, but do not want to install the full-blown BIND (which is the standard DNS-Server) you should look into dnsmasq at: www.thekelleys.org.uk/dnsmasq/doc.html.

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.

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!

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-Server 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.

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.

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 for retrieving and reading mail
• IMAP: Internet Mail Access Protocol for retrieving and reading mail
• CUPS: Common Unix Printing System
• 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.

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.

The sections that follow will explain how it is possible to control other machines on the network. While most of the methods work together well, they also work independently from each other. Some techniques complement each other, some are alternatives for each other. If you made your way through the section “X11-Forwarding done by ssh” you might want to take a break and get confortable with what you have learned. After everything has settled, continue to the “XDMCP-sections”. If you need to connect to (or from) Windows-PCs, go to the “VNC section” at the end. This screenshot might give you an idea of what is possible.

All this is possible in local networks. As I said, in Unix/Linux there are almost no differences between one computer, a local network and the internet. While this is completely true for the techniques described here, some things (like routers or firewalls) used in internetwork connections might break them. This can be fixed (with port-forwarding) but that is something way beyond the scope of this lesson. If you need to do these things across the internet, your search-engine will help you further.

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). When you are done, type “logout”, “exit”, or “<Ctrl>-D” to end the connection.

stw@linux:~> ssh info@eighty-one
info@eighty-ones password:
Have a lot of fun...
info@eighty-one:~> uname -a
info@eighty-one:~> w
info@eighty-one:~> df -h
info@eighty-one:~> logout
Connection to eighty-one closed.
stw@linux:~>

There are also ssh-clients for other OS. I used to use TeraTerm with the ssh-extension to access my linux-shell from windows. Putty is probably most popular ssh-client for windows. The search-engine of your choice will get you to the download-pages of those tools.

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)

I only include this here for debugging purposes! If the other methods don’t work and you want to check if remote X11-access works at all, then try this. Otherwise, don’t read this! Skip to X11-Forwarding done by ssh.

On The X-Server (local machine) you have to run the command xhost +remoteip to grant the X-Client (remote machine) the right to access your screen. (This access-right is valid until X11 is restarted or explicitely revoked by xhost -remoteip.) After connectiing via ssh to the remote machine, you will have to set the environment-variable DISPLAY by export DISPLAY=localip:0.0 (The ‘:0.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.0’

So you want to try the insecure way of X11-forwarding. Try this:

stw@linux:~> xhost + eighty-one
eighty-one being added to access control list
stw@linux:~> ssh info@eighty-one
info@eighty-ones password:
Have a lot of fun...
info@eighty-one:~> export DISPLAY=linux:0
info@eighty-one:~> xclock & xterm & xload & emacs this.will.go.to.a.X11.Window
info@eighty-one:~> logout
Connection to eighty-one closed.
stw@linux:~>

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

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!

stw@linux:~> ssh -X info@eighty-one
info@eighty-ones password:
Have a lot of fun...
info@eighty-one:~> xclock & xterm & xload & emacs this.will.go.to.a.X11.Window
info@eighty-one:~> logout
Connection to eighty-one closed.
stw@linux:~>

If that does not work, check if you have the X11Forwarding option in the SSHd? set to yes:

linux:~ # grep  "^X11Forwarding" /etc/ssh/sshd_config
X11Forwarding yes

If the command gives you something else (or nothing) as output, you will need to edit /etc/ssh/sshd_config (on the ssh-server, which is the remote-machine) and restart sshd. (SuSE: rcsshd restart, Debian: /etc/init.d/sshd restart, others ???)

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

Using “ssh -X”, 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). These three are alternatives. You can pick your favorite. :)

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.

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 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.

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 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 fullscreen. You can switch between ‘remote’ and ‘local’ by pressing <ctrl>+<alt><F7> and <ctrl>+<alt><F8> Loging out will take you again to the login-screen. You can kill the server by pressing <ctrl>+<alt><Backspace>.

Another option to access an XDMCP-Server is Xnest. It opens a window on the X11-Screen you are using. The connection is displayed inside that window as if it where a screen of it own. You can even start Xnest from inside Xnest…

I think this is the perfect time for a screenshot :) http://LinuxBasics.org/LanRemote.jpg shows my SuSE8.2-KDE running Xnest connecting to my SuSE8.1 PC called eighty-one, also running KDE. Inside that Xnest (read: running on ‘eighty-one’) there are three windows. Two more Xnests and a VNC-Viewer (explained in the section below). The two Xnests are connected to eighty-one (read: eighty-one is remote and local at the same time), but at login, I chose different window-managers: MWM and windowmaker. While WMW has two regular applications (xcalc and xplanet), windowmaker has one xterm open, from which I connected to a co-located server some 200 miles away via ssh. The VNC-Viewer is connected to a Windows-PC, which in turn uses TeraTerm to ssh to my linux-laptop. As I said: Networking can be confusing :)

There are also X11-server for other OS. MacOS comes with a X11-technology. I have used Cygwin to run X11 on a Windows-box. It looked like Xnest, but was notably slower. Hummingbird is a commercial X11-Server for windows. It looks quite nice (Seamless windows: X11-Windows and Win-Windows mix together). Speed was also ok, but the evaluation-license expired some day and the product is quite expensive. When I evaluated Hummingbird, there was no de-installer. The ‘dead’ icons stuck around until the next Windows-reinstall. The search-engine of your choice will get you to the download-page of Cygwin.

VNC is another option to remotely control a GUI. It is independant of X11 or SSH and runs on many plattforms. 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 = “950×650”; 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 from Windows, Linux or MacOS.

• www.realvnc.org - VNC-Homepage
• www.the-labs.com/X11 - Information on X11, xnest, vnc, multihead & stuff
• www.linuxworld.com/story/32827.htm - Remote X11 access using XDMCP
  Linuxworld has moved this article. The links inside the document do not work anymore. So here are parts 2, 3, and 4.
• Net-HOWTO - Networking in Linux (especially the section on IP-Network-Classes
• Fernsteuerung - The remote-control part of this lesson has been translated to german.