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