Erik Geurts

I assume you mean debug.log. Yes, you can delete it, it will just be created again automatically.

Revive Adserver requires 'all privileges' during operation and during upgrades, for example to be able to create temporary or new tables.
 
I recommend contacting your provider and recommending that they fix that one-click installer they offer.

There is no technical limit in the software for the number of targeting channels you can create.

The term cb means cache buster. The value of the cb parameter is intended to be randomized so that browsers don't run it from their cache. It is not something that will be stored anywhere.

Please have a look at http://www.reviveconsultant.com/articles/how-to-move-the-banner-image-storage-location-in-revive-adserver/ which is what we've assumed you've done before performing an upgrade as described here http://www.revive-adserver.com/support/upgrading/

This is a known issue https://github.com/revive-adserver/revive-adserver/issues/549 which will be fixed in the upcoming release v3.2.1.

Your existing code will continue to work before, during and after the upgrade to v3.2.0. After the upgrade, it's your choice if you want to switch to asynchronous tags immediately or perhaps gradually. We'll be adding more information and documentation about this in the coming days and weeks.

That's documentation for an entirely different product. See http://blackriver.to/2014/01/openx-source-revive-adserver-magic-macros/

http://documentation.revive-adserver.com/display/DOCS/Delivery+options

Revive Adserver has been designed to display banners in a random order, where the weights (on remnant campaigns) drive the calculations that result in probabilites. Having a higher probability for a banner does not mean it is more likely to show up first, it just means its more likely to show up (period).

Revive Adserver was not designed to produce real time statistics. The statistics will be updated at the top of the hour.

Targeting channels are related to delivery limitations but they have nothing to do with this question.
 
You need to add the site variable to the SPC code line:
 
<script type='text/javascript'><!--// <![CDATA[
var type = '02';
// ]]> --></script><script type='text/javascript' src='http:  //  www.example.com/www/delivery/spcjs.php?id=1&amp;target=_blank'></script>
 
becomes:
 
<script type='text/javascript' src='http:  //  www.example.com/www/delivery/spcjs.php?id=1&type=15&amp;target=_blank'>
 
That's all.

It's not required, please see http://www.revive-adserver.com/faq/geotargeting-with-revive-adserver/

Yes, when you delete a zone, all the statistics associated with that zone will also be deleted.
 
This also means that all statistics associated with any of the banners that have ever been delivered through that zone will also be deleted.
 
In general, I would recommend that you never delete anything. Storage space is virtually free these days anyway.

A campaign that's created inside one account is completely invisible from any other account. Likewise, a site and zone created in one account is not accessible from any other account.
 
The reason is that each account is a completely separate entity, what happens on one account is locked inside that account.

When you're serving an ad that's in fact an iframe, then Revive Adserver has no control over the content of the ad inside the iframe, and therefore the {clickurl} macro won't work. What you're trying to achieve is impossible. This has nothing to do with Revive Adserver specifically, it won't work in any ad server if the ad is an iframe with the actual ad inside the iframe.

An advertiser user can view the statistics of their own campaign, but they can't make any changes.

The issue has been fixed, it turned out to be a faulty configuration of the Nginx software, nothing related to Revive Adserver itself.

The reason is that Juicyads tags don't support third party click tracking. Contact them to inquire about their options for it.

Please follow the process described on the page at http://www.revive-adserver.com/support/upgrading/ . Upgrading and Updating is the same.
 
Do not simply copy the new files over the old files, it will result in a broken system.

I'm sorry, but OpenAds 2.0 does not have a password recovery feature.
 
Do you know how to access the MySQL database that is associated with this installation? There is a table in there called x_config (with x_ being your own table name prefix). In that table there is probably just one record, and one of the fields in the record is called "admin_pw".
 
That field contains the MD5 hash of your password. Just come up with a new (secure!) password, then use http://hash.online-convert.com/md5-generator to generate the MD5 hash of that new password and paste it into the admin_pw field.
 
I haven't tested it myself, but this should enable you to set your password again.
 
By the way, have you considered upgrading to Revive Adserver 3.0.x? With OpenAds 2.0, you are about a decade behind...

Being hacked on your current instance of v3.0.3 is by itself not proof that there is a vulnerability. Unfortunately, we've seen many cases where people had their installation compromised a long time ago, and then just recently their system got attacked by someone using the credentials that were taken or created all that while ago.
 
If you do find evidence of a security issue, please read this page http://www.revive-adserver.com/security/ carefully and follow the instructions there.