147
edits
Changes
From SME Server
Jump to navigationJump to searchno edit summary
{{Note box|Future mythTV versions (any later then 0.20.2) will NOT work with SME Server 7.3 since MySQL version 4.1 is the default version with default SME Server 7.3 (MySQL updates not foreseen yet) and newer versions of mythTV *require* at least MySQL version 5.x.
{{Note box|Future mythTV versions (any later then 0.20.2) will NOT work with SME Server 7.3 since MySQL version 4.1 is the default version with default SME Server 7.3 (MySQL updates not foreseen yet) and newer versions of mythTV *require* at least MySQL version 5.x.
ATRPM no longer has Myth 0.20.2 which is the last version that supported mysql4. Christian does have these rpm's and can make them available if you need them until SME server 8 is ready. Alternatively, and this is not recommended, you could upgrade to mysql5.
ATRPM no longer has Myth 0.20.2 which is the last version that supported mysql4. Christian does have these rpm's and can make them available if you need them until SME server 8 is ready. Alternatively, and this is not recommended, you could upgrade to mysql5. Another alternative is to run the SME Server as a Slave backend and have the Master backend running in a virtual machine on the SME using for example VMWare. This is also documented in this How-to under "Configured as a Slave Backend".
Also note that for the ivtv modules, that they do depend on the kernel version. You may be in a situation where the supported ivtv module depends on a kernel you do not have. Chances are over time, that the next SME update will provide the kernel you need. If you are in a hurry, you will need to update your kernel to a matching version. Do this only if you are confident in what you are doing and its impact.}}
Also note that for the ivtv modules, that they do depend on the kernel version. You may be in a situation where the supported ivtv module depends on a kernel you do not have. Chances are over time, that the next SME update will provide the kernel you need. If you are in a hurry, you will need to update your kernel to a matching version. Do this only if you are confident in what you are doing and its impact.}}
You should only have to install the new kmdl for ivtv using:
You should only have to install the new kmdl for ivtv using:
yum install ivtv-kmdl-`uname -r` --enablerepo=atrpms --enablerepo=dag
yum install ivtv-kmdl-`uname -r` --enablerepo=atrpms --enablerepo=dag
===Configured as a Slave Backend===
====Rationale====
An alternative to using the SME Server as a Master Backend is to configure it as a Slave Backend to another Mythtv Master Backend Server. There are many ways to organize this and the reader should review the MythTV documentation to determine how they wish to implement it.
An advantage to using the SME Server as a Slave Backend is that a delegated Master Backend can house most of the enhanced functionality including mythweb, MySQL5, and a variety of plugins while keeping the SME Server implementation minimalist.
In my case I run the Master Backend as a Guest application in VMWare running on SME Server. This allows MythTV to run autonomously and I use the SME Server OS only to manage the video capture cards.
====Steps====
The reader should become familiar with MythTV's architecture before implementing this. In essence the steps are as follows:
* Configure Master Backend
* Configure Video Sources on Backend
* Install Mythtv per above Installation instructions EXCEPT for MySQL step. MySQL will run on the master backend.
* Make the needed config changes noted below
* configure needed shared mount points so Master, slave, and frontends all have the same path to shared directories.
* Run Mythtv-setup pn SME Slave as per X-11 Forwarding instructions above
** Under General Settings validate that the IP Address of the Master Backend is correct and that SME's address is defined for this server
** Define capture cards
** Slave Backend should pick up the Video Sources from the Master Backend automatically
** Configure the Input Connections
If there are situations where the Master Backend will come up after the Slave then you will need to kick the slave to restart mythtvbackend when the master comes back on line. This may be a polled mechanism on the slave using cron (such as is used in MythDora). Or it may be an explicit command given by the master when it starts up.
====Config Changes====
The main change is to have Mythtv on the SME Server look for the database on the master backend. This change is made in the '''mysql.txt''' file and is usually located in any of:
/var/lib/mythtv/mysql.txt
/root/.mythtv/mysql.txt
/home/mythtv/.mythtv/mysql.txt
If you followed the above How-To, it should be in the first one. This change is important otherwise you will get bizarre failures where the Slave sees the Master but not the other way around.
Change the first line "DBHostName=xxxx" so that xxxx is the DNS name or IP address of the master backend
====Enable Master to wake up Slave====
If the Slave starts before the master then it will not find the database and mythbackend will terminate. These instructions show you how to use the Master to wake up the slave. An alternative would be to have the slave poll for mythbackend not being active and attempt to revive it periodically.
{{Warning box|It is important that you are comfortable with the following instructions. Improper implementation of this mechanism can lead to a security breach. Other weaknesses in the Mythtv distro of your choice that may allow a breach to its own root could theoretically allow a hacker to access the root of the Slave (ie. SME Server). Implement this mechanism only if you feel comfortable doing so.}}
First you will need to give the master authority to log in to the slave. This can be accomplished by following the SSH Key Howto at http://wiki.contribs.org/SSH_Public-Private_Keys. Specifically steps:
http://wiki.contribs.org/SSH_Public-Private_Keys#On_SME_Server and http://wiki.contribs.org/SSH_Public-Private_Keys#Installing_the_Private_Key_onto_the_Clients
You can do this to allow the master's root user to log into the slave's root user. Test that it works by executing from the master "'''ssh slaveAddress'''". If you did it correctly, no password will be required.
Next you will want to create a script in a directory readable by the mythtv user but only writable by root. For example /root. The script (call it SlaveRestart) will contain
ssh root@SlaveAddress /etc/init.d/mythbackend restart
ensure the file is owned by root exclusively and has only read/execute permission for mythtv. Example:
chown root:root SlaveRestart
chmod 555 SlaveRestart
Next is to modify /etc/sudoers. You will need to temporarily allow root permission to write this file.
chmod u+w /etc/sudoers
edit the file and add ",/root/SlaveRestart" to the end of the list of "mythtv" allowed commands. Remember to remove write permission on the file:
chmod u-w /etc/sudoers
{{Warning box|The permissions of the script and directory it is in are important to ensure that this script file can not be modified by someone to create a trojan horse running as root. Test from user mythtv to verify it can not be modified.}}
Now, running mythtv-setup on the master backend, enter the "General" settings and advance to the "Shutdown/Wakeup Options" page. In the field "Startup Command:" enter "sudo /path/to/SlaveRestart".
You can verify that it works both from the command line of the master running as mythtv and by terminating the mythtbackend on the slave, restarting the mythbackend on the master, verifying the slave's mythbackend restarted successfully.
===Installing Mythweb in an Ibay===
===Installing Mythweb in an Ibay===
