[mythtv-users] Upgrading from pre-0.22 MythTV versions
f-myth-users at media.mit.edu
f-myth-users at media.mit.edu
Fri Mar 30 03:58:09 UTC 2012
> Date: Thu, 29 Mar 2012 23:31:19 -0400
> From: Raymond Wagner <raymond at wagnerrp.com>
> 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.
Ok. I remembered that behavior something like that had gone in, but
had lost track of the details of exactly what 0.24 was currently doing.
> 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.
I hope I never have two master backends running on the same physical host. :)
> 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.
Is the detection automatic, or would I be prompted? Alternately, if I
firewalled ports 1900 and 2869 on the old backend (or the new machine :),
I assume this would inhibit this behavior without breaking anything else?
(I -hope- this is moot---UPNP went into myth in... 0.22? I can't remember.
I think my backend is too old to respond, but I don't know for sure.
netstat -l shows nothing listening on either of those ports on my master,)
> In either case, MythTV will
> find somewhere to make a database backup, allowing the mistake to be
Who makes the backup? The new master or the old master? My old
master predates these automatic backups (I have alternate tools).
Is the code that updates the schema smart enough to bail out without
doing anything if the backup fails, such as due to a disk-full? I can
think of more than one filesystems on my old master where a bulky ~1GB
backup could conceivably fail in some circumstances.
[OTOH, I'm assuming we're talking here about the new master making the
backup (hence 0.24-fixes in my case), since my old master doesn't even
know how to make backups except via my own tools, and I'm assuming I'd
be running the new master on a machine with sufficient freespace. But
still, that'd be a nasty failure mode if somehow I wasn't, like in a
VM that I hadn't provisioned appropriately or if it chose some
filesystem I wasn't expecting.]
More information about the mythtv-users