[mythtv-users] restricting mythpreviewgen?

Alex Williamson alex.l.williamson at gmail.com
Tue Jan 22 18:48:35 UTC 2013


On Tue, Jan 22, 2013 at 11:19 AM, Raymond Wagner <raymond at wagnerrp.com> wrote:
> On 1/22/2013 12:38, Alex Williamson wrote:
>>
>> On Tue, Jan 22, 2013 at 10:22 AM, Raymond Wagner<raymond at wagnerrp.com>
>> wrote:
>>>>
>>>> On 1/22/2013 12:07, Alex Williamson wrote:
>>>>
>>>> Because I want different, isolated environments on a consolidated
>>>> system.
>>
>>
>>> Why not use chroot, or something like LXC?  Both offer isolated
>>> environments, allowing you to manage multiple system images without risk
>>> of
>>> interference from conflicting packages.
>>
>>
>> hdpvr requires kernel modules, including the ir module from the
>> staging tree.  That means a container doesn't really improve my
>> overall system uptime if I still have to reboot the host for a driver
>> glitch.
>
>
> It's a kernel module. You unload the old one and load the new one in place.
> No reboot is needed.

Sure, can I have your phone number for my wife to call for support
when she needs to login and reload the module vs flipping a switch on
a power strip.  And of course usb devices never fail with bus errors
after the driver hangs.  This is why I'm abandoning virt for this
aspect, even if I can make it work 99% of the time, fixing it that 1%
when I'm not around is not worth the frustration.

>>>> Isn't that why people generally use virtualization?
>>>
>>>
>>> No. They use virtualization because they need to run multiple separate
>>> operating systems (like Linux and Windows), are doing development and
>>> can't
>>> risk a kernel panic bringing down the whole thing, or can't risk one
>>> hacked
>>> server compromising the whole system.
>>
>>
>> Look, I'm pretty familiar with virtualization and I'm not looking for
>> an argument about why I've chosen this or that.
>
>
> You chose to use a system architecture that is the fundamental cause to a
> series of compounding issues. I'm merely trying to get you to reconsider
> your reasons for choosing full machine virtualization and the issues it is
> causing, rather than continue to stack on workarounds as you meet them.

Well, IMHO my use of virtualization meets all your requirements.

1. run multiple, separate operating system

Check, RHEL != Ubuntu, different kernels, different release cycles,
different stability, different userspaces

2. doing development, can't risk kernel panic bringing down the whole thing

Check, mythtv is a far less stable environment that I don't want
bringing down my server

3. can't risk one hacked server compromising the other

Check, my mythtv setup is far less secure than the host environment.
I'll be annoyed if a hacker breaks into my home network and deletes my
recordings.  I'll be much less forgiving if they break into the server
and compromise real files.

MythTV supports slave backends and I'm trying to make use of that.
What if my master wasn't a vm, but was in a location where I couldn't
physically connect the hdpvr, would you still concentrate on trying to
redesign my environment?

>> I can restrict other jobs to not run on this slave, can or can I not
>>  restrict mythpreviewgen?
>
>
> Mythpreviewgen is not a job that runs through the jobqueue, and thus cannot
> be restricted to a single host in the manner that the other tasks can. It is
> always run by the backend that owns that recording. Assuming your slave
> backend has no storage of its own, and records to shared storage on your
> file server/master backend, your only real option is to have something run
> after recording is finished to change ownership of that recording to the
> master backend.

Now we're getting somewhere, thank you.  A mysql cron script wouldn't
be too hard.  Alternatively I was thinking about replacing
/usr/bin/mythpreviewgen on the slave with a script that just does an
rsh of the job to another system.  Your idea might be less tedious to
maintain though.  Thanks,

Alex


More information about the mythtv-users mailing list