[mythtv-users] Upgrading from pre-0.22 MythTV versions

[Mike Perkins]

On 30/03/12 04:31, Raymond Wagner wrote:
> On 3/29/2012 23:09, f-myth-users at media.mit.edu wrote:
>> For some reason, I was assuming that upgrades might happen where a
>> frontend (or mythtv-setup) talked to (the wrong) backend and then told
>> the (wrong) backend what to do to upgrade the schema, rather than
>> using a direct connection to the DB. In that case, the (wrong)
>> backend already knows the password and hence can corrupt the
>> production DB. Is this impossible?
>
> That should not be possible in 0.24 or 0.25. In 0.24, `mythtv-setup` on any
> machine is allowed to update if authorized by the user through the UI,
> `mythfrontend` is allowed to update only if a certain command line flag was
> passed to it, and `mythbackend` is allowed to update only if it is the master
> backend. If the master backend is run detached from an interactive terminal, the
> update will be performed automatically. Otherwise, the user is asked whether or
> not to upgrade on the terminal. In 0.25, `mythfrontend` is never allowed to
> update, and all other behavior remains the same.
>
> That means there are two potential routes for trouble. If the user installs a
> second, newer version of MythTV on the master backend, and either runs
> mythbackend from the same user account or the older version is still running and
> passes the database credentials over UPNP, the new backend will think it is the
> master and proceed to update the database. If the user installs a newer version
> of MythTV anywhere on the network, and detects the wrong instance of MythTV over
> UPNP, they could tell mythtv-setup to upgrade the wrong database. In either
> case, MythTV will find somewhere to make a database backup, allowing the mistake
> to be reverted.
>
Looking forward, may I suggest a possible solution that may also help development?

This would be to provide an extra keyword/value pair to the mysql.txt/config.xml 
file(s): domain=<value>

<value> would of course default to 'mythtv' for the vast majority of users who 
only have one system but for those who are planning a complex migration or who 
just want to build another system, for example for portable purposes or for 
evaluating a new feature, it would provide a means of distinguishing one setup 
from another.

This value could be passed during the initial handshake and ensure that the 
wrong setup/backend connection(s) are not made.

-- 

Mike Perkins