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