benwinton
-
Posts
19 -
Joined
-
Last visited
Posts posted by benwinton
-
-
RESOLVED:
I found two problems, and when I fixed them, everything upgraded correctly:1. Permissions: When you set permissions to certain folders to 777 for the upgrade (as described in the Documentation) be sure to also set them for the SUBFOLDERS. I failed to do that.
2. It appears that the original FTP upload of version 5.2.0 had errors and some of the files failed to upload. I discovered this when checking the FTP log file.
SOLUTION: Start over from scratch. Deleted everything. Grabbed a new copy of version 5.2.0, uploaded it, and set the correct folder permissions. Copied my version 5.1.1. database over to the new database, and everything worked like a charm. Hope this post helps anyone with similar issues.
-
I am unable to upgrade from version 5.1.1. to 5.2.0 because a plugin called OpenX3rdPartyAdservers cannot be found.
I searched for it manually in the etc folder, and also looked for it in the 5.1.1 version, just in case.
It flat-out does not seem to exist. But I receive error messages in the plugins report that the xml file for it cannot be found.
Also, the plugins did not get installed during the upgrade, like they normally do. I had to go back and manually extract the ZIP files and place the results in the plugins folder
I've performed dozens of upgrades over the years, so feel pretty adept at these types of things.
-
I bet this topic already is in a forum, but had a little trouble finding it. I apologize in advance.
Thanks to having a robust clientele and lots of advertising, our database is also getting really big.
Are there tips on how to prune the database to keep its size manageable? For example, I have emptied the _userlog table. I don't really need to see who's logged or when. It was good for about 1.5 MB. The biggest tables are data_intermediate_ad and data_summary_ad_hourly.
Is it safe th empty those? Or, is there a recommendation on how to at least prune them?
I can run sql commands, but am only at an intermediate skill level on that. So, any help construction such commands would be appreciated.
Thanks!
-
Thanks. Yes, I totally cleaned the system and removed the previous version. Despite all this, the hack continued.
This is still good advice, and much-appreciated. I found that deleting the old installation of Revive ASAP -- so that it did not even exist on the server any longer -- also helped mitigate.
But, a full malware scan, and additional security settings also were necessary.
In addition, reporting offending hackers to Google Adsense, as well as blacklisting them, seemed to help.
Oh, and -- most important -- change every password into your website, everywhere, no matter how painful. This includes FTP passwords, but also Wordpress passwords, and Adsense passwords. Do not use the old Adsense passwords under any circumstances.
Also, do not use the old Revive adserver passwords under any circumstances.
-
Even after upgrading to Version 4.2.0, a hacker was able to use script injection to force his/her ads with the following Adsense ID -- pub-6084777151829107 -- into my websites.
It appears this person found a way to get to a file named ads.txt, which is recommended by Google to allow specific Adsense IDs to be used on a website. The txt file is in the root directory of the site.
I installed additional security software on both the webserver and via the Web host, and for the last 12 hours, things have settled down.
I am not sure if the vulnerability is found in Adserver 4.2.0 or some other file in Wordpress. In any case, be on the lookout for this Adsense ID showing up on your site, especially if you notice Adsense revenues are down.
I reported the ID to Google, but I never hear back from Google on anything I send to them.
-
These are great instructions.
Unfortunately, the ad clicks are not tracked through Revive, so there's no way to see how things are performing, unless you log into your Adsense account.
Not a major issue, but it would be nice to see how the Adsense ads perform relative to all other ads on the same site.
-
Just a security alert:
After upgrading to Version 4.2.0 as quickly as possible, and following the upgrade procedures on the Revive website, my site still got hacked.
How?
Here is what I think happened:
I followed the upgrade procedures found here, at this link, and these are excellent instructions, I would still follow: https://www.revive-adserver.com/support/upgrading/
But, I left my OLD backup files on the server. I had renamed the old directory to "bak" or something similar, to disable access to it.
In spite of this, sometime in the 72 hours after the upgrade, the hackers mentioned in the security update notes, managed to exploit my Wordpress files and begin injecting their own ad code.
As soon as I replaced the Wordpress files with my backup files, the hacked ads stopped appearing.
Be on the lookout -- and remove any backup installs of your Adserver files asap, and the database, if it is a migrated or copied file.
Thanks.
-
Andrew,
Thank you for the response. I might have found a workaround that has been successful for the last 48 hours:
1. Create a new ad zone and set the wildcards for the height and width -- "*".
2. Create a new Google Adsense banner and set its height and width to something arbitrary. I chose 800x133, because that seemed close to the proportions of their full-sized Native ad format.
3. Assign the new Adsense Native banner to the new ad zone that has the wildcards for its height and width.
The Native ad format seems to be getting displayed and tracked properly on some test pages I created.
Just a workaround. Maybe in a future release, Revive might have an even greater solution. :)
Thanks!
-
Not too long ago, Google introduced "Native ads" that can respond to the content AND the device around them to provide a more streamlined user experience between content and advertising on the website.
However, I am not finding an easy way to integrate the code into the latest version of Revive Adserver.
If I select Generic HTML as the format, I am forced to specify an IAB ad-unit size, which entirely defeats the purpose of "Native ads." Native ads change shape and size automatically, to adjust to the device and to the content around them. It's sort of like a responsive ad, but even more so -- maybe a responsive ad on steroids.
How do you integrate AdSense's new Native ad format into the most current version of Revive Adserver?
-
Thanks, Andrew. That is what I was thinking, and it helps to verify all is working as expected.
-
For Andrew: My conf file is set to 644, but I still receive the warning -- as well -- for Version 4.1.1.
Is there a way to remove the warning, and still have the permission on that file set to 644, or are we just stick with having to ignore the warning message?
Sorry, I forgot to turn on the "notify me" feature of this forum. Just did that.
-
Agreed! This is truly a bug, and it should be treated as such over at Github! Let's report the bug a second time to the developers and see if they "get it" this time. If not, and they close it again, we'll re-open it. If that fails, we can always let the world know that the support for the open source has degraded substantially since Version 3.0.3. and warn the public to be wary of further upgrades! One way to get developers to pay attention is to start letting the world know that they are NOT paying attention to their customers.
-
Glad my solution (workaround) is successful. The directory at /adserver/maintenance (replace "adserver" with the name of your top-level revive directory), should be at least 755. (However, I set mine at 777 during testing to verify no issues with permissions.)
Also, the directory at /adserver/scripts/maintenance should be at least 755.
That should do it, and allow maintenance to run, which in turn affects statistics.
-
I resolved mine by doing the following:
1. Locate the RV.php file. It should be at /lib directory of your revive installation.
2. Edit line 13 as follows: Change the line from this -- "require_once RV_PATH . '/lib/pear/PEAR.php';" to this, instead: require_once 'fully_qualified_server_path/adservername/lib/pear/PEAR.php'; ("fully_qualified_server_path" would be your host or webserver path. "adservername" is the name of your directory where revive 3.0.3. is installed, typically something like "revive.")
Also check that your maintenance scripts are chmod'd to at least 755. I set mine to 777 for now, but am experimenting with lowering them back to 755.
-
I found a solution. In the /lib file, there is a new file named RV.php that does not seemed to have existed before version 3.0.3 of Revive. The path to PEAR.php file on line 13 is coded up incorrectly.
You have to put the fully qualified server path to PEAR.php in that file, eg, "require_once '/homepages/16/e34564563465/htdocs/ads/revive/lib/pear/PEAR.php';
(This is a fictional path above, for security reasons, but illustrates what the line should look like when fixed. I did not try using a fully qualified domain URL, eg, http://somedomain.com/revive/lib/pear/PEAR.php, but that might also be worth a shot to see if it works. I doubt that it will.)
The only other thing I did was chmod the maintenance scripts from 755 to 777. I dont like doing that, and might try lowering them back to 755 to see if stats and automatic maintenance continues to run.
Hoping this gets fixed over at GitHub, where there is a bug reported on this item, as well.
-
Still having a problem. Followed all the suggestions listed, so far, in this thread, to no avail.
-
Thank you Snoork Hosting for the response. I meant to write that there are no NEW statistics. The previous statistics remained frozen at the same numbers that existed at the same time as the upgrade occurred.
-
I am continuing to have the same problem -- no statistics generated -- since upgrading to 3.0.3. I reinstalled all plugins in the following manner:
1. Disabled all plugins via the Admin Panel.
2. Uninstalled all plugins via the same panel.
3. FTP'd to the webserver and deleted all plugin folders.
4. Via the Admin Panel in Revive, I reinstalled all plugins by browsing to the /etc directory and selecting each zip file. (I used the new download for Revive 3.0.3. to ensure I had the latest plugin versions.)
5. Set my config file to chmod 777 and checked all settings. Did not change any settings. All looked good. So, I re-set the permissions on the config file (in the /var directory) to 644.
Waited 1 hour. Still no new statistics.
This problem first happened after the upgrade to the latest Revive version. The upgrade was done by following up the upgrade instructions.
Configuration file not locked, even though it is?
in Managing Revive Adserver
Posted
For years, I have been seeing the following message atop the Global Settings view:
" It is possible to edit all settings because the configuration file is not locked, but this could lead to security issues. If you want to secure your system, you need to lock the configuration file for this installation."
The file (the one ending in .conf in the var directory) is set to 644 on permissions.
What am I missing? I cannot find anything about this in the documentation or help files.
(Apologies for the yellow background on text.) I copied and pasted the warning message, and there seems to be no way to clear formatting in this wysiwig editing tool for forum posts, lol. Just having a bad day.)