[mythtv] Schema updates

f-myth-users at media.mit.edu f-myth-users at media.mit.edu
Sun Mar 4 02:26:26 UTC 2007


    > Date: Sat, 03 Mar 2007 09:37:04 +0000
    > From: Allan Stirling <Dibblahmythml0015 at pendor.org>

    > And adding _another_ manual step doesn't improve matters for
    > anyone.

As I said in another reply, the idea is that SVN users who pull a
version every few days leave the switch set to "dangerous" and
everything works the way it's worked since Myth had the ability to
auto-update the schema at all.  But people who use point-releases
or packages will have the switch set to "warn me before charging
ahead" and therefore won't get screwed if for some reason they didn't
-think- they were updating.  (Think people who run some sort of
automatic upgrade-everything every night; if that happens to update
Myth, they're screwed, since updating one machine in a multi-machine
setup is guaranteed to break everything.)

More to the point:

  WHY is it even POSSIBLE for a frontend to upgrade the DB schema if
  the backend isn't that recent?  For example:  I'm running 0.18.1.
  I accidentally run 0.20 on a frontend anywhere on my network that's
  heard of the backend.  Bam!  My MBE now has a 0.20 DB, but the -code-
  there still expects a 0.18 DB!  This is not a supported (or tested)
  configuration, so why does Myth go -out of its way- to put the user
  in this situation?
  
That's part of why I don't understand the reluctance to making DB
schema upgrades NOT happen AUTOMATICALLY from a FRONTEND.

Furthermore, if a frontend can upgrade a backend all by itself, that
means that PREVENTING a backend from being updated requires
disallowing connections from any machine whose frontend you don't
trust.  This is nutty.  It means that, even if my backend runs on a
machine that nobody can log into except me, some innocent who doesn't
even have a login password or privs in its filesystem can nonetheless
totally break my backend by running a frontend and aiming it at the
backend.  Even worse, he can do it BY ACCIDENT---and perhaps not even
realize he did so!  What sensible sort of security posture is this?

[Said innocent might need my MySQL password (I'm not sure---does a
FE talk directly to the DB, or does it ask the MBE to execute the
commands?)  but if he's is authorized to run a frontend at all, then
he'll have it.  And if the server has other (non-mythconverg)
databases on it, he'll have it, too, and I'll have to play all sorts
of games with GRANT on mythconverg, etc.]

Not to mention (again):
(a) mythfrontend and mythtv-setup BOTH have UI's.  That means they can
    -ask- before doing something dangerous.  (Though I'd argue that
    MFE has no business even making the attempt if "dangerous" isn't
    set, but whatever.)  
(b) There's no way an SBE can function correctly if it's newer than
    the MBE, and yet the MBE will be broken if its DB is updated past
    its code, so why does the SBE try?

The only case where it (a) makes sense to update the DB and (b) you
don't already have a UI where you can ask first is when the MBE itself
has been updated, and somebody tried to run it before running
mythtv-setup.  People who update from SVN can just leave the switch
set dangerous.  People who do point-releases MUST run mythtv-setup
ANYWAY and mythtv-setup can ask first and then run the update.  And
if they expect to NOT run mythtv-setup, at the very least they'll
probably notice something like this blatted out to stderr -and- syslog
by a backend that immediately aborts:

  This master backend uses DB revision 12345, but your database was
  last used by a backend that expected revision 9975.  If you actually
  intend to run this new backend, please run mythtv-setup.  The very
  first screen it will pop up will ask you if you intended to run a
  newer version of MythTV; answer YES when it asks.  Please note that
  if you answer YES, it is NOT possible to undo this!  From that point
  onward, you must use this backend or any newer version, but not the
  backend that was running revision 9975.  mythtv-setup will offer to
  make a backup of your database beforehand just in case, and you are
  urged to let it do so.

Also:  Packagers can do this even better.  Not only can the preinstall
back up the DB first (and, really, it -should- because otherwise it
makes no sense to talk about reverting to an earlier version, e.g.,
installing and removing the package isn't idempotent for Myth), it can
wrap the installation:  If desired, when installing mythBACKend only
(not the frontend) it can note the state of the "dangerous" flag, then
-set- it to dangerous in the preinstall, then install, then set
"dangerous" back to what it used to be before the preinstall ran.  Now
the user doesn't even have to run mythtv-setup for the DB to have been
updated---but ONLY if a new backend was installed---though avoiding
having to run mythtv-setup on a new point-release seems nuts anyway
because things have probably changed that the user needs to adjust.

    > The 'target market' as you put it just wants it to work.
    > Which it invariably _does_ if they follow the various
    > instructions. Making those instructions even longer is _not_
    > a good way to go.

But don't the instructions -already say- you have to run mythtv-setup
somewhere between point releases?  (And the "SVN market" sets the
switch to "dangerous" and gets the same behavior they've had all
along.)

And remember---the problem here is that PEOPLE MAKE MISTAKES.
Just saying "follow the instructions perfectly and you'll be fine"
is obviously defective or we wouldn't have half the traffic we do on
the -users list.

Let me try another way of putting this:

Myth's auto-DB-update mechanism as it stands right now is equivalent
to saying, "You must run as ROOT all the time even if you don't want
to."  It's been conventional wisdom for -decades- that this is poor
policy.  Sure, it's -possible- for an expert who never makes mistakes
to run as root all the time, but it's SUCH a bad idea that we go out
of our way to make it convenient to be root as little as possible.
Not so with Myth, which tries hard to go the other direction (aka the
same model as all but the last 2 or 3 releases of a certain extremely
widespread closed-source OS, ahem).

Or another:

I run Myth in a research environment.  I currently have to FIREWALL
the backend just to make sure some bozo doesn't compile a newer
frontend and connect to my backend with it, hence limiting them to
machines which I trust more.  This is a sensible way to structure a
client/server system?  (I'll probably institute Chris's 9999 hack as
further insurance, but oy vey, what a kluge.)

    > The best way I can see to resolve this particular wrinkle is
    > a mythbackup script or similar, that's either run regularly
    > or at least on schema updates. This makes stepback easier.

Yes, it does, and it's a start.  I'm arguing that we make the problem
harder to fall into in the first place, with a -trivial- amount of
error-checking.  [And even backups aren't a panacea:  After all, we
had a case a few months ago of a user [I forget who, but it went to
-users at least] who ACCIDENTALLY revved his database somehow and
didn't figure out what had happened for days or a couple weeks or
something.  Most people's DB backups wouldn't still be around unless
they were careful to keep tiers of daily/weekly/etc, and merging the
old & new would have been a nightmare anyway, especially for a
newbie.]

    > I believe most of the devs (please correct me if I'm wrong)
    > understand that there are _way_ too many options and 'things
    > that need done' to get a good working install. It's just
    > that noone has figured out a good way to remove the
    > complexity without removing the functionality.

If you're installing the first time, nothing I've said matters at all
because you're starting from a fresh database.  If you're installing
from packages/releases, you have to run mythtv-setup anyway, and it
will ASK and then update.  If you're running SVN, you'll presumably
get annoyed by having to run mythtv-setup every time you rev the DB,
so you'll set the switch to "dangerous", and you'll have the same
behavior we have now.  I really don't see how this is increasing the
complexity -to the user-, but it sure makes Myth safer to use.

    > Again, as usual, patches will get a lot more attention than
    > discussion. However, please remember that the devs have
    > personal lives that do not (all ;) revolve around myth. Have
    > a look in trac and see how many outstanding issues there are
    > currently. That's a good indication that everyone has
    > already enough "itches to scratch" at the moment. Expecting
    > patches from (sorry to be brutal) a beginning contributor to
    > be committed within a few weeks / months at the moment is
    > unrealistic.

I'm not sure who you're speaking to here.  Certainly not me, since I
haven't submitted a patch for this.  I do find it unfortunate that
usleepless has said, "I've got a ton of patches to improve Myth;
here's the first one...  hello?...  hello?...  okay, well, I won't
bother submitting more until the first one gets looked at"--- and got
-threatened- in response.  But that's not a situation I can help with
at all.

    > Please, keep up with your patches, however. When a dev does
    > get time to look at it, it's a lot more likely to be
    > committed or at least commented upon if it applies cleanly
    > to current SVN.

As I said, without building a complete one- or two-machine experimental
setup on a net I can be assured won't accidentally screw up my production
machines, -I- won't be running SVN at all, so this is good advice to
someone, but unfortunately not to me.

Thanks.


More information about the mythtv-dev mailing list