-----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----- -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d317269.70...@debian.org
