[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:09:47 UTC 2012
> Date: Thu, 29 Mar 2012 09:38:07 +0100
> From: Andre <mythtv-list at dinkum.org.uk>
> On 29 Mar 2012, at 05:20, f-myth-users at media.mit.edu wrote:
> >
> > P.S. I'm also still trying to determine if I can -guarantee- that
> > any 0.24 version -will not- attempt to upgrade a random older Myth it
> > happens to see on the network, no matter whether I'm running its
> > backend, frontend, setup, etc, and maybe even if it's not the very
> > latest 0.24-fixes [because who knows what version I might wind up
> > getting], and if not, which ports should I firewall so I can test
> > safely? I want to be able to run 0.24-fixes, and later 0.25, for
> > quite time to to test everything, while my much older production myth
> > is online and operating. Tnx.
> I was caught out by this when testing a 0.24 system in parallel to
> my 0.23 one! Fortunately I was able to restore the db from backup
> before any important recordings were missed.
> While different subnets is the safest approach that's not often
> practical, I have firewalled the mysql 3306 port on my live system
> from my test system and set a different mysql password for belt
> and braces peace of mind.
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?
In any event, setting a different password for the two DBs does
sound like a logical safety precaution, but knowing either that
0.24-fixes can't do this on its own, or what to firewall, would
be better. I may just kill everything but ssh and see.
More information about the mythtv-users
mailing list