Images not showing even when logged in - Manual install

[aboron]

I have a manual install of Version: 1.01.7/b running well enough for my minimum needs on a fedora core 8 i386 machine, but for some reason none of the images for the graphs are ever showing.

I set site.graph.public to 1 in the variables, but that didn't help. I can't see the graphs even after I log in anyway.

I'm not as familiar with PHP as I am with some other languages, but when looking though the test.graph.php file it seemed to me that it uses libgd, so i did my best to make sure that GD and PHP were fully updated.

Apache is showing the following in the access_log:

(ip removed)- - [07/Oct/2008:16:00:20 -0700] "GET /nats/test.graph.php?testid=L2&startx=1223362800&finishx=1223449199&nodeid=rsd_west_office&i=219086 HTTP/1.1" 500 - "-" "Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.30 Safari/525.13"

So apache knows it's some kind of error, but the error_log shows nothing, as if a 500 reply is an OK response to send without any clarification.

I have error logging turned on in php.ini and even tried it set to write errors to output, but still no messages about what is going wrong when trying to display a data graph.

If anyone has a suggestion about what to try next it would be appreciated.

[dave]

Hi there,

It shouldn't be an issue with public graphs if you're not seeing them even in the interface. It generates a PNG image so requires GD to do this.

Try the following, cd to the server/web directory and then:

Code: Select all

php test.graph.php

You should see a bunch of binary chars which is the image output. I'm guessing you won't though - hopefully you will see a text error which will point us in the right direction.

Cheers,

Dave.

[aboron]

Unfortunately this was one of the things i already tried with no effect. It just returns right to the prompt and nothing in the php_error.log.

I also tried going into the test.graph.php file and uncommenting the following line and setting it to a valid value from my installation:

if (!isset($_REQUEST['testid'])) $_REQUEST['testid']="L2";

But that did not change anything. (it looks like that was a way to default the graph that would be made in case there were no headers being passed in)

After doing a quick "echo" bombing of the code i have tracked down the exit point to this line:

$im=@imagecreate($width,$height)
or die("Cannot create image");

Although that die() text doesn't seem to end up going anywhere.

Which I guess means that yum on fedora 8 can report the packages are there, but still not have them linked to each other?

Time for a complete recompile/install from a tarball on php maybe? Or is there a less disruptive way to link the @imagecreate() reference?

**Edit - further discoveries:

I almost remember the news about the red hat security key getting stolen a while back, and now it hits me that I should have paid a bit more attention.
Apparently, some of the files on my machine managed to update at some point in the past, before the key problem, but not all the ones I require now.

After following the step from this ( https://fedoraproject.org/wiki/Enabling_new_signing_key ) article, I have the command line execution working
and it will create a graphic when called with the "L2" default above in the code. However, it does give me a % by 0 error on line 280 and the images
are still not showing up on the web page.

Time to keep hacking...

[dave]

Hi,

Hmm.... Well I'm glad it's slightly working if not totally. The Div 0 at 280 is linked to the grid lines it seems.

Try this - right click on one of the broken images and do a "View Image" (dependent on browser) to open the image in a seperate tab with it's own URL.

Add &no_grid=1 to the end and see if it then renders.

I would also try removing the specific test being defaulted and then try the graph directly from a brower with no parameters. This should open an image with "ERROR: No Data" or similar displayed and lets us know that the image opening/writing is working for definate.

Cheers,

Dave.

[aboron]

Still no luck getting any display. Here is a link to the image generator: http://www.ggxtech.net/nats/test.graph.php
It should work without password, since i have that set.

Also, here are links to the images i created on the command line using various combinations.

Plain stock unedited source run as "php test.graph.php > image.jpg":
http://www.ggxtech.net/nats/image.jpg

Run after editing to default to node 2:
http://www.ggxtech.net/nats/image2.jpg

Run after editing grid line defaults to be false:
http://www.ggxtech.net/nats/image4.jpg

Seems the %0 didn't really have any effect on the completion of the image (maybe just happens on one freaky data point).

[dave]

Hi,

Ok this looks like a difference in the capabilities of the CLI PHP and the HTTP one, which I'm assuming is the Apache module.

What I would try to see is:

Create a phpinfo.php file with just

Code: Select all

<?php phpinfo(); ?>

In it.

Compare this output from the command line i.e. php phpinfo.php > phpinfo.cli.html with it being "natively" run in Apache.

I think you'll have to patch the Apache module with GD like the CLI one is now.

Cheers,

Dave.

[aboron]

Well the two configs look about the same to me, although they have a lot of different information due to the manner in which they were run.
They both seem to reference the same install locations and modules.

http://www.ggxtech.net/nats/phpinfo.php
http://www.ggxtech.net/nats/phpinfo.cli.txt

(I removed the user info and ssh connection ip stuff from the cli version)

I think that since the command line php is generating an image as it should, that this is clearly not something I should trouble you with further.

I do thank you very much for your support, and I will be happy to report back when I do nail the trouble down, in case someone needs to
install on a similar system later.


Time to delve onward into the interactions between Apache and PHP. Thanks again.

[dave]

Hi,

Well I can see a difference in terms of GD in your phpinfo output.

From the CLI one:

Code: Select all

gd

GD Support => enabled
GD Version => bundled (2.0.34 compatible)
FreeType Support => enabled
FreeType Linkage => with freetype
FreeType Version => 2.3.5
GIF Read Support => enabled
GIF Create Support => enabled
JPG Support => enabled
PNG Support => enabled
WBMP Support => enabled
XBM Support => enabled

And from the CLI compilation options '--with-gd=shared'.

From the Apache version in the compliation options is '--without-gd'

So that is definately the problem I'm afraid. The Apache module was compiled explicitly without it (thanks RedHat!). In the past with the Apache module I have found it best just to recompile configuring it --with-pretty_much_everything (removing only stuff that fails dependencies).

The alternative would be to setup a CGI handler which I'm sure you could do on a per-directory basis but would be complicated to say the least.

If you find an easy way to patch please do let me know and I'll include it in the documentation.

Anyway I hope that is some help even if there is no solution on offer! Always glad to hear from users, especially when their problems don't come from my shoddy code (for a change).

Regards,

Dave.

[aboron]

Thank you very much for spotting that for me, the wall of text it generated must have temporarily overloaded something in my brain and i couldn't see the forest for the trees.

At least now i know what to concentrate on next. Luckily this is only a spare machine that hasn't any other important role to fill yet, so i can do
massively evil things like a custom upgrade to apache without breaking anything.

And on a more positive note, just looking at the text for the ping monitor I set up yesterday, it is certain that every time we lose connection from here at work to the internet it is always
both the our internal router and our next hop gateway that become unpingable. Putting the problem squarely onto the ISP equipment, not our router.

So thanks for making a tool that got the job done in spite of the fedora package problems.

[aboron]

It's alive!

Downloaded the source tarball for apache (ver. httpd-2.2.9.tar.gz) and did:

./configure --enable-ssl --enable-so --enable-rewrite
make
make install

And now all is right with the world again, plus it didn't seem to have confused anything that was already installed.