[mythtv-users] Mythbuntu 9.04, Boot On LAN, DHCP c\o pfSense

[Mike Perkins]

Tortise wrote:
> ----- Original Message ----- From: "Mike Perkins" 
> <mikep at randomtraveller.org.uk> To: "Discussion about mythtv" 
> <mythtv-users at mythtv.org> Sent: Sunday, October 25, 2009 1:24 AM Subject: Re:
>  [mythtv-users] Mythbuntu 9.04, Boot On LAN, DHCP c\o pfSense
> 
> 
> Tortise wrote:
>> Finally got this booting
>> 
>> Server MCC: Diskless Server: Select CPU architecture of your clients: i386
>>  Apply  (Wait hours!) Choose image i386 Commit changes (use the underlying 
>> defaults)
>> 
>> pfSense: DHCP Server serving IP's to named MAC addresses Enable Network 
>> booting Server address: {Whatever} Enter the {ERROR =IP address from the 
>> network boot server} boot image reference:   /ltsp/i386/pxelinux.0
>> 
>> Frontend(s) Enable PXE boot on LAN function (details depend on system - 
>> either using motherboard BIOS if there or BootonLAN capable NIC) Seem to 
>> boot into a generic image.
>> 
>> At the moment I have two diskless front ends and both will boot at same 
>> time.  Kewl.
>> 
>> Presumably they each have their own Desktop, file set, config etc(?)
>> 
>> Now need to presumably configure each with vdpau etc.  I guess I have to 
>> add in JYA's repo into synaptic with his keys etc into each frontend.
>> 
>> Nice to get rid of the greatest FE noise, the HDD's.  Boot speed is also 
>> better than HDD, which was a pleasant surprise!  Some smarts don't seem to 
>> be there, for example typing sensors usually gives a prompt telling what to
>>  install, however not so in the images.
>> 
> 
>> You probably ought not to be booting LTSP clients if you want them to run 
>> mythfrontend. Since all LTSP processes effectively run on the server, you 
>> would
> be faced with running several mythfrontends on the same host, which could get
>  interesting. ============== I am not sure this is correct?  Seems to me the 
> image is downloaded and run with all the processes being run on the FE?  ltsp
>  just happens to be the directory that the diskless FE is under, not sure
> that makes it ltsp?
> 
> 
>> Not to mention, LTSP uses the remote X functionality to display the 
>> desktops on the thin clients, and myth does too much for that to work 
>> properly.
> I know, I've played around with that in the past. 
> =============================== Again I am not sure this is a true thin 
> client configuration, I note there are two distinct image file sets under 
> /var/cache/mythbuntu-diskless/overlay/ If it were a true thin client 
> situation, wouldn't all the vdpau stuff be run on the server, and the 
> changing images sent over the LAN - and the LAN wouldn't have the capacity to
>  send 1080i yet this plays fine on the FE, suggesting to me most of the work
>  continues to happen on the FE.
> 
>> It is perfectly possible to serve both from the same system, however. I run
>>  a host which serves both LTSP clients and a diskless mythfrontend.
> 
> 
> I think you should be booting minimyth (http://minimyth.org/) for your front
>  ends. ======================== OK, why?
> 
> It is a relatively straightforward matter to add in the required files 
> alongside those installed by the LTSP functions. You would also need to add 
> extra lines to dhcp.conf to handle your dedicated mythfrontend clients. 
> Because of this, I don't let my pfSense firewall run the dhcp, it's all 
> handled by the master server, which in any case has to run tftpboot and other
>  services for the thin clients. This has the added advantage of keeping the 
> configuration all on one machine. ======================= Running diskless 
> seems to conserve all config files on the server also.  Server CPU load seems
>  unaffected to brief testing.  What's the distinction you see?
> 
> pfSense seems ok as dhcp server in default form , so long as there is only 
> one boot file server.  More would get interesting.
> 
> I appreciate you input Mike, thank you.
> 
(i) Of course there is an image downloaded from the server to the thin client.
What you should have running on the thin client is a bare-minimum system just
capable of running X and forwarding mouse and keboard info back to the server.
This allows you to remote-login to the server and run things, which happens *on
the server*. Only the X output is forwarded to the client for display, hence
"thin client".

My thin clients go from power-switch to logon screen in ~35 seconds. If your
system takes much longer, it's probably not a thin client. One of my thin 
clients is an ancient K6-2/366 laptop with 32M, works fine.

(ii) You probably couldn't get vdpau running on the server unless the server had
a vdpau-capable graphics chipset in it. It certainly wouldn't work over the
network, because vdpau talks directly to the graphics chipset of the host which
is doing the displaying.

If you are, actually, running vdpau on your front ends, I would suggest that you
aren't running a true ltsp client, but just remote-booting a fat client. If
you're doing that, I still suggest you have a look at minimyth, since all the
hard work will have been done for you, vdpau included (thanks, Paul!).

(iii) As I have a mixed system of servers, ltsp thin clients, myth front ends 
and occasional guest laptops, I felt I needed to have a little more control over
dhcp configuration than pfSense provides as a default. For example, I have
groups defined so that I don't have to repeat lines for boot files, next-server
and such for every host.

It's possible that recent pfSense versions offer more flexibility than I
realised, I haven't looked for a while. My dhcp setup has been running on my
master server since about 1998, so I haven't seen a need to change.

(iv) If you're using pfSense for dhcp, and running tftpboot (or whatever) on
another host, your configuration files are *not* on the same system, you have to
co-ordinate between the two (or more), and this can be where errors creep in.

-- 

Mike Perkins