>>>>> Have you considered using PXE to network boot your systems? you can >>>>> have various configurations set up based on mac addresses to address >>>>> different hardware issues. I recommend trying out SystemRescueCD to >>>>> experiment with PXE booting for the client and server. >>>> >>>> That sounds like exactly what I need. So, I could set up a Gentoo >>>> server and a bunch of completely diskless clients which would all PXE >>>> boot from the server? Would the clients basically each control a >>>> different virtual terminal on the server? >>> >>> Each machine can pull a copy of the master boot image to make updates >>> a lot simpler. The SystemRescueCD PXE boot mechanism just pushes out a >>> copy of the CD to all the machines to boot them. to update the boot >>> image just update the files in one location to update all machines. >>> the machines act as separate fully functioning machine. Check out >>> http://www.sysresccd.org/Sysresccd-manual-en_PXE_network_booting to >>> see how to setup the PXE boot environment. >> >> I think I get it now and it sounds great, exactly what I'm looking for. >> >> Everything can be done in RAM, no disks required? >> >> Can PXE boot be done wirelessly? Maybe only if the wireless is >> onboard? I tried to Google this but the info returned is terribly >> outdated for some reason. >> >> Do you think SystemRescueCD is the best boot image for clients that >> only need a browser? >> >> What sort of machine would work well as a client? Should I just put >> together a bunch of motherboards with onboard video and ethernet, >> CPUs, RAM, PSUs, and small cases? Is there a prebuilt system that >> works well for this? Maybe an ARM-15 system as "Tampa Bay" James >> referenced, although I think that isn't released yet. >> >> - Grant > > Well, the first thing you need to decide is whether you want each > client running that browser locally, or whether you want each client > to merely provide an interface to the server, and every user's browser > (and every other application) running on the server itself. If your > clients boot, then run all their own software locally, your server's > under only under load during boot-time and your clients need to be > able to handle that work (not much, but it's more than nothing, just > try running a modern Firefox on 64MB of ram). On the other hand, if > your clients merely boot into a remote connection to the server, a la > VNC or NX, the client does *very* little locally, can run on next to > nothing hardware-wise (a true 'thin client'), and the entirety of the > workload is offloaded to the server. If you want responsive 'eye > candy', 3D graphics work/play, or any form of particularly 'smooth' > animation, you will want that work to be handled on hardware closer to > the user (requiring a far faster processor, more ram, a capable video > device, and likely local storage for swap at the least), while serving > up a simple browser to the user is far more forgiving.
After reading this, my first reaction was to run the browser on the server and have each client connect via VNC/NX. Now that I think about it, I may be better off running the browser locally for simplicity's sake. I always try to keep the number of layers I'm dealing with to a minimum and VNC/NX is one layer I could do without if I beef up the clients a bit. How different would the client hardware requirements be between running the browser locally and running it via VNC/NX? I suppose I could also do without the PXE layer and all of its requirements if I install some sort of minimal storage device (flash drive, SD card, USB key, etc.) into each workstation for the boot image. I could still push updates to the boot image over the network almost as easily as updating the single boot image on the server. What is the benefit of loading SystemRescueCD instead of another monolithic "just work" distro like Ubuntu? > As for wired vs wireless, true hardware PXE booting is generally > limited to wired scenarios, but it would be entirely possible (though > not truly 'diskless') to deploy a minimal kernel+initramfs that > handles initial booting, joining WiFi, pulling down of the system > 'image' from your server, and handing control off to that in the same > way your run of the mill kernel+initramfs loads hardware drivers until > it can find the harddrive, attaches to the root partition, and hands > off control to init from there. Changes to the wireless configuration > would require directly visiting each client, and client-side kernel or > initramfs updates easily could as well, if things don't go as planned > (but, since all the user-side software is either run on the server or > loaded from it at boot-time, changes to the client's "loader" > shouldn't be frequent). It sounds like I should stick with ethernet for simplicity's sake. > There's also the option of pre-made hardware thin clients that > typically boot from internal flash and simply provide a remote > interface to a central server (though most are geared towards RDP or > Citrix), and some are even WiFi capable. A pre-made thin client could be the way to go. Do you know of any that are geared toward open protocols? - Grant > Poison [BLX] > Joshua M. Murphy
