CPU Architectures

When thinking about CPU support for LTSP, you need to understand that the CPU of the thin client is entirely independent of the CPU of the server. For instance, you can run an Opteron 64-bit CPU in the server, and a 233 Mhz Pentium II CPU in the client, and everything will run just fine. The thin client will ONLY execute code that is in the /opt/ltsp/i386 tree, and the server will NEVER execute code in that area. The server only needs to be able to provide that tree to the client.

Some people also assume that the server and client both need to be running the same version of the Linux kernel. But in fact, the server doesn't even really have to be running a Linux kernel at all. The LTSP server simply needs to be able to serve up the services that the client needs. Any Unix based server should be able to do that, and in fact it has even been reported that someone has served LTSP clients from a Windows 2000 server.

x86

LTSP has excellent support for x86 based thin clients.

Power PC (PPC)

LTSP can run on Apple Power Macs !!!!

LTSP on Nubus Macintosh (5260 6100)

-- cliebow@ltsp.org

Early Macintosh clients do not have the ability to netboot directly into LTSP. They Can be used as chubby clients by placing an LTSP kernel/initrd on the local hard drive and forcing it to boot from that kernel using the mklinux bootloader. Remember that LTSP functions by mounting a file system which resides on the server. It must include binaries specific to the architecture of the Client. The architecture of the server is irrelevant as long as it can provide the essential services necessary to ltsp (DHCP TFTP NFS XDMCP). So for Macintosh we have a completely seperate file system with Macintosh binaries at /opt/ltsp/ppc on the server.Remember that this seperate filesystem is totally independent of the architecture of the server.It is only the client that mounts this filesystem as its root filesystem.

From my notes: Fresh install of mac os7.6.1 after splitting 600 meg hard drive in two pieces at install.I used pdisk to designate the extra partition as swapspace.Total overkill but..they need all the help they can get..the swap space seemed to come up /dev/hda6..Install stuffit expander so you can extract the kernel.Best to use appletalk to move the kernel from a linux box.drop the Mach Kernel.gz on Stuffit and then rename the kernel (exactly) Mach Kernel .Put this in the extentions folder. Now you need the mklinux bootloader which has four pieces.there is a control panel which goes in controlpanel..there is a config file and the bootloader itself which go in extensions (leeme check that)you can use the controlpanel to decide which system to default to.There is also a mklinux.prefs where you can manually set default os and bootdelay.I forget where it goes for now.

lilo.conf needs to be editted..mach_options=ramdisk=8192 also rootdev=/dev/ram

I ediited mklinux.prefs and set bootdelay to 3

Server side-

you need the nfsmount from YDL that Skip Gaede created..I know an ibook will run with this old filesystem.I dont know if a nubus machine will run on the modern Bill Cavalieri root filesystem (asuming you put the old /lib/modules in the new root filesystem).I bet it would.

Rather than export /opt/ltsp/i386 via nfs, export /opt/ltsp..and put the new ppc rootfilesystem parallel to the i386 one.. so youd have both /opt/ltsp/i386 and /opt/ltsp/ppc

Be sure the lts.conf in /opt/ltsp/ppc/etc has the correct server information..

Important: From my old notes i had to set aside XF86Config-4 so it was unaxailable..and make a link so ltsp would use the XF86Config generated by ltsp in /tmp.

ln -s /tmp/XF86Config /opt/ltsp/ppc/etc/X11/XF86Config

LTSP on IBM NetworkStation1000 (8362-a53)

Finally it is also possible to run LTSP on a IBM NetVista^? 8362-a53. You need a special kernel for it and a LTSP-PPC Root-Filesystem.

Please refer to the NetworkStation1000 page for more details.

-- HeGi^? - 06 Feb 2007

Connecting to ltsp server via os9 and wierdx as implemented by sn9 9-21-05

If you can't give up the ol' os9 here's a way to install an X-server so youn can contact an ltsp-server and get a login/session.

LTSP on Latter Day Macintosh (G3 Emac g4 Ibook)

New Age Macintosh have as their foundation an os called openfirmware which is written in Forth.These machines are capable of being a true ltsp thin client, by enabling the ethernet card, downloading a kernel from a server, mounting an NFS file system and receiving a desktop as if they were working directly on the server. So on to the nitty gritty. You need the identical services running as for regular ltsp on i386.(dhcp tftp nfs xdmcp) so I will not reiterate that..*BUT* there are several items in dhcpd.conf which need to be there to get a Mac to netboot.

One is pointing your client to mount the Macintosh specific file system typically placed in /opt/ltsp/ppc.

option root-path "192.168.0.254:/opt/ltsp/ppc";

The other is to add to your dhcpd.conf the code to pass options 43 and 60 to the client. These options were placed in the global section of my dhcpd.conf to get Macintosh to initiate tftp transfer.I don't see any reason why they couldn't be put in a section specific to one client.

Jim Macquillian has developed a small addition to dhcpd,conf which will interpret the dhcp response from the client and switch root-path for you..Will try to put that up here as well.

option routers 192.168.0.1;
option dhcp-parameter-request-list 1,3,6,15,17,43,44,46,60;
filename "yaboot";
erver-name "imac4";
option vendor-class-identifier "AAPLBSDPC";
option vendor-encapsulated-options 01:01:02:08:04:01:00:00:01:82:
         05:                                    # length
         69:6d:61:63:34;                           # hostname

It may be necessary to add a stanza for each Macintosh client.Early open firware seems to only support a bootp type response and won't pick up a random address.

host mac {
   hardware ethernet 00:50:e4:66:54:7c;
   fixed-address   192.168.0.253;
}

With this addition to dhcpd.conf you should be able to boot from a linux server all the way into ltsp.I have found two ways to do this..The first requires that you manually enter openfirmware using the cmd-option o f key combination. Assuming you have no openfirmware password you may simply type at the ok> prompt boot enet:192.168.0.254 where 192.168.0.254 is the ip address of your server..

The client dutifully downloads (from /tftpboot) yaboot which is a bootloader for Macintosh .It in turn downloads yaboot.conf which passes the name of the kernel and initrd to yaboot. The kernel downloads, executes and creates the initrd. From there a linuxrc takes control just as it does for i386 clients.

Here is my yaboot.conf.

timeout=30
init-message="Lumensoftware Terminal Server"
default=linux

image=vmlinux-ppc-2.4.22-ltsp-1
   label=linux
   initrd=/initrd-ppc-2.4.22-ltsp-1
   append="init=/linuxrc rw root=/dev/ram0"

Once you are comfortable with this first method you can from osx change your startup disk in system preferences to network and the entire process will be automatic.This can be also be set directly from openfirmware as well I have not been successful using a third method--holding down the N key at startup so far except with the Bondi puke-green desktop models. . The final consideration is altering the lts.conf within your /opt/ltsp/ppc/etc folder..Here is mine..For some models it will have to be tweaked to load the glx module to get X working properly.

[00:03:93:a7:1f:ba]
XSERVER=fbdev
[mac]
   XSERVER = ati

So a g4 uses the ati driver very nicely and even an fbdev driver works for and ibook. An emac or fruity g3 probably need the glx module.. So where to get the pieces? As soon as i get the go-ahead from Bill Cavalieri who created the kernel, initrd and nfs file system we will let you know where to download them. I understand the new 4.1 ppc nfs file system is nearing completion as well.. cliebow@ltsp.org

Using Windows dhcp to boot a G3 to ltsp

option 17 10.10.10.254:/opt/ltsp/ppc
option 43 01 01 02 08 04 00 00 01 82 05 69 6d 61 63 34
option 60 PXEClient
option 66 10.10.10.254
option 67 /yaboot
option 211 74:66:74:70

add options using netsh for options not normally in dhcp .Get a command prompt

netsh
dhcp server
add optionDef 211 BootProtocol STRING

Windows pads option 17 with three zeros so from command line on your ltsp server ln -s /opt/ltsp/ppc /opt/ltsp/ppc000. Yaboot expects to find yaboot.conf in the root of the tftp chroot. I use server_args = -s / because of my netvistas so that is why my "filename" statement looks weird. cliebow@ltsp.org

-- Note Added by RaphalRIGNIER - 20 Jan 2006

Modifying the build_x4_cfg script

Since generaly a Macintosh keyboard is plugged into the terminal, the script should set macintosh Keyboard Model by Default (or at least recognize the XKBLAYOUT option in lts.conf).

edit the /opt/ltsp/ppc/etc/build_x4_cfg file, and bellow the lines :

Section "InputDevice"
       Identifier  "Keyboard0"
       Driver      "keyboard"
       Option      "XkbRules"  "${XKBRULES:-"xfree86"}"

Add this line :

       Option      "XkbLayout" "${XKBLAYOUT:-"macintosh"}"

This should be done in LTSP-PPC tarball.

-- End note -- RaphalRIGNIER - 20 Jan 2006

Getting the LTSP-PPC tarball

The tarball can be had at http://grammacams.com/apple.tar.gz. There are a lot of shakeups on my network so please let me know if the link reaks.. cliebow@ltsp.org

Automatically setting root-path, based on CPU

You can have the PPC workstation automatically determine the correct root-path by following this document: DHCP#How_to_automatically_pass_the_co

SPARC

LTSP on SPARC architectures

If you want to use Ultra SPARC machines as LTSP clients see http://math.univ-lille1.fr/ltsp-sparc/

There are two ways that I know of to deal with multiple CPU architectures. One way is to pass the vendor string and point to the right directory, per the above and another section in this Wiki. Since I didn't know how to do that and, at that particular time, didn't have time to learn, I happen to use a separate NIC per CPU architecture. Fortunately, I had the IRQ's available in my LTSP server to handle multiple NICs. My SPARC clients are thus in a separate VLAN on my switch. By the way, part of these instructions might also help you if you need to use an IP subnet other than 192.168.0.0/24 for your clients. I used 172.16.3.0/24, since my network at home already uses 192.168.0.0/24, and I was getting some routing problems. The LTSP (in my case, K12LTSP) server's NIC for serving up to my SPARCs uses 172.16.3.254 and is a Gig-E copper NIC.

What I did was pop another NIC in and edit lts.conf file to reflect my subnet:

  SERVER = 172.16.3.254
  DNS_SERVER = 172.16.3.254

I did not have to make entries in the LTSP server's /etc/hosts file.

Then, I made a new DHCP scope for the SPARCs. I simply copied the existing one that came with LTSP to a new scope, gave it a name, replaced 192.168.0 with 172.16.3, and I was pretty much good to go, IP address-wise.

I also needed to modify two lines in the file /opt/ltsp/sparc/etc/lts.conf in order for the mouse to be recognized.

  X_MOUSE_PROTOCOL   = "PS/2"
  X_MOUSE_DEVICE     = "/dev/psaux"

My changes for my Ultra 5's were the following.

  X_MOUSE_PROTOCOL   = "busmouse"
  X_MOUSE_DEVICE     = "/dev/sunmouse"

So far, so good.

Now, the tricky part comes. First, you've got to update OpenBoot^? to v3.31 if it isn't there already. It was in v3.31 that DHCP booting became supported in addition to the old RARP method. This version can be found on Sun Microsystems' Web site; it is Patch ID #106121-18, dated May 15, 2002. It comes as a ZIP archive, so just un-zip it and put "flash-update-Ultra510-latest" in the root directory. NOTE: there is a caveat that you need to know about before you do this if, like me, you've got, say, GNU/Linux or *BSD installed on your UltraSPARC^?'s hard disk.

The instructions for updating the firmware tell you that it doesn't matter which OS is on the box; Sun even says that "the absence of a valid Solaris or SunOS^? release does not preclude the installation of this patch against the hardware." This is false; you've got to have Solaris installed on the hard disk to run the flash updater program. My guess is that it's because the Solaris boot loader likes the firmware updater program better than SILO does. With GNU/Linux and SILO installed, when you run the OB updater, you get a "FATAL ERROR" message saying that the ELF binary has more than one entry point, so sorry, better luck next time. Looking for a way to do this with a Free Software OS instead of Solaris, I then installed OpenBSD^? and tried updating the firmware, but sadly, a similar error pops up with OpenBSD^?'s boot loader. Oh well, it takes about 40 minutes to install Solaris 8 on these boxes. I did so with one hard disk, popped the firmware updater program in the root directory, and used that hard disk for all of my other Ultra 5's. This saved several hours.

Once all this is done, I fired up the Ultra 5, hit Stop-A, and issued the following command at the OpenBoot^? prompt:

  ok> boot net:dhcp

upon which this "old" UltraSPARC^? came right up with the K12LTSP login screen. The UltraSPARC^?'s hard disk can now be removed. To make the UltraSPARC^? do netbooting with DHCP by default (remember, the factory default for netbooting is BOOTP/RARP, which doesn't work here), you set your boot environment variable, like so:

  setenv boot net:dhcp

which will cause the UltraSPARC^? to always boot via the network, using DHCP. Since Ultra 5/10's built-in network ports support 100BaseTX/FullDuplex autonegotiation, you have a client that feels nearly as fast as an x86 thin client. That also means that, if you've got fifteen UltraSPARC^? thin clients playing something like TuxMath^? or TuxType^?, you'd better have Gig-E on your server!

The only thing bad that happens today is that TuxType^? crashes with an X11 opcode error, though TuxMath^? doesn't. I believe that this is because the X11 version currently being used on the client is an early release candidate of XFree86 4.4.0 and not the final version. I imagine that a later version of XFree86 or X.org would work fine; I just haven't had time to compile it and try it yet. Recall above that I had previously had Red Hat Linux 6.2 for the UltraSPARC^? installed on one and simply popped "X -query 172.16.3.254 &" at the end of /etc/rc.d/rc.local. Why such an ancient version of RHL? It works, that's why. The nice part for software testing purposes is that RHL 6.2 has XFree86 3.3.6, which, as it happened, allowed me to see if I could reproduce this issue with an older X11 version. TuxType^? was happy as a clam with 3.3.6. TuxMath^? didn't seem to mind either way, though. Ah well, hardly a show-stopper, since there's a workaround until we get around to compiling a newer X11 version for SPARC clients.

The end result: I now have a single K12LTSP server that can netboot x86, PMac 52x0, and SPARC boxes as thin clients...simultaneously. How? I have four NICs in this box--three inside, one outside, like so.

eth0 = inside, 172.16.0.254/24, Gig-E fiber (x86 terminals)
eth1 = outside, DHCP, 100BaseTX copper (to the main bldg. LAN)
eth2 = inside, 172.16.2.254/24, 100BaseTX copper (PMac 5260 terminals)
eth3 = inside, 172.16.3.254/24, Gig-E copper (Ultra 5 terminals)

Each of these subnets and NICs is sitting in its own VLAN, and all the thin client subnets are being served by dhcpd on the K12LTSP server. Life is good.