Modern tools.
Traditional dedication.
Home
| Purpose
| Linux
| Products
| Legality
| Special
| Downloads
| Articles
| Contact
You will require:
Run Mandrake’s Terminal Server wizard (as root): drakTermServ.
Click on the First Time Wizard button, then OK.
Click on the Use thin clients checkbox (then the OK button on the dialog which pops up) and Next button.
The panel should be filled out according to the specs of your LAN; if it’s connected to a typical NATted DSL, the parameters would be:
| Parameter | Value |
| Network address (“Subnet”) | 192.168.1.0 |
| “Netmask” | 255.255.255.0 |
| Default route (and all else; “Routers”) | 192.168.1.254 |
drakTermServ thoughtfully pulls these values (and more) from your running system, but depending on how it’s configured, they may be wrong. The values are about to be applied to the DHCP (automatic address) server for your workstations. If these values are right for you, the rest of the parameters on the page should have values more or less like the following:
| Parameter | Value |
| “Subnet Mask” | 255.255.255.0 |
| “Broadcast Address” | 192.168.1.255 |
| “Domain Name” (inside your LAN) | whatever |
| “Name Servers” | 192.168.1.254/blank/blank |
| “IP Range Start” | 192.168.1.100 |
| “IP Range End” | 192.168.1.199 |
Click Write Config then Next (and OK on the small dialog which appears, and yes, it really will take a few minutes; it’s building separate boot kernel images and RAMdisk images for circa 60 different kinds of network cards).
Big pause... then click Next, Next, Next, Next, and now we get an opportunity to make some boot floppies, CDs or PXE images if we need them.
Most people won’t, but in my case one of my clients was a laptop with a (built-)broken RTL8139; the first thing this braindead device does is identify itself . . . and then tack some semi-random crud onto the end of the ID string, which made it difficult for the PXE software to figure out which boot file to send it. This was cured by giving tftpd a remap option and file (I chose /etc/tftpd.remap), by adding “ -m /etc/tftpd.remap” to the server_args line in /etc/xinetd.d/tftp.
The remap file looks like this (the idea was pulled from a mailing list post found with Google and kept in its cache):
# strip ending garbage from filenames (Realtek PXE bug) r ^(boot-8139[[:graph:]]*)(.+)$ /eb-5.2.5-rtl8139.zpxe
In short, remap any graphic string starting with “boot-8139” and followed by junk to point to a PXE-to-Etherboot file (which we generate here).
And why not remap it to the kernel it needs straight away? Well, I’m glad you asked: because this never-to-be-sufficiently-condemned device then turns around and says that there’s not enough memory (like, only 512MB) to load the kernel into. So we bounce through Etherboot, which takes an extra fraction of a second but gets us clear of the Realtek bugfarm.
We also have to add a coping mechanism to DHCP to deal with this, a belt-and-braces approach, in the form of a sub-stanza like this inside the “class "PXE"” stanza in /etc/dchp.conf:
host laptop {
hardware ethernet 00:0A:E4:20:40:65;
fixed-address 192.168.1.25;
if substring(option vendor-class-identifier,0,9) = "PXEClient" {
filename "/eb-5.2.5-rtl8139.zpxe";
} else if substring(option vendor-class-identifier,0,9) = "Etherboot" {
filename "/boot-8139too.2.6.3-7mdk.nbi";
}
}Such is the penalty for paying too little for one’s laptop – that and a memory-stick controller card from WinBond (anybody remember penny-pinching VL-buss IO cards with buffered 16450s masquerading as real 16550s? Same crew) with zero documentation and so no Linux driver (Linux doesn’t even admit to it existing, which at least shows good taste.
Oh, yes. Click Next.
When drakTermServ offers to restart the display manager, the safest answer is No. Restarting the Display Manager would take your current X session and all of the programs you have open in it (probably including a browser showing this text) and all of your remote sessions et al with it – if you logged in graphically. You can do the same thing later from a command line by typing service kdm restart (or gdm, if that’s what toots your whistle, but kdm is the default).
You are now, in principle, done. In reality, there will be some tweaking to do.
If your server and workstations are based around related chipsets, you possibly really are done. In my case, the server ran an ATI video card on an nVidia motherboard chipset (nForce2 sucks), the workstations a variety of chipsets including the above-mentioned laptop’s Intel chipset.
In most cases, the server will run one chipset, most of the workstations will run another, and a few workstations will dare to be different.
I handle this with ClusterNFS features by creating /etc/modules, /etc/modules.conf and /etc/X11/XF86Config-4 (this will change to something like /etc/xorg.conf with Mandrake 10.1) for the server, then another set /etc/modules$$CLIENT$$, /etc/modules.conf$$CLIENT$$ and so on for the most common workstation configuration, then nail specific network cards to specific addresses in dhcp.conf with stanzas not unlike the one used for the laptop above. I then create /etc/modules$$IP=192.168.1.25$$ and so on with matching contents.
ClusterNFS does the rest. The hardest part is remembering to escape the $$ (as \$\$ or by enclosing the whole name in apostrophes).
Terminal Server works in two basic modes. In “thin” mode, the workstations run just an X display server locally, on a network mount from the server. This display server connects to the main machine’s KDM (or whatever) service and logs in there, so the applications are all run on the actual main machine, and the workstations are being only a display (keyboard, mouse).
This is perfect for recycled 486es (in real life, recycled Pentium Is and Pentium IIs) but anything which pounds heavily on the screen (games and 3D applications) is going to work poorly if at all, and sound (if any) will be emitted at the server end (sad for audio and video programs). On the bright side, memory is shared very efficiently and programs load very fast, especially for computationally weak workstations.
“Fat” mode runs a local copy of KDM, logs in through that, and runs everything locally, over the network mounts. This makes programs slower to start (they have to be loaded over the network) but faster to display (no network lag), and everything like sound, 3D, high-bandwidth graphics and local devices work as normal. No memory sharing occurs and the workstations need more memory and processor power, but the server doesn’t need so much memory (or processor) to do its job.
To flip between thin and fat mode, change the last line of /etc/inittab$$CLIENT$$. Thin looks like this:
x:5:respawn:/usr/X11R6/bin/X -ac -query 192.168.1.254
Alter IP address to suit taste (ie, point it at your server). Fat looks like this:
x:5:respawn:/etc/X11/prefdm
Opportunity is missed by most people because it is dressed in overalls and looks like work. — Thomas Edison
Last changed: 09-Sep-2008 10:29:30 Find out who links to this page. Verify for yourself that this page is pure, standard HTML, not Ruby.
If you would like us to read email for
USD$1000 per page, payable in advance, send it here.