Opened 11 years ago

Closed 10 years ago

#9174 closed defect (fixed)

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

Reported by: myth@… Owned by: Nigel
Priority: minor Milestone: 0.25
Component: MythTV - General Version: Unspecified
Severity: medium Keywords: database backups upgrade upnp
Cc: Ticket locked: no


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).

Attachments (1)

UpgradeWithoutBackup.log (55.2 KB) - added by myth@… 11 years ago.
Log of backend connection, upgrade w/o backup

Download all attachments as: .zip

Change History (6)

Changed 11 years ago by myth@…

Attachment: UpgradeWithoutBackup.log added

Log of backend connection, upgrade w/o backup

comment:1 Changed 11 years ago by robertm

Resolution: Duplicate
Status: newclosed

Dupe of #7799

comment:2 Changed 11 years ago by Nigel

Resolution: Duplicate
Status: closednew

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.

comment:3 Changed 11 years ago by Kenni Lund [kenni a kelu dot dk]

Owner: changed from dblain to Nigel
Status: newassigned

comment:4 Changed 10 years ago by sphery

Component: MythTV - UPnPMythTV - General

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/" 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.

comment:5 Changed 10 years ago by Github

Milestone: unknown0.25
Resolution: fixed
Status: assignedclosed

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

Note: See TracTickets for help on using tickets.