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

[John Finlay]

Mike Perkins wrote:
> 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.
>
The last time I looked at the Mythbuntu diskless setup it looked like it 
used LTSP for setup but set up fat clients not thin ones so all client 
processing is on the client. It uses nfs file system overlays to allow 
each client to have different configurations overlayed on the common 
filesystem image. I found Mythbuntu diskless setup realtively easy 
especially since MCC does all the hard work. Why switch if it works?

John