Opened 13 years ago
Closed 13 years ago
#9174 closed defect (fixed)
A new backend can uPnP to old master, upgrade DB without backup
Reported by: | Owned by: | Nigel | |
---|---|---|---|
Priority: | minor | Milestone: | 0.25 |
Component: | MythTV - General | Version: | Unspecified |
Severity: | medium | Keywords: | database backups upgrade upnp |
Cc: | Ticket locked: | no |
Description
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)
Change History (6)
Changed 13 years ago by
Attachment: | UpgradeWithoutBackup.log added |
---|
comment:2 Changed 13 years ago by
Resolution: | Duplicate |
---|---|
Status: | closed → new |
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 13 years ago by
Owner: | changed from dblain to Nigel |
---|---|
Status: | new → assigned |
comment:4 Changed 13 years ago by
Component: | MythTV - UPnP → MythTV - 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/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.
comment:5 Changed 13 years ago by
Milestone: | unknown → 0.25 |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
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
Log of backend connection, upgrade w/o backup