Jump to content

vicos

Approved members
  • Posts

    16
  • Joined

  • Last visited

Posts posted by vicos

  1. My revive is installed on a dedicated domain at the root level. It was time to migrate to a newer server, so took the opportunity to upgrade Revive from 3.2.1 to 4.1.4. 

    The upgrade completed, but with some errors, all involving plug-ins. Before I show the errors, a note about the upgrade process. Since your instructions are set up for revive being in a folder and not at the root, I just did it this way:

    -- Setup new clean domain 
    -- Created database and imported data
    -- Did not copy all files over, just the ones I thought were unique:
    --- banner images
    --- config files
    --- plugins folder

    I didn't realize there were some plug-in files in /www/admin, so none of those got copied.

    So, the install completes, but says there are errors and says it is ok to proceed. I login and everything looks OK. So, here a few of the key errors. They most involve Plugin: openXVideoAds

    /home/mysite/public_html/www/admin/extensions/videoReport/lib/ofc2/ofc_y_legend.php
    Plugin: openXVideoAds - Unable to locate file: 

    One immediate problem is that there is NO www/admin/extensions on the old server. But, there is a www/admin/plugins folder where the respective file is located. So, even if I had copied the www/admin/plugins files to the new server, the script still would have an error, I guess?!

    Anyway, there is NO showing in the admin control panel under plugins. 

    Finally, it complains:

    #! openXDeliveryLog(): Problems found with components in group oxDeliveryDataPrepare.  The openXDeliveryLog plugin has been disabled.  Go to the Configuration->Plugins page for details 
    #! openXDeliveryLog(): Task failed _verifyDataObjects

    But, when I look in the admin CP under Plugins, I see Banner Delivery Logging Plugin enabled. This is the only plugin on the new system that has the same version (1.1.2) as the old system. All other plugins have a newer version.

    Bottom Line: is there a problem, or I am safe to proceed with using the new install?

    Appreciate you insights!

    I confirmed that all of the standard Plugins are there (the same ones as on the old server)

    Also ran thru the troubleshooting at: https://documentation.revive-adserver.com/display/DOCS/Plugins+Incorrectly+Upgraded

    and it all looks good. I would feel better if that plugin had a newer version number so I knew for sure.

  2. I believe it relies upon your config file to determine if it is an existing installation. i.e. does the config file exist and does it have an existing database specified in the parameters.

    the config file is in the 'var' directory: yourdomain.com.conf.php where "yourdomain.com" is your domain name.

    Maybe you overwrote this when you uploaded the new files...

    Also, if you originally accessed the domain as mydomain.com and are trying the upgrade via www.mydomain.com, this might cause it to look for a differently named config file from the one that exists.

  3. 1) Did you grant full SQL privs to the mysql user you specified

    2) are the username, password, and database name you specified correct. Open a shell and try connecting to the database from the command line to test your parameters:  mysql -umyusername -pmypassword mydatabasename

    3) The host is usually 'localhost.'  If you specify a remote host, your host needs to be specified in that server's remotehosts for mysql or it will not be allowed to connect.

  4. In the var directory for revive you will find a file called mydomain.com.conf.php where "mydomain.com" will be your domain name.

    This file must be writable by the webserver in order to change the settings via the revive admin.

    If your webserver is running as user nobody, then the file will need '666'

    If your webserver is running as the account owner, the default 644 should be fine.

    You could also edit this file using nano from a shell if you feel confident. Always make a backup of any file before you change it just in case...

    The developer recommends that the config file be set so that it is not writable by the webserver after you have finished making your changes for security reasons. Check the install guide for details...

  5. OK, I'm out of tricks...

     

    I purged all hourly data pre-2013 and optimized the database.

     

    The script runs up to a point and stops, not timeout, just stops. If I view source of the page, there is just a "1".

     

    Here are the last few lines of the install.log:

     

     

    UPGRADE SUCCEEDED
    to version: 544
    timing: constructive
    schema file found: /home/dev10smd/public_html/revive/etc/changes/schema_tables_core_544.xml
    schema definition from cache TRUE
    successfully parsed the schema
    schema name: openads
    schema version: 544
    schema status: final
    changeset definition from cache TRUE
    successfully parsed the changeset
    changeset name: openads
    changeset version: 544
    changeset comments: UAPP Step 2
    schema and changeset versions match
    constructive changes found
    destructive changes found
    migration file found: /home/dev10smd/public_html/revive/etc/changes/migration_tables_core_544.php
    migration class Migration_544 instantiated
    target database: dev10smd_revive
    table prefix: phpads_
    successfully initialised DB Upgrade
    verifying constructive changes
    verifying/creating constructive tasklist
    task found: doAddTable__account_preference_assoc
    task found: doAddTable__preferences
    checking field: phpads_application_variable value
    found field value
    task found: doAddIndex__accounts__account_type
    executing constructive tasks
    executing task 0 : phpads_account_preference_assoc => create
    successfully created table phpads_account_preference_assoc
    executing task 1 : phpads_preferences => create
    successfully created table phpads_preferences
    executing task 0 : phpads_application_variable => alter

     

    Then, if I reload the install page, it starts all over and complains:

     

     

    application

    1. - database integrity check detected problems with the database
    2. - 13 tables to add
    3. - 18 fields to add
    4. - 1 fields to change
    5. - 10 indexes to remove
    6. - 3 indexes to add

     

    There is nothing I'm doing wrong at this point.

  6. I have the data imported properly. The problem is the way the upgrade is written is causing constant timeouts. It would be nice if this could run via shell so web server timeouts are not an issue.

     

    I just ran it again on a brand new server with PHP memory limit=128M and execution timeout of 300 and it just timed out again leaving the database in an unrecoverable state.

     

    This is the point where it keeps dieing because the table is so large. I guess I will set the execution time to a zillion years and try again.

     

    task found: doAddIndex__data_summary_ad_hourly__hour

     

    I have almost 16M rows in this table. Does the new version of Revive have an automatic mechanism to keep these tables trimmed to the last xx years or do I still need to goin there and manually delete records ??

  7. I started over. Apparently there was a problem importing the backup from the dump the first time. Anyway, it ALMOST worked. The PHP script timed out because mysql was taking so long because of the size of the DB (only 3GB)

     

    Can you put something in the code to prevent the timeouts and/or break the upgrade process into multi-steps so a different URL is called each time to reduce chance of timeout?

  8. No, we started with PHPAdsNew way back when and have never made any customizations that I recall. The only thing I ever did to the database was manually purge the stats tables because they were becoming huge over the years and there was no way to do it via the program.

     

    I have debug and install log files if there is some way I can transmit them privately. It looks like it failed with the 2.5.42 upgrade.

  9. Hi, I setup a testbed to see what happens when I upgrade from 2.4.6 to 3.0.2.

     

    The first image shows the first failure upgrading the schema. The second image shows what I get as soon as I try to start over.

     

    The database is close to 3GB.

     

    This is on a shared Hostgator account. So, I have no control over timeouts or anything like that, if that is perhaps the root cause.

     

    Fail-1.PNG

     

    Fail-3.PNG

     

     

    P.S. Neither the "documentation" or "FAQs" links on that last image are correct.

×
×
  • Create New...