0.8.8b fresh install and upgrade problem

[smlick]

I didn't see any relevant difference about what I did and the upgrade procedure!
I did it in the past with no success.
So I tried a clear similar process.
Your installer is not intended as an upgrade so I start from a fresh install and then I restore the backup, in fact the upgrade process and the post install first login goes well!
The only difference is that I didn't copy yet the rrd file, script, ecc. but I don't think that this can cause an http 500 error.
Also as I can see elsewhere in a topic I have to convert first the rrd file in xml and not copy them directly because the format change.

Is possible a problem with the automated upgrade procedure? Do you think is better an intermediate upgrade from 0.8.7g to 0.8.7i for example?

Regards
Alessio

[BSOD2600]

The only difference is that I didn't copy yet the rrd file, script, ecc. but I don't think that this can cause an http 500 error.

Nope.

Also as I can see elsewhere in a topic I have to convert first the rrd file in xml and not copy them directly because the format change.

Only required for OS or 32bit/64bit architecture changes. Again, won't cause error 500.

Is possible a problem with the automated upgrade procedure? Do you think is better an intermediate upgrade from 0.8.7g to 0.8.7i for example?

Doubt it. The phpinfo page proves its the web server/php config which is at fault and entirely independent from Cacti. Once you fix that, Cacti will work fine. I suggest you go through the installation guide http://docs.cacti.net/ step by step and validate everything is configured correctly.

[smlick]

Ok I can check step by step no problem but as I told you I started from a fresh install with your installer and I get it working well after that the only thing I did is to restore from a mysqldump the old db (0.8.7g), so there's no possibility that something changed outside the db (permission and other things).
The upgrade procedure goes well except for the Cacti log, I didn't change the path in the db (settings) but I did a fast workaround and I recreate the desidered path (log write successfully).

Tomorrow I will check step by step but I think there's something wrong in the table update procedure.

Regards
Alessio

[smlick]

If I export the table structure (no data) is possible a check for it?

Regards
Alessio

[smlick]

The phpinfo works great probably I did something wrong when I test it last day sorry!
So php ok, Apache ok.
I attached the phpinfo result.
So as I told I think something wrong in the table structure. Is it possible?

I attached also the Cacti db structure (after upgrade) with no data, have you the possibility to check it? So we can understand if it's something wrong with the automated upgrade db structure.

Regards
Alessio

[smlick]

Hi BSOD2600 I wanted to know if you've had time to see the structure of the database, and also possible solutions.


Regards
Alessio

[BSOD2600]

I'm not sure what the problem is. Most likely something one of us has overlooked.

[smlick]

You mean something that the developers have missed?
I have a big production environment so I can't restart from "0", there's no solution?
Who are the developers who developed the upgrade script? Is possible a fix?
As a workaround do you think that a step by step upgrade from the different version 0.8.7g, 0.8.7h, ecc. instead a direct upgrade is a possible "solution"?

Regards
Alessio

[BSOD2600]

if you could determine the root of why the page is blank, this would help greatly with solving the issue.
Try different browsers? clear the cache? I still am finding it hard to believe neither the PHP or Apache logs contain anything about the error you're seeing.
Validated the various error logging configs in apache and php are enabled?

[smlick]

The problem is inside the db!! A problem with the upgrade script.....a table that doesn't exist, a table with incorrect format or other thing but this is the problem!
No other change except db so there's no possible other issue with php, permission etc.
Something goes wrong with the automated cacti upgrade script at first logon.
I tried also with different browser (IE, Firefox, Chrome) cleared the cache......nothing same issue.
The generic error that I get http500 (only in IE, in Firefox and chrome i get a a blank page).
I attached the log and there's nothing inside! I think something unexpected into the db, you had time to check the db structure that I attached? Is that right?

Regards
Alessio

[BSOD2600]

The problem is inside the db!! A problem with the upgrade script.....a table that doesn't exist, a table with incorrect format or other thing but this is the problem!

If this was true, it would be in one of the logs.

[smlick]

I tried the same procedure from 0.8.7g to 0.8.8a and all works ok!!
So something with 0.8.8b.
When will be available 0.8.8c installer I'll try to do it from 0.8.8a to 0.8.8c

Thanks anyway for your help!

Regards
Alessio

[BSOD2600]

I tried the same procedure from 0.8.7g to 0.8.8a and all works ok!!
So something with 0.8.8b.

That's great. so your install is currently on 0.8.8a? Take a snapshot so everything is backed up. Then when you manually upgrade to 0.8.8b (NOT using the installer), things break again? What about to 0.8.8c? We really need to determine the root cause, otherwise the problem will likely continue in the future.

When will be available 0.8.8c installer I'll try to do it from 0.8.8a to 0.8.8c

It's in progress. The installer is NOT meant to be used for upgrades -- only new installs.

[smlick]

This is what I did and what I get:

First attempt (0.8.7g to 0.8.8b)

Step 0 : Install Cacti 0.8.8b from your last installer
Step 1 : The installations halt when try to start the mySQL service (as workaround I have to overwrite during install the my.ini with a mod in the Innodb memory size "innodb_buffer_pool_size=2G" to "innodb_buffer_pool_size=500M")
Step 2 : Cacti 0.8.8b works great
Step 3 : get the old db from the production server 0.8.7.g --> mysqldump -uroot -pxxx -l --add-drop-table cacti > cacti.sql
Step 4 : move the cacti.sql backup from old server (0.8.7g) to new server (0.8.8b)
Step 5 : restore the old db --> mysql -uroot -pxxx cacti < cacti.sql
Step 6 : Login
Step 7 : Automated upgrade db procedure goes ok (all success)
Step 8 : tried to login again in IE HTTP500, Firefox and Chrome blank page


Note: no significant error in php or mySQL log
Result: Attempt failed


Second attempt (0.8.7g to 0.8.8a)

Step 0 : Install Cacti 0.8.8a from your last installer, Cacti 0.8.8a works great
Step 1 : get the old db from the production server 0.8.7.g --> mysqldump -uroot -pxxx -l --add-drop-table cacti > cacti.sql
Step 2 : move the cacti.sql backup from old server (0.8.7g) to new server (0.8.8a)
Step 3 : restore the old db --> mysql -uroot -pxxx cacti < cacti.sql
Step 4 : Login
Step 5 : Automated upgrade db procedure goes ok (all success)
Step 6 : tried to login all works great!!!
Step 7 : Restored plugin and rrd, I get 0.8.8a with all my device, graphs, ecc.

Result: Attempt OK


Third attempt (0.8.8a to 0.8.8b)

Step 0 : Install Cacti 0.8.8b from your last installer
Step 1 : The installations halt when try to start the mySQL service (as workaround I have to overwrite during install the my.ini with a mod in the Innodb memory size "innodb_buffer_pool_size=2G" to "innodb_buffer_pool_size=500M")
Step 2 : Cacti 0.8.8b works great
Step 3 : get the old db from the production server 0.8.8.a --> mysqldump -uroot -pxxx -l --add-drop-table cacti > cacti.sql
Step 4 : move the cacti.sql backup from old server (0.8.8a) to new server (0.8.8b)
Step 5 : restore the old db --> mysql -uroot -pxxx cacti < cacti.sql
Step 6 : Login
Step 7 : Automated upgrade db procedure give a no update script required!
Step 8 : tried to login all works great!!!


Result: Attempt Ok



Final consideration....there's something wrong in the update script inside 0.8.8b

Now I get 0.8.8b working. If you need more to get something to debug I'm here.

Regards
Alessio

[BSOD2600]

The only database upgrades occur with (look in \cacti\install\)
0.8.7g -> 0.8.7h
0.8.7i -> 0.8.8
There is nothing for 0.8.8a, 0.8.8b, or 0.8.8c.

To demonstrate there are no issues with the Cacti db upgrade scripts, I used the old Cacti-0.8.7g.exe Windows Installer on a clean Windows 2008R2 VM. Validated all was working. Then I overwrote all the files with those from 0.8.8c (and updated \include\config.php). The db upgrade scripts ran successfully and could log on just fine.

This week while working on the next installer, I ran into various issues with blank pages and/or Error 500. changing the various log/display settings in php.ini was quite helpful. you might consider switching to the php.ini-development file to assist with troubleshooting. Basically what I'm trying to get at is that additional digging/research on your side is needed to find the root cause of the generic error 500.

Are you only restoring the database or also scripts/plugins/etc?
Which plugins are you using on 0.8.7g? Try disabling them before making the backup. Various aspects of the plugin architecture and plugins changed between 0.8.7g and 0.8.8 which could be a source of the problem(s).
Are you certain php and apache logging is working?