Re: Zabbix package's RC bugs fixed - ready for Squeeze
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am 15.01.2011 10:18, schrieb Adam D. Barratt:
> On Sat, 2011-01-15 at 01:02 +0100, Christoph Haas wrote:
>> 1.) Putting the database upgrade scripts into
>> /usr/share/doc/zabbix-server-(pg|my)sql/examples/1.(6|8)/...
>>
>> The upstream developers failed to send me proper SQL to
>> upgrade the database from 1.4->1.6->1.8 and pointed out that
>> users of Zabbix have to run their SQL queries and ignore any
>> error or even run the upgrade shell script.
>>
>> The README.Debian of the zabbix-server-mysql and
>> zabbix-server-pgsql packages reflect that.
>
> So what happens when a user upgrades from lenny to the new package?
A debconf screen is displayed telling the user that no automatic upgrade
of the database is possible. The user is pointed to
/usr/share/doc/zabbix-server-*sql/README.Debian with further
instructions to upgrade manually.
> Does their zabbix installation simply stop working?
Yes, Zabbix stops working. The users sees a lot of SQL errors on the web
interface. Until the user does the manual upgrade procedure Zabbix is
unusable. But no existing data is lost.
> Is there any information provided to them during the upgrade as to
> what's going on?
There is no automatic upgrade procedure. We tried hard with
dbconfig-common but dbconfig-common relies on properly working SQL
statements. Different versions of 1.4.x and 1.6.x apparently created
different SQL schemas. (I can a couple of upgrade tests with different
voluntary users. And no single upgrade SQL script succeeded for
everyone.) So there is no single correct SQL file that could upgrade the
schema. Upstream says: "run this SQL script and ignore any errors".
Unfortunately dbconfig-common cannot be told to ignore errors. It rolls
back upon the first SQL error. Even worse: upstream even provides a
combination of an SQL script and a shell script to do the upgrade on
MySQL for version 1.8.
>> 2.) The debian/patches/zbx-2329 quilt patch has been added
>> to deal with a problem in Zabbix 1.8.2 that caused data
>> loss and had been fixed upstream in Zabbix 1.8.3.
>> I asked for a proper patch to fix this very issue and
>> this quilt patch fixed it (I verified that).
>
> This looks okay; thanks.
Good.
> + * Removed recommends for a database server from zabbix-frontend-php
> + package to prevent automatic installation since recommenations are
> + automatically installed.
>
> This doesn't seem to have been applied to the unstable packages?
Right. I've put more time into the Squeeze package during the last days.
The same changes will be applied to the upcoming 1.8.4-1 package in
"unstable". But first I hurried to get the RC problems fixed for Squeeze.
I made this change because it will likely fix two bugs that have been
downgraded from "grave" to "important" - namely #606780 and #606795.
During installation and upgrade tests I found that even if I chose
zabbix-server-pgsql (Zabbix server using a PostgreSQL backend) the
zabbix-frontend-php started to install a mysql-server-5.x package.
> Presumably the package is still going to attempt the database
> autoconfiguration step during install anyway?
Well, we still use dbconfig-common. On a fresh installation the database
can be created with dbconfig-common properly. Just in an upgrade
situation we can't rely on dbconfig-common. So there are no files for
dbconfig-common for the upgrade procedure and it just does nothing
during an upgrade from 1.(4|6) to 1.8.
> - chmod 000 $(TMP_FRONTEND)/usr/share/zabbix/setup.php
> + rm $(TMP_FRONTEND)/usr/share/zabbix/setup.php
>
> Why was this change made? (and why was the previous package explicitly
> setting an included file to mode 000? That seems a little strange).
The "chmod 000 ..." somehow failed to work. Some dh_* script changed
that back. And it was not dh_fixperms. At some point I gave up and
removed the script.
The setup.php script is supposed to be run first to set up the database.
As we use dbconfig-common for that purpose the setup.php is not needed.
On the contrary: if the file exists or is readable then the first login
on the Zabbix web interface (zabbix-frontend-php) redirects to setup.php
and throws error messages that e.g. the database already exists. So
after confering with the upstream developers we removed the setup.php
file to avoid confusion.
Best regards
Christoph
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0xcmYACgkQCV53xXnMZYaulgCg4f/+S4IOPXbg31Lg/OcDxHds
xvEAoPzGDV94RA6P2QMwEym+f+xo+zDG
=JWWc
-----END PGP SIGNATURE-----
Reply to: