This chapter is from the book
This chapter is from the book
This chapter is from the book
XDMCP
When your Linux system comes up, you are either looking at a graphical login screen, or a simple text login prompt. The graphical login, or login manager, can also be used by remote thin-client units or PCs. XDMCP (X Display Manager Control Protocol) is the protocol that allows thin clients to login via the graphical login manager (kdm). Option 7 asks whether you want to start the protocol. The answer here is yes.
There are other login managers. GDM is popular with GNOME users and the classic XDM is still in use. Since we are concentrating on KDE, I'll cover KDM.
Immediately thereafter, you are asked another very interesting question: Do you want the graphical login manager running on the console as well? In my own office, I tend to keep the console terminal more or less permanently logged out. Consequently, a graphical login on the console isn't necessary (even though graphical logins are provided to the thin clients). The decision here is yours.
The magic that happens in the background takes place in two files, kdmrc and Xaccess. To get a graphical login screen presented to a querying host, you need to uncomment the following lines in the /etc/X11/xdm/Xaccess file:
* #any host can get a login window * CHOOSER BROADCAST #any indirect host can get a chooser
Next, the configuration utility makes changes to the kdmrc file. On one of my systems, it is located in /etc/kde/kdm. On the other, it is in /usr/share/kde/kdm. Look for the following lines and make sure that the Enable parameter in the [Xdmcp] section is set to true.
[Xdmcp] # Whether KDM should listen to XDMCP requests. Enable=true
When you restart the window manager, you should then be able to get a remote graphical login. One way to reset the environment is to take the system down to runlevel 3 and then back to runlevel 5; this works for most systems.
init 3 init 5
If you are anxious to test this out right now, you can. All you need is a Linux client. For this example, I'll assume that you are already running in a graphical desktop. I'm going to have you type a command, but before you do, I should probably tell you what is going to happen. Your graphical KDE session is running on virtual terminal number seven. You can test this by pressing <Ctrl+Alt+F1>. You should drop out of your graphical session and back to a text screen. To get to the second, nongraphical desktop, press <Ctrl+Alt+F2> and so on, right up to virtual terminal number six. When you press <Ctrl+Alt+F7>(as in virtual terminal number seven), you'll be back to the graphical screen. The following command will start another graphical screen, but on virtual terminal eight! Assuming that your thin-client server is called your_tcserver, you would type:
X -query your_tcserver :1
Your X workstation queries your thin-client server for a login. The :1 at the end of the command specifies the second graphical display on your PC (the first is :0). If all has gone well up to this point, you should find yourself with a nice, graphical login screen. To switch back to your regular session, just press<Ctrl+Alt+F7>. To go back to the new session, press <Ctrl+Alt+F8>.
Back to Our Configuration
For each thin-client workstation you define, there should be an entry in your DNS tables or in your /etc/hosts file. If you are planning on providing entries on your name server zone files, you can skip this step. The same is true for a small handful of entries in your /etc/hosts file. Manually creating a handful of entries is easy, but Option 8 can create the hosts file entries for you. If you choose to let ltspcfg create entries for your /etc/hosts file, be aware that the entries will be generated as ws001 through ws254 (with IP addresses for your subnet) and a domain extension will be set to ltsp. You will probably want to do a global substitution in the file to change ltsp to your own domain name.
The next item on the menu, Option 9, has to do with system security. One way to provide or deny access is through the /etc/hosts.allow and /etc/hosts.deny files. Because some of these services, which may be controlled by the TCP wrapper, are needed by all thin-client workstations, it makes sense to put them in the /etc/hosts.allow file. These additions will be in a paragraph preceded by an ##LTSP-begin## comment line and closed with the ##LTSP-end## comment line.
bootpd: 0.0.0.0 in.tftpd: 192.168.22. portmap: 192.168.22.
By the way, take note that the private Class C network used in this example may not be the same as in your office. Option 10 brings us back to NFS by defining those file systems that need to be exported for the thin-client workstations. By default, the entry created looks like this:
/opt/ltsp 192.168.22.0/255.255.255.0(ro,no_root_squash,sync) /var/opt/ltsp/swapfiles 192.168.22.0/255.255.255.0(rw,no_root_squash,async)
The paths mentioned are probably fine. The first entry should not be a problem at all. I do want you to think about the second, however. If you are using NFS swap (most likely), the amount of space you allow per workstation may impact on where you store this information. Imagine 50 thin-client workstations logging in, each with 64 megabytes of swap space. That starts to add up. Make sure that the file system you choose here has the capacity to handle the load.
This brings us to the last option in the menu, and that means that it's time to talk about the lts.conf file.
The lts.conf File
When you choose to execute Option 11 and write the lts.conf file, you may get a message telling you that the file is already there. That's because by this point, you have probably effected enough changes to your system's configuration that the lts.conf file has been written. There's no harm in rewriting it, so go ahead. The file, by the way, lives in /opt/ltsp/i386/ltsp/etc, assuming you chose the recommended default installation. Aside from a few comments at the beginning of the file, this is the basic information you can expect to see:
[Default]
SERVER = 192.168.22.6
XSERVER = auto
X_MOUSE_PROTOCOL = "PS/2"
X_MOUSE_DEVICE = "/dev/psaux"
X_MOUSE_RESOLUTION = 400
X_MOUSE_BUTTONS = 3
USE_XFS = N
SCREEN_01 = startx
Let's look at the various parameters and what each means. The SERVER variable is the IP address of the machine on which your LTSP server will run. Nothing complicated here.
Pretty much every other variable that follows has to do with the graphical displays on the thin-client PCs or units. XSERVER generally is set to auto, but this is something you could hard code for individual workstations. The settings could be nv, vesa, ati, or any of the X servers supported by XFree86 version 4. We'll look at selecting parameters for individual thin clients in more detail when we discuss workstations in the next chapter. The next four variables (all prefixed with X_MOUSE_) are all pretty self-explanatory and relate to configuring the mouse. Meanwhile, the USE_XFS variable specifies whether the workstation will handle its own fonts or pull the information from the server's own font server.
The most interesting parameter here is SCREEN_01. The default is startx, which specifies that the workstation should boot up in a graphical X display, but there are a number of interesting possibilities. The other options are:
-
telnet: When the workstation boots up in this mode, it waits for you to press <Enter>, then starts a TELNET session to the host. Obviously, your TELNET server must be running for this. (Many offices use SSH by default.)
-
shell: This starts a local command shell, meaning local to the workstation, not to the server. From here, you could telnet or ssh to your server, or start a graphical login by typing startx. This mode is generally used for testing. It's also a great way to see the virtual Linux machine that gets created as part of the LTSP boot process.
-
rdesktop: Setting SCREEN_01 to this fires up rdesktop, a Linux-based Windows Terminal Server client, which means it uses RDP (remote desktop protocol) to communicate with and run remote Windows sessions from your Linux thin client.
How Many SCREENs?
Of course, the fact that this last variable is labeled SCREEN_01 leads up to the obvious question: What about SCREEN_02? Or SCREEN_03?
Earlier on in this chapter, I told you about running your main X session on virtual terminal session 7, while the second X session (started with an X -query) ran on virtual terminal 8. You can do something similar with thin-client workstations by modifying the lts.conf file to include more than one SCREEN definition. Here's the example from my own server:
SCREEN_01 = startx SCREEN_02 = telnet SCREEN_03 = shell
The first virtual terminal (accessible by pressing <Ctrl+Alt+F1>) runs the graphical login served up via XDMCP. The second virtual terminal (<Ctrl+Alt+F2>) runs a TELNET session with a prompt saying “Screen:2 – Press <Enter> to establish a connection to the server…” Finally, the third screen (<Ctrl+Alt+F3>) sits at a shell prompt.
In a default LTSP installation, all these screen definitions can be found in the /opt/ltsp/i386/etc/screen.d directory. Each is a shell script and easy to read and understand. You could, if you so wish, create your own screen definitions to better suit your own environment.
These types of screen modifications can be done globally or on a client-by-client basis. In the next chapter, you're going to look at just what sorts of things you can do with workstations. I'm also going to show you how you can run a not quite so thin, Linux thin client from a Windows desktop.
But first, what if you need extra help?