can't create image in 1.8

[brian]

I tested Palmertree's suggestion, it worked for me with rev. 5914

[prote]

I have a problem with images too, but I think, that's an other problem. I get absolutely no pictures after upgrade to Zabbix 1.8 from 1.6. The Upgrade via apt-get works fine - without the DB of course. During upgrade I got a message, that I have to run the DB-Upgrade manually. Ok, I found a patch.sql. After running it I got many many errors. Some hours after that I figured out, that this patch.sql is an Upgrade-SQL for older versions to 1.6 and the upgrade which needed for 1.8 is missing in the Deb-package. After getting this script I updated my DB to utf8 and so on. But I have no images at all: no graphs, no images in the head-row of overview-table in the frontend, ...


I tried many different things but nothing helped me. My system is a Debian Lenny with testing for Zabbix and dependencies. MySQL is 5.0.51a-24+lenny2, JS-prototype is 1.6.1 for the menus and so on.

I got following errors for calling this pictures in FiFo:
/chart.php?itemid=23960&sid=...
/vtext.php?text=Servername
Die Grafik .../vtext.php... kann nicht angezeigt werden, weil sie Fehler enthält.

In english: The picture /vtext.php... could not be shown cause it contains errors.

Some ideas?

[kleytonn]

People,

My instalation is a Debian Lenny 5.0.3 whith Mysql Server 5.1.36 x86_64.

In my case a upgrade from 1.6.5 to 1.8.0 and convert de production database. I convert all database and tables do default UTF8 encoding.

I resolv this problem with php frontend code modifications proposed by Vedmak in this post.

I wait for 1.8.1 for php frontend bug fixes.

Thank's!!!

[Palmertree]

You have to make sure the database itself is UTF8 and not just the tables.

[prote]

Database is utf8, Zabbix-tables are utf8_general_ci. I got new data, my triggers work fine and so I think, that my Zabbix-DB is ok. I updated MySQL to Debian-testing 5.1.41-3, but still get no graphs from routines vtext.php and chart.php.

I think that the reason could be an compatibility-issue in the dependancies of the frontend, but don't know where to search. As I sayd I use a Debian Lenny stable with some packages from testing.
Actually I installed Zabbix 1.8 on an VMware-machine and will try to get it working with an export/import from my life-system ...

Edit:
ok, I found the problem and as I supposed it is an issue in the frontend. After some hours of installing and testing with my VMware I figured out, that there is an alias in /etc/zabbix/apache.conf for the directory /zabbix - fine ^^

Naturally I use (sub-)domains for my Zabbix, in the VMware the 192.168.../zabbix works fine, but without this subdirectory the images doesn't work. So I searched on my server and found the deadlink in zabbixdir/fonts.

In older 1.6-versions it was no problem to copy the zabbix-frontend in the htdocs-dir of an (sub-)domain or otherwise simply link to the frontend, make two chowns and put some directories into the openbasedir. With later 1.6-versions comes a new relative JS-prototype-link with it, which must adapt to the right path. In 1.8 there are to additional links to JS-scriptaculous and my last problem the font-link.

If somebody uses same configuration with a domain and don't want the ".../zabbix/" in the path, here are the needed links:

# ln -sf /usr/share/javascript/prototype/prototype.js /var/www/virtual/[domain.de]/htdocs/js/
# ln -sf /usr/share/javascript/scriptaculous/ /var/www/virtual/[domain.de]/htdocs/js/
# ln -sf /usr/share/javascript/scriptaculous/scriptaculous.js /var/www/virtual/[domain.de]/htdocs/js/
# ln -sf /usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf /var/www/virtual/[domain.de]/htdocs/fonts

Otherwise you can make a link as the following:
# ln -s /usr/share/zabbix/ /var/www/virtual/[domain.de]/htdocs
and fix some permissions:
# chown -R vu2001.www-data /var/www/virtual/[domain.de]/
# chown vu2001.www-data /etc/zabbix/dbconfig.php
and if using fcgi fix the openbasedir in /var/www/fcgi/[domain.de]/php5/php.ini:
open_basedir = "/etc/zabbix:/usr/share/php/:/usr/share/javascript/:/usr/share/fonts/truetype/ttf-dejavu/"

It would be very nice, if in future versions the needed links could be absolut or if the JS-Scripts and the font could be directly in the zabbix-frontend

[sbedoya]

Problem Solved

In Summary:
This problem of storing images is not a Zabbix code problem, but how the database default character set is setup on the Zabbix database and the image table.

This fixed my issue:

USE zabbix;
ALTER DATABASE zabbix charset=utf8;
ALTER TABLE images charset=utf8;

How Resolution was determined:
After looking at HEX dumps on the blob column of the images, I was able to figure out what was going on between the previous versions of Zabbix and the current version.

Current version of Zabbix sets the characters sets for SQL queries to UTF8
Time:0.000779 SQL: SET NAMES utf8
Time:0.000552 SQL: SET CHARACTER SET utf8
while older versions did not. Which makes sense since 1.8 is utf8 aware now.

If UTF8 default character set is not set for the database and the image table, hex 3F is stored because of an invalid translation between the client and the SQL server. Comparing a good image save and a bad one, I could see a lot of 3F hex codes when viewing the blob field.

Determine the hexadecimal value of the character or characters that are not being displayed correctly.

You can obtain this information for a column column_name in the table table_name using the following query:

SELECT HEX(column_name)
FROM table_name;

3F is the encoding for the ? character; this means that ? is the character actually stored in the column. This most often happens because of a problem converting a particular character from your client character set to the target character set.

In the Zabbix documentation it tells us to create the database so it supports UTF8. I think the issue is that people running previous versions did not change the default character set of the database to UTF8. I found that changing the table "images" to UTF8 character set alone was not good enough but you also have to change the default character set of the database itself. Maybe a MySQL UTF8 check can be done on the config screen where the php version, GD version, etc is checked? Just a thought. :-)

This MySQL setup will have problems storing images correctly into MySQL:

[FONT=Courier New]mysql> SHOW VARIABLES LIKE 'char%';

+--------------------------+--------------------------------+
| Variable_name            | Value                          |
+--------------------------+--------------------------------+
| character_set_client     | utf8                           |
| character_set_connection | utf8                           |
| character_set_database   | latin1                         |
| character_set_filesystem | binary                         |
| character_set_results    | utf8                           |
| character_set_server     | latin1                         |
| character_set_system     | utf8                           |
| character_sets_dir       | /var/lib/mysql/mysql/charsets/ |
+--------------------------+--------------------------------+[/FONT]
8 rows in set

This setup will work and will store images correctly into MySQL:

[FONT=Courier New]mysql> SHOW VARIABLES LIKE 'char%';

+--------------------------+--------------------------------+
| Variable_name            | Value                          |
+--------------------------+--------------------------------+
| character_set_client     | utf8                           |
| character_set_connection | utf8                           |
| character_set_database   | utf8                           |
| character_set_filesystem | binary                         |
| character_set_results    | utf8                           |
| character_set_server     | latin1                         |
| character_set_system     | utf8                           |
| character_sets_dir       | /var/lib/mysql/mysql/charsets/ |
+--------------------------+--------------------------------+
8 rows in set[/FONT]

Curious if this fixed anyone else having the same issue.

Hello,
This work for me.

Thanks,
Santi

[Signum]

In older 1.6-versions it was no problem to copy the zabbix-frontend in the htdocs-dir of an (sub-)domain or otherwise simply link to the frontend, make two chowns and put some directories into the openbasedir. With later 1.6-versions comes a new relative JS-prototype-link with it, which must adapt to the right path. In 1.8 there are to additional links to JS-scriptaculous and my last problem the font-link.

If somebody uses same configuration with a domain and don't want the ".../zabbix/" in the path, here are the needed links:

# ln -sf /usr/share/javascript/prototype/prototype.js /var/www/virtual/[domain.de]/htdocs/js/
# ln -sf /usr/share/javascript/scriptaculous/ /var/www/virtual/[domain.de]/htdocs/js/
# ln -sf /usr/share/javascript/scriptaculous/scriptaculous.js /var/www/virtual/[domain.de]/htdocs/js/
# ln -sf /usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf /var/www/virtual/[domain.de]/htdocs/fonts

Otherwise you can make a link as the following:
# ln -s /usr/share/zabbix/ /var/www/virtual/[domain.de]/htdocs
and fix some permissions:
# chown -R vu2001.www-data /var/www/virtual/[domain.de]/
# chown vu2001.www-data /etc/zabbix/dbconfig.php
and if using fcgi fix the openbasedir in /var/www/fcgi/[domain.de]/php5/php.ini:
open_basedir = "/etc/zabbix:/usr/share/php/:/usr/share/javascript/:/usr/share/fonts/truetype/ttf-dejavu/"

It would be very nice, if in future versions the needed links could be absolut or if the JS-Scripts and the font could be directly in the zabbix-frontend

I'd say that if you'd like to run the frontend from a non-Debian-standard location in your file system you need to dereference the links to the Javascript library files.

Debian uses the "dh_link" program to create links during package building. And it creates relative links automatically. So there is not much we can (or want to) do about the general Debian package.

I'll personally go with the "/zabbix/" path in the URL and just throw an alias in my apache config.

Cheers
Christoph
(Debian package maintainer)

[windsurf51]

Hello,
This work for me.

Thanks,
Santi

this worked for me too !

AIX5.3 Server, Apache/2.2.13, 5.1.39-log MySQL, php 5.3.0

thx !

[bashman]

Worked for me too, zabbix v1.8.3.

[pedmond]

The solution worked for me too !

[craigarms]

Solution Worked

Hi thanks for that i change de DB & Tables to UTF8 and nothing else.

Zabbix 1.8.3 on Debian Lenny 5.0.6 with Apache & MySql

[aflannery]

patch

here's a patch for version 1.8.2 which allows the image upload to work without a dependence on character set.

[dickinson]

For me, what Palmertree wrote, works!!!!!!!!:

USE zabbix;
ALTER DATABASE zabbix charset=utf8;
ALTER TABLE images charset=utf8;


I spend too much time trying to solve this issue..thank you very much indeed!!!

[noxis]

Still broken in 1.8.4 and database is already UTF8... and now the source has changed.

[SMB]

Having this same problem with 1.8.3 and 1.8.4, PHP version 5.1 and 5.2 with PostgreSQL 9.0 backend. Problem started when we upgraded from PostgreSQL 8.4 to 9.0. Database is in UTF8 encoding.