Andrew Hudson - Fedora™ Unleashed, 2008 edition

Unless you have Fedora configured to log in a specific user automatically, you will be familiar with the user login screen that appears at bootup. What you are seeing is the GNOME Display Manager (GDM), which runs your X sessions, checks passwords, and so forth. What you are doing is logging in to the local machine because that is the default configuration.

However, GDM is also equipped to allow other network users to connect to your machine through the XDMCP protocol. There are various reasons for using XDMCP; the most popular is that many modern machines are large and noisy. They have big hard drives, CPUs with huge fans, powerful graphics cards, and so do not fit into a peaceful living room. On the flip side, a thin client (a machine with very little CPU power and no hard disk of its own) is silent but not powerful enough to run GNOME or OpenOffice.org.

The solution is to have your powerful machine locked away in a cupboard somewhere with a Wi-Fi connection attached and your quiet thin client sitting in the lounge also on the Wi-Fi link. The thin client connects to the powerful machine and runs all its programs from there, with all the graphics being relayed over the network.

With Fedora, this is easy to do. On the server side (the powerful machine), you need to check one box, and on the client side (the less-powerful machine), you need to check another box. We will start with the server side. Select System Settings, Login Screen; then select the XDMCP tab and click Enable XDMCP. On the client side, select System Settings, Login Screen; then select the Security tab and click the Allow Running XDMCP Chooser from the Login Screen. You should also make sure the Show Actions Menu box is checked.

Now, from the client side, log out from your desktop so that you return to the Fedora login screen. When it prompts you for your username, press F10. A menu appears with an option labeled XDMCP Chooser. Select that and a new dialog box appears with a list of local XDMCP servers that are willing to accept your connection—you should see your server in there. Select it and click Connect; you will see a login screen from that server, inviting you to log in. You need, of course, a valid account on the server to be able to log in; however, that is the only thing you need.

As you can see, because XDMCP is so core to the X Window System, it is easy to set up. However, as you will find as you use it, XDMCP is very slow — even on a Gigabit Ethernet network, it chews up a substantial percentage of bandwidth. It is also insecure. Anyone can monitor what you are doing with very little work. Because of these two flaws, XDMCP should never be used outside a trusted network.

The next step up from XDMCP is VNC, which was developed at AT&T's Cambridge Research Laboratory in England. VNC is widespread in the Linux world and, to a lesser extent, in the Windows world. Its main advantage is its widespread nature: Nearly all Linux distributions bundle VNC, and clients are available for a wide selection of platforms.

By default, Fedora installs the VNC server component but not the client component. Go to the Add or Remove Packages dialog box and select System Tools. Then select vnc to install the client, go to Network Servers, and select vnc-serverto install the server.

With that done, all that remains is to tell Fedora who should be allowed to connect to your session. This is done from the Remote Desktop option on the Preferences menu. By default, your desktop is not shared, so check Allow Other Users to View Your Desktop to share it. You should also check Allow Other Users to Control Your Desktop; otherwise, people can see what you are doing but not interact with the desktop — which is not very helpful.

The second set of options on that screen is important. If you are using this as a remote way to connect to your own desktop, deselect Ask You for Confirmation. If this is not done, when you try to connect from your remote location, Fedora pops a message box up on the local machine asking Should this person be allowed to connect?. Because you are not there to click Yes, the connection fails. If you want to let someone else remotely

connect to your system, keep this box enabled so that you know when people are connecting. You should always enter a password, no matter who might connect. VNC, like XDMCP, should not be considered secure over the Internet, or even on untrusted networks.

► http://www.openssh.com/— The home page of the OpenSSH implementation of SSH that Fedora Core Linux uses. It is run by the same team as OpenBSD, a secure BSD-based operating system.

► http://www.realvnc.com/— The home page of the team that made VNC at AT&T's Cambridge Research Laboratory. It has since started RealVNC Ltd., a company dedicated to developing and supporting VNC.

► http://www.tightvnc.com/— Here you can find an alternative to VNC called TightVNC that has several key advances over the stock VNC release. The most important feature is that TightVNC can use SSH for encryption, guaranteeing security.

► http://www.nomachine.com/— Another alternative to VNC is in the pipeline, called NX. The free implementation, FreeNX, is under heavy development at the time of writing but promises to work much faster than VNC.

One book on SSH that stands out from the crowd is known as "The Snail Book" because of the picture on the cover. It covers the entire SSH suite and is called SSH: The Secure Shell (O'Reilly), ISBN: 0-596-00011-1.

Xen is a powerful new virtualization system that enables you to run multiple operating systems on one computer. If you have ever used virtualization software such as VMware or Virtual PC, you have an idea how Xen works, except that it is faster, more powerful, and, of course, completely free.

This chapter contains an introduction to the world of Xen: how it differs from normal virtualization solutions, how you can install it on your Fedora machine, and how to get it configured to best suit your environment.

The last few years have seen an incredible growth in the market for blade servers — high-performance, low-cost, space-saving servers that can be hooked together to form massive computing networks. These server farms provide a terrific amount of power for a relatively small budget, but the main problem with them is that distributing workload makes idle servers much more likely. For example, server A is a monolithic server: It has four CPUs, 4GB RAM, and so on, and runs both your database and web servers. If your database server is quiet but your web server is overrun with requests, it simply gives more resources to the web server. The downside here is that running multiple servers on one computer is insecure—a hole in your web server (hardly an uncommon thing) would also expose your database server. Now imagine that situation in which there are two servers: one running a database and the other running the web server. In this scenario, the database blade server would stand idle while the web server is swamped with requests.

If you think this problem is quite rare, you ought to know that experts estimate that current server farm utilization is as low as 15%, which means that 85% of your computers are likely to be sitting around waiting for something to do. Virtualization allows you to create multiple independent virtual machine (VM) operating systems that run on a single server. If one VM needs more processing power, the server simply allocates it more resources. More importantly, because the VMs are completely isolated from each other — they are literally treated as independent hardware — a security hole in one server cannot affect the others.