On Wed, 2012-08-15 at 15:49 -0700, Vagrant Cascadian wrote:
> 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 <pet...@ok-labs.com>
> 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?
>
Probably not. I put the revoke line in on the principle of "least
privilege". Given alter is still there I doubt it makes that much of a
security hole.
If noone else complains, I'm not fussed by it being left there.
> 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.
>
Can that be fixed with the following:
* an extra dependency on the later kernel? That would force the
install.
* A "uname -r" check in the upgrade script and bail with a
detailed error message if the later version isn't in place.
> So I guess there are at least two more issues above and beyond the database
> upgrade itself.
>
>
> live well,
> vagrant
--
Peter Howard <p...@northern-ridge.com.au>
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
