On Thu, Aug 09, 2012 at 05:26:32PM -0700, Vagrant Cascadian wrote: > Peter Howard committed a patch to mercurial that mostly addresses the > database > upgrade issue, although the upgrade process is still a bit fragile. I've got a > test environment set up to work on this now...
Ok, the following patch (from the mercurial repository) almost works. There appears to be a syntax error on revoking create privledges, but it basically works if that line is commented out: changeset: 121:9fe977a1baaa tag: tip user: Peter Howard <[email protected]> date: Wed Aug 08 10:24:27 2012 +1000 summary: Fix postinst to add permission for table creation during upgrade diff -r e40abe8162b7 -r 9fe977a1baaa debian/postinst --- a/debian/postinst Mon May 14 01:56:21 2012 -0700 +++ b/debian/postinst Wed Aug 08 10:24:27 2012 +1000 @@ -26,10 +26,11 @@ OLD_ZM_VERSION=$(echo 'select Value from Config where Name = "ZM_DYN_CURR_VERSION";' | mysql --defaults-file=/etc/mysql/debian.cnf --skip-column-names zm ) fi if [ -n "$OLD_ZM_VERSION" ] && [ "$OLD_ZM_VERSION" != "$VERSION" ] ; then - echo 'grant lock tables, alter on zm.* to 'zmuser'@localhost identified by "zmpass";' | mysql --defaults-file=/etc/mysql/debian.cnf mysql + echo 'grant lock tables, create, alter on zm.* to 'zmuser'@localhost identified by "zmpass";' | mysql --defaults-file=/etc/mysql/debian.cnf mysql # stop zoneminder before performing database upgrade. invoke-rc.d zoneminder stop || true zmupdate.pl --nointeractive --version $OLD_ZM_VERSION + echo 'revoke create on zm.* to 'zmuser'@localhost identified by "zmpass";' | mysql --defaults-file=/etc/mysql/debian.cnf mysql fi else Would there be any serious problems with just leaving the create privledges in place? Though it still fails to upgrade properly in a variety of cases... if the database upgrade succeeds, but zoneminder fails to start for some reason, the upgrade fails... and after running "apt-get -f install" zoneminder tries to upgrade the database again, which fails, because it's already upgraded. I'm thinking it should actually ask the database itself what version to upgrade from, rather than relying on the version passed into postinst. It's not immediately clear what all the ZM_DYN_*_VERSION values in sql are used for. Also, I've noticed that it seems to require upgrading the kernel and rebooting before upgrading zoneminder, otherwise it fails to start (and therefore, fails to upgrade). This may have to do with the switch to using libsys-mmap-perl. So I guess there are at least two more issues above and beyond the database upgrade itself. live well, vagrant -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
