A new backend can uPnP to old master, upgrade DB without backup

[myth@…]

If an older backend is running, and a newer backend connects, it upgrades the database. Though it is supposed to backup the exiting database first, the backup may return a failure code. In this case the database upgrade continues along anyway, though it should probably not do so.

Verbose log attached, observed on OSX 10.6.4 with 0.24RC1 (slave) and 0.23.1 (master).

[myth@…]

Log of backend connection, upgrade w/o backup

[robertm]

Dupe of #7799

[nigel]

Not quite the same problem as 7799, so I'll take this & investigate.
Brian, the schema upgrade is meant to prompt the user, tell you the backup failed, et c., but it didn't in this case. From your log:

2010-11-02 21:26:43.320 Console is non-interactive, can't prompt user...
2010-11-02 21:26:43.320 Upgrading.

This usually only happens in SSH'd shells, but I will investigate if MythBackend?.app has any extra bugs in this scenario.

[mdean]

For what it's worth, 889f53315 modified the schema upgrade procedure so mythbackend can only upgrade the database when running on the master mythbackend host (and mythbackend running on any remote host is not allowed to upgrade the database). Therefore, a new backend should never be able to upgrade the database out from under a running master mythbackend.

I can modify the schema upgrade wizard to refuse to upgrade the database if the 2 backup attempts fail, but it was originally designed to allow upgrade even if the automatic backup fails--since we have always suggested users manually back up the database before upgrades. For now, I plan to leave it as is--so that if the "do our best to get a backup in case the user didn't" fails, we still allow the upgrade to proceed. (If consensus among developers is that we should not allow the upgrade, I will make the change.)

And note that the backup failed here because a) "2010-11-02 21:26:43.076 Database backup script does not exist: /Volumes/Brobits?/TV/myth24/MythBackend.app/Contents/Resources/share/mythtv/mythconverg_backup.pl" and b) when we fell back to using mysqldump directly, mysqldump was not in the PATH, so it couldn't be executed.

So, as I read it, all that's left of this ticket is checking whether there's a bug in determining whether a console is interactive on Mac OS X, and, if so, fixing it.

[Github]

Prevent UPnP detection from using backends of a different version

This implements the new ConnectionInfo? values into the DatabaseParams? struct, and throws an error if the remote backend is found to have a different protocol or database version.

Closes #9174

While this does not address the secondary issue that OSX does not support detection of an interactive console, it does prevent a UPnP connected client from ever altering the database.

Branch: master Changeset: e2295b3627a8ff0ce38ebdd261c684b46247e6c0