Jump to content

firstimpression

Approved members
  • Posts

    52
  • Joined

  • Last visited

Everything posted by firstimpression

  1. Hi, Is there any documentation how exactly the "pruning" of bucket tables work? My issues right now: 1. Sometimes bucket tables have leftovers because maintenance script did not run at a certain hour. An expected behavior would be that any subsequent run would take care of everything that is left unprocessed in the bkt tables. But in reality I have to manually run the "republish.php" script to take care of those leftovers. 2. Let's say I have 1 master server and 2 slave servers. If the maintenance runs in the order: maintenance-distributed on slave 1, maintenance on master, maintenance-distributed on slave 2 - it looks like the data pulled from slave 2 would be left in master's bucket tables forever (until I run on republish.php). The cause is that after the record in "log_maintenance_statistics" is made, the maintenance would not do anything again for the same hour. Any ideas how to solve that?
  2. @kanuns, this is totally possible. If you set up MySQL replication you can replicate your set up whenever MySQL slaves will be able to connect to master. If you know IP addresses of your remote servers then you can run maintenance-distributed to pull statistics to master server. With this scheme you will have all the stats on the master server. To have all the rest of the stuff synchronized you will have to write a few scripts that will put graphic assets to your remote servers.
  3. Don't do this. https://github.com/revive-adserver/revive-adserver/issues/102 Even after 6 years of this discussion I want to confirm that InnoDB is still ridiculously slow with Revive when logging impressions at high frequency. Tried a lot of InnoDB settings, in the end reverted the "bkt" tables to MyISAM. I think ON DUPLICATE KEY UPDATE in all logging scripts causes a type of lock that makes all the mentioned InnoDB advantages useless.
  4. According to this webserver config, any request like mydomain.com/images/image.jpeg would be fetched from /opt/revive-adserver-4.0.1/www/images/image.jpeg. You have to configure your webserver accordingly if you want to serve over HTTP anything that is outside of www folder. You can use Alias or RewriteRule directives.
  5. Yes, look in /etc/php.ini and apache configs (usually in /etc/httpd/) for anything that refers to "/hermes/phpsessions". I think there is some strange ASCII symbol that someone mistyped in a config before path. Eg. session.save_path=`/hermes/phpsessions If you fix the setting don't forget to reload the webserver to apply the change.
  6. @Accuraty, from my experience, after you run out of disk space, and after you solve the issue by freeing up some space, you have to restart MySQL. Otherwise it just continues to behave as if there is still no space available.
  7. @duplexcleaning, this soudns like an issue with PHP session storage. Try to enable PHP error logging in php.ini (the setting called log_errors), and see if there are any error messages in webserver error log. My bet is that your session storage folder is not writable.
  8. Are you absolutely positive that error logging is enabled, and still there are no error messages in logs? Keep in mind that you can enable: Revive's native logging Webserver logging PHP error logging Those are different logs that work on different levels of systems, enable them all and check them all. Does the error appear instantly, or after some long time?
  9. Got it, had to run "composer update" in install directory to download dependencies Sinergi and Symfony.
  10. I performed a normal upgrade from 3.2.2, and everything worked except upgrade of DeliveryLimitations plugin (request returned Error 500). Now when I try to manually enable the plugin, getting error 500. The PHP error log would pop the error below. PHP Fatal error: Class 'Sinergi\\BrowserDetector\\Browser' not found in /var/ox/lib/OX/Plugin/Component.php on line 64, referer: http://localhost/admin/plugin-index.php PHP Stack trace:, referer: http://localhost/admin/plugin-index.php PHP 1. {main}() /admin/plugin-index.php:0, referer: http://localhost/admin/plugin-index.php PHP 2. OX_PluginManager->enablePackage($name = 'openXDeliveryLimitations', $reparse = *uninitialized*) /var/ox/www/admin/plugin-index.php:192, referer: PHP 3. OX_Plugin_ComponentGroupManager->enableComponentGroup($name = 'Client', $extends = 'deliveryLimitations') /var/ox/lib/OX/Plugin/PluginManager.php:504, referer: http://localhost/admin/plugin-index.php 4. OX_Component->getComponents($extension = 'deliveryLimitations', $group = 'Client', $recursive = TRUE, $enabledOnly = FALSE) /var/ox/lib/OX/Plugin/ComponentGroupManager.php:641, referer: http://localhost/admin/plugin-index.php 5. OX_Component::factory($extension = 'deliveryLimitations', $group = 'Client', $component = 'BrowserVersion') /var/ox/lib/OX/Plugin/Component.php:189, referer: http://localhost/admin/plugin-index.php How to fix this? Do I have to separately install Sinergi browser detector...? Thank you
  11. Can you give me any hint how to check if database was upgraded? Some specific field value, or type? But except the `rv_application_variable`.`oa_version`
  12. No. That's where I got surprised, that no further action was required. I refreshed the page, and probabluy because /var/INSTALLED file is present it just acts as usual, just like a normal upgraded installation.
  13. Does upgrade from 3.2.2 to 4.0.1 include any database changes? When I ran a test upgrade on a dev server, after copying files I entered admin GUI, and it gave me message, unfortunately, it is gone now, but it was something like "your version is 4.0.1 no upgrade is needed". Is that normal??
  14. Done: https://github.com/revive-adserver/revive-adserver/issues/806
  15. Distribution. Sometimes we want to switch admin servers and not to loose all currently logged in users' sessions.
  16. The problem of malvertising is becoming bigger issue all the time. I'd suggest adding an option to sandbox iframe tags, so that the stuff that runs in iframe would not be able to: perform top-window redirects run javascript (serve static HTML only) open any new windows (not clickable) prevent content from using plugins (eg. if you want to block video when you sell placement for HTML ads only)
  17. Moral: always run third-party ad vendors in sandboxed iframe.
  18. Your Revive installation might have been hacked, and malware is served right from your adserver (in zone append fields)
  19. As a temp walkaround: if you use nginx as frontend you can add headers in nginx host config.
  20. Actually, you can implement a complex solution that would pass the cookie to destination, and the destination upon conversion would craft a CURL request to Revive tracking script with that cookie in headers.
  21. This is very problematic. I'd suggest you to put a symlink named "www" that would point to "public".
  22. I was wondering if switching PHP's session storage to Memcached would not brake Revive Adserver admin interface and API. If it would not, my next question if setting session handler to a UNIX socket would still work okay, I am concerned about that, for example, because I see in Flexy in Translator.php the following: 'compileDir' => ini_get('session.save_path') . '/HTML_Template_Flexy_Translate', Obviously, in case of session.save_path like /var/run/memcached/memcached.sock the compilation would not work. Not sure if the above thing is any relevant for Revive admin interface. Thank you.
  23. Thank you for your reply. In the end it was something that I edited in Revive's core code. Just wanted to confirm that it was an incorrect behavior.
×
×
  • Create New...