Jump to content

andrewatfornax

Approved members
 View Profile  See their activity

  • Posts

    2007

  • Joined

  • Last visited

 Content Type 

Posts posted by andrewatfornax

  6. Targeting channel based on a HTML tag

    in Managing Revive Adserver

    Posted

    Hi,

    I don't think there's a way to support this with Revive Adserver, as such, but some ideas:

    • Write some JS code that will determine if the HTML code matches, and then dynamically modify the Revive Adserver tags to pass an appropriate targeting option through (e.g. keyword); or
    • If that's too complex (and it sounds like it), try doing that keyword setting when the HTML code is generated.

  7. Click and impression tracking from agency

    in Using Revive Adserver

    Posted

    Hi Michael,

    What's the impression tracking link look like - specifically, if you load the link in a banner, what does it return in the browser?

    Revive Adserver doesn't have support for call-back impression tracking, so you might need to load this link as an image or via JS or something, which would involve turning that GIF banner into an HTML banner, with the appropriate bits around it to make it all work...

  11. Max Db connections while maintenance

    in Managing Revive Adserver

    Posted

    On 6/7/2018 at 10:14 PM, Kush Rohra said:

    Earlier I was running maintenance every hour.

    That's good! It is recommended that you do.

    On 6/7/2018 at 10:14 PM, Kush Rohra said:

    But in some instances, when I receive a heavy amount of traffic the DB connections reaches a limit and then table level locking occurs. 

    That's not quite correct.

    If you are using MyISAM tables, then table level locking always occurs. Every single write to the table results in the whole table being locked, so only one write can happen at a time.

    What you really mean is that when you get heavy traffic, the table level locking starts to become a problem, and things don't work, because processes start to have to wait too long for their turn to lock the table, and things break.

    On 6/7/2018 at 10:14 PM, Kush Rohra said:

    Because as per my assumption if I am running maintenance every hour so it will read data and delete them. so that table gets space to insert new banner delivery records.

    Hence I would like to know is there a restriction or limit of the rv_data_bkt_m table? So that if i am receiving the banner delivery more then the size/restriction of table I need to find an alternative way to solve this max DB connection.

    Running maintenance will delete rows from the data bucket tables - but that's irrelevant. Revive Adserver is quite efficient in how it records impression data, so there's not really any limit to the number of rows it can have (other than what MySQL or PostgreSQL impose).

    The real issue with running out of connections to the database is (probably) because connections are staying around for so long, because they have to wait for so long to complete their writes, because you are using MyISAM, which uses table level locking.

    The solution is to move to InnoDB tables (or PostgreSQL).

  12. CORS, VAST, HELP

    in Managing Revive Adserver

    Posted

    Well, the error you are seeing seems pretty clear:

    The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'. Origin 'https://imasdk.googleapis.com' is therefore not allowed access.

    Seems like setting something other than the wildcard might help?

     

  15. What Files, What Permissions

    in Managing Revive Adserver

    Posted

    10 hours ago, jpt said:

    https://www.revive-adserver.com/support/upgrading/

    This page in the Revive Adserver docs recommends chmod 777. Is that page incorrect? What should I be doing instead when I upgrade my Revive Adserver instance?

    Ah, thank you. I did not know about that one. 

    I will look into getting this changed.

    What you should be doing is setting appropriate read/write permissions for your system.

    6 hours ago, scott001 said:

    It's your software, why not just give the exact permissions we need to set with a publicly facing site???

    Yes, Revive Adserver is our software - but it's not a complete solution. It needs a webserver, and an operating system underneath it as well, and those things vary greatly, and you can set things up there in a huge number of ways.

    It's like getting a new car radio, and the manual says before you install the new radio, make sure your car is switched off, and the handbrake is on, but then complaining that the car radio manual doesn't give you exact details on how to switch off your car and apply the handbrake for your exact car. Would you really expect the manual to document every single possible car model in the world, and describe how to do those things? No, you'd expect that the general information is sufficient, because if you're not sure how to do those things with your car, then it's reasonable to expect you to go away and look in the car's manual on how to do that.

    We expect the same thing - we tell you that you need to set read/write permissions on certain files and directories, and we expect you to look at your webserver/operating system manual, and do so in an appropriate way for your needs.

    7 hours ago, scott001 said:

    PS - I would not set this file /var/cache/www.mydomin.com_admin_container.php to anything other than 644 or higher, perhaps even 444 if that would work.

    And that's kind of the point - what you would do may or may not be suitable for everyone.

    7 hours ago, scott001 said:

    So why not just give your users the most conservative setting that will prevent the software from throwing the errors? That is all I am saying here. Why leave us to guess from dozens of possible permissions?

    Well, we do, in a way - we say what files and directories need to have read/write permissions by the webserver that's delivering the site. That's the minimum required, and if you do this in a way that's appropriate for your setup, then you will be good.

  16. What Files, What Permissions

    in Managing Revive Adserver

    Posted

    On 6/5/2018 at 3:50 AM, scott001 said:

    If I 777 all files under /var 777, then it will be open to the world.

    Correct - which is why I have not said that you should use chmod 777.

    I think my previous reply was quite correct - read/write access is required (for full Revive Adserver functionality - you can prevent write access to your configuration files if you want to lock down changes to the files via the admin UI, but that's a separate issue), and chmod 777 is a convenient way for users to do that - but it not what I recommend, and it's not what the documentation says.

    On 6/5/2018 at 3:50 AM, scott001 said:

    I only ask that you be precise, so that my server, and perhaps others, don't get hacked. Due to this situation, I am still unclear which files need 777.

    I think I have been precise - what is required is read/write access from the web server. 

    There are several ways to achieve that, and chmod 777 is the worst way, which is why we don't say that in the docs, and say (more precisely) what read/write permissions are needed.

    On 6/5/2018 at 4:10 AM, scott001 said:

    For example in /var/cache I seethis file which contains my site login/password:

    www.mydomin.com_admin_container.php

    Your instructions are telling me to chmod this 777, right?

    No, I don't believe that at any point have I said in the forums, or in the documentation, that you should chmod 777 anything. 

    If you do see that written somewhere, especially in the documentation, though, please let me know, and I will happily fix it.

    On 6/5/2018 at 4:29 AM, scott001 said:

    And here is what I believe it should say (note that I removed the var and plugins listings, because I don't think you mean those. I think you mean only the ones listed under those?

    The web server requires the ability to write to the following Revive Adserver directories and MOST files/directories under these locations (FOR APACHE THIS IS 777):

    var/cache (EXCEPT THE PHP FILES IN THERE, WHICH SHOULD BE 644)
    var/plugins
    var/templates_compiled
    www/admin/plugins
    www/images

    I respectfully disagree with you here. I do not believe that our documentation should advise anyone to use chmod 777 for anything. It is an overly permissive approach that I do not recommend.

    Sometimes, for some users, it's the right way to get the job done - but there are better approaches. 

    However, as always, what is important to some users is not relevant to others, so, we leave it to the user to decide the best approach of assigning the read/write permissions required for their individual circumstances. (For example, if you have a physically secure server, that has no general user access to it, then chmod 777 may well be a perfectly acceptable approach for you. But I'm not going to recommend chmod 777 in our docs.)

  17. Delivery capping by IP

    in Using Revive Adserver

    Posted

    Hi @Rob,

    It depends what you mean by "possible to instead implement".

    If you mean "is there a setting in Revive Adserver that I can flip, and it works on IP, rather than cookies", then the answer is no.

    If you mean "is it possible to alter the code base so that it works a different way", then the answer is yes.

  18. What Files, What Permissions

    in Managing Revive Adserver

    Posted

    On 6/2/2018 at 3:43 AM, scott001 said:

    Ok, so no reply...again, are you saying that I need to chmod my configuration file to 777? Would this not open it up, including my passwords, to the world?

    Patience my friend. 

    No, the conf files don't have to have 777 permissions. The various conf files only need to be writable by the web server user, if you want to update the configuration via the web UI. If you don't want to do that, then you don't need to have any write permissions on the config files - so long as the web server can read them, then you are good.

    However, under Revive Adserver's var directory, there are a number of subdirectories, and both var and all of the subdirectories, and their subdirectories, etc. are where Revive stores and caches all kinds of data.

    All of these directories and their files must be able to be read and written by the web server user.

    777 is not needed, but you will need an approach that allows the correct level of access - for many users with limited Unix experience, 777 is therefore a convenient approach.

  19. Max Db connections while maintenance

    in Managing Revive Adserver

    Posted

    Hi,

    Please remember that MyISAM tables implement table-level locking.

    So, during delivery of banners, only one banner can be logged at a time.

    The use of InnoDB may be more appropriate, given that it supports row level locking.

    While general database support is somewhat beyond the scope of this forum, please remember to always back up your database before making any changes!

  20. Max Db connections while maintenance

    in Managing Revive Adserver

    Posted

    No, you can't. Data is inserted into the table in real time as delivery happens (which cannot be changed), and is read from the table every time maintenance runs and the data needs to be summarised. 

    This should happen hourly when maintenance runs - it should not be a single, massive update once a day that takes a couple of hours. 

    It sounds to me more like the issue is that you are having database issues under delivery load, rather than because of maintenance.

    What database are you using? MySQL? Are you using MyISAM tables? What monitoring do you have in place on your server? How many DB connections are permitted? Can you add more? Have you checked if your setup is leaving database connections open that could be closed, and if so, have you tried tuning that?

  22. Cron Task - site url to append to the end

    in Managing Revive Adserver

    Posted

    Hi,

    The domain that is passed in as the parameter to the crontab entry to run maintenance should match the domain that the Admin UI runs on.

    As you are talking about a single install of Revive Adserver, with multiple URLs in use, you only need one crontab entry, as it doesn't matter what URL is used to access the UI or deliver banners, it's all the same database & set of statistics.

    See also https://documentation.revive-adserver.com/display/DOCS/Managing+Configuration+Files

×
×
  • Create New...