jamieburchell

Bump

Hey Long time Revive Adserver user here (since when it was OpenX). For each upgrade I have copied the existing config file over as per the instructions. Now I'm wondering if anything needs to be changed in the config to use/convert to utf8mb4? Here's the config I'm using (there doesn't seem to be a "reference config" to look at): [database] type=mysqli host=localhost socket="/var/lib/mysql/mysql.sock" port=3306 persistent= mysql4_compatibility=1 protocol=tcp compress= ssl= capath= ca= [databaseCharset] checkComplete=1 clientCharset= [databaseMysql] statisticsSortBufferSize=

Hi Can you tell me what negative impact anonymising the visitor's IP has? I've read that it's used for geo location and for recording conversions and preventing duplicates. Presumably an anonymised IP doesn't affect geo location, but does it affect the ability to identify duplicate conversions? Does it have any other negative effect? TIA Jamie

Please can I request that the Revive team take another look at this, as it's still an issue today. I already took the step to force an envelope sender address: php_value[sendmail_path] = /usr/sbin/sendmail -t -i [email protected] But if you see, it's the other from address that is getting set/mangled by Revive: To: "Administrator" <team@xxx> Subject: Impending campaign expiration: XXX X-PHP-Originating-Script: 1005:Email.php ... From: "n" <[email protected]> X-Original-Authentication-Results: mx.google.com; dkim=pass [email protected] header.s=krs header.b="b/nn6hqL"; spf=pass (google.com: domain of [email protected] designates XXX as permitted sender) [email protected] Line in maillog: Sep 12 00:05:03 x postfix/cleanup[1549]: 9F27F4696CC: prepend: header From: "n" <n> from local; from=<[email protected]>: X-Mailgun-Native-Send: true In my Revive config: [ email ] (without spaces) logOutgoing=1 headers= qmailPatch= fromName="Admin" fromAddress="[email protected]" fromCompany="My Company" useManagerDetails= Further, all of my Advertisers have email addresses and names configured. I think there's at least one potential issue in the Email.php file: https://github.com/revive-adserver/revive-adserver/blob/master/lib/OA/Email.php#L53 What happens if $aConf['email']['useManagerDetails'] is false? $aFromDetails does not get defined but is used further down. TIA Jamie

I'm having the same issue and have had the same issue for a long time. The from header is being set as "n" <n@hostname> where hostname is the machine name. The quotes appear to be part of the name too, according to my inspection of the headers in our Mailgun account: "from": "\"n\" <n@hostname>" The "Email 'From' Email Address" in the settings is set to no-reply@ and a different domain. Doesn't seem to be getting picked up. The From name and company were blank, I've tried completing those to see if it makes any difference but am unsure how to trigger a test email. Log all outgoing email messages is ticked, but I can't see where they are being logged to.

It's not always possible or desirable to set the envelope sender system wide (https://stackoverflow.com/questions/24183058/how-can-i-force-the-from-header-envelope-sender-in-php-without-putting-it-in) in my view, Revive should be setting the envelope sender properly when calling the mail function. Libraries like Swift Mailer, PHPMailer et al already do this or let you specify it.

Was this ever resolved? I have a problem with Revive sending emails out from php-fpm@server because Revive does not set the envelope sender (only the from header is set from the address specified in the admin). If Revive is using PHP mail() directly, there's a 5th parameter which can be used to set this: "For example, this can be used to set the envelope sender address when using sendmail with the -f sendmail option." http://php.net/manual/en/function.mail.php Is there a fix or workaround?

Turns out that's fixed by setting the correct images path in the config *doh*

I always seem to run in to this. In my case I'm still getting the red notification on login, but I have already set the following directories to be owned and writable by the apache web user. SELinux is disabled. Of course, the debug.log never actually shows anything. $ chown -R apache:apache var $ chown -R apache:apache plugins $ chown -R apache:apache www/admin/plugins $ chown -R apache:apache www/images $ chmod -R u=rwX,go=rX var $ chmod -R u=rwX,go=rX plugins $ chmod -R u=rwX,go=rX www/admin/plugins $ chmod -R u=rwX,go=rX www/images $ chmod 444 x.conf.php $ find . -type d -user apache ./www/admin/plugins ./www/admin/plugins/videoReport ./www/admin/plugins/videoReport/css ./www/admin/plugins/videoReport/templates ./www/admin/plugins/videoReport/navigation ./www/admin/plugins/videoReport/lib ./www/admin/plugins/videoReport/lib/Csv ./www/admin/plugins/videoReport/lib/ofc2 ./www/admin/plugins/videoReport/lib/Url ./www/admin/plugins/videoReport/lib/Graph ./www/admin/plugins/videoReport/lib/Graph/Flash ./www/admin/plugins/videoReport/lib/SmartyFunctions ./www/admin/plugins/videoReport/images ./www/admin/plugins/videoReport/js ./www/images ./www/images/layerstyles ./www/images/layerstyles/geocities ./www/images/layerstyles/simple ./plugins ./plugins/invocationTags ./plugins/invocationTags/oxInvocationTags ./plugins/invocationTags/oxInvocationTags/layerstyles ./plugins/invocationTags/oxInvocationTags/layerstyles/geocities ./plugins/invocationTags/oxInvocationTags/layerstyles/simple ./plugins/invocationTags/oxInvocationTags/layerstyles/floater ./plugins/invocationTags/oxInvocationTags/layerstyles/cursor ./plugins/invocationTags/oxInvocationTags/_lang ./plugins/deliveryLimitations ./plugins/deliveryLimitations/Time ./plugins/deliveryLimitations/Client ./plugins/deliveryLimitations/Geo ./plugins/deliveryLimitations/Geo/data ./plugins/deliveryLimitations/Site ./plugins/3rdPartyServers ./plugins/3rdPartyServers/ox3rdPartyServers ./plugins/geoTargeting ./plugins/geoTargeting/oxMaxMindGeoIP ./plugins/geoTargeting/oxMaxMindGeoIP/data ./plugins/bannerTypeHtml ./plugins/bannerTypeHtml/vastInlineBannerTypeHtml ./plugins/bannerTypeHtml/vastOverlayBannerTypeHtml ./plugins/bannerTypeHtml/oxHtml ./plugins/reports ./plugins/reports/oxReportsStandard ./plugins/reports/oxReportsAdmin ./plugins/deliveryLog ./plugins/deliveryLog/oxLogVast ./plugins/deliveryLog/oxLogImpression ./plugins/deliveryLog/oxLogConversion ./plugins/deliveryLog/vastServeVideoPlayer ./plugins/deliveryLog/vastServeVideoPlayer/flowplayer ./plugins/deliveryLog/vastServeVideoPlayer/flowplayer/3.1.1 ./plugins/deliveryLog/oxLogRequest ./plugins/deliveryLog/oxLogClick ./plugins/deliveryCacheStore ./plugins/deliveryCacheStore/oxMemcached ./plugins/deliveryCacheStore/oxCacheFile ./plugins/etc ./plugins/etc/oxLogVast ./plugins/etc/oxLogVast/etc ./plugins/etc/Time ./plugins/etc/oxLogImpression ./plugins/etc/oxLogImpression/etc ./plugins/etc/oxLogConversion ./plugins/etc/oxLogConversion/etc ./plugins/etc/oxDeliveryDataPrepare ./plugins/etc/oxDeliveryDataPrepare/etc ./plugins/etc/oxDeliveryDataPrepare/etc/changes ./plugins/etc/oxDeliveryDataPrepare/etc/DataObjects ./plugins/etc/oxText ./plugins/etc/Client ./plugins/etc/Client/etc ./plugins/etc/Client/etc/changes ./plugins/etc/Geo ./plugins/etc/oxReportsStandard ./plugins/etc/vastInlineBannerTypeHtml ./plugins/etc/vastInlineBannerTypeHtml/etc ./plugins/etc/vastInlineBannerTypeHtml/etc/changes ./plugins/etc/vastInlineBannerTypeHtml/etc/DataObjects ./plugins/etc/vastServeVideoPlayer ./plugins/etc/vastOverlayBannerTypeHtml ./plugins/etc/oxReportsAdmin ./plugins/etc/oxMaxMindGeoIP ./plugins/etc/oxInvocationTags ./plugins/etc/oxLogRequest ./plugins/etc/oxLogRequest/etc ./plugins/etc/oxLogClick ./plugins/etc/oxLogClick/etc ./plugins/etc/oxMemcached ./plugins/etc/oxMemcached/_lang ./plugins/etc/oxMemcached/_lang/po ./plugins/etc/ox3rdPartyServers ./plugins/etc/ox3rdPartyServers/_lang ./plugins/etc/ox3rdPartyServers/_lang/po ./plugins/etc/oxCacheFile ./plugins/etc/oxCacheFile/_lang ./plugins/etc/oxCacheFile/_lang/po ./plugins/etc/Site ./plugins/etc/videoReport ./plugins/etc/oxHtml ./plugins/bannerTypeText ./plugins/bannerTypeText/oxText ./plugins/deliveryDataPrepare ./plugins/deliveryDataPrepare/oxDeliveryDataPrepare ./plugins/videoAds ./var ./var/cache ./var/plugins ./var/plugins/recover ./var/plugins/DataObjects ./var/templates_compiled Error: File permission errors detected.These may impact the accurate delivery of your ads,See the debug.log file for the list of unwritable files

I'm always weary of third party software recommending or requiring setting directory permissions to 777. Is it possible to deny direct access to PHP files in these directories or will it break the software? ./var ./var/templates_compiled ./var/plugins ./var/plugins/DataObjects ./var/plugins/recover ./var/cache ./www/images ./www/admin/plugins ./pluginsSpecifically using an Apache configuration like this, which would be fine providing the PHP files are only included and not accessed directly: <Directory ~ /(var|www/images|www/admin/plugins|plugins)/> php_admin_flag engine off <Files *.php> Order Deny,Allow Deny from all </Files> </Directory> We've been bitten a few times with leaky software that has enabled PHP files to be created in writeable directories and executed to install web shells. This attempts to reduce that risk by disabling PHP execution/denying PHP access directly in the browser.

Yeah, sorry my question was miss-leading. I was just curious to know why when the list of chmod commands do show, that one is missing. Good luck!

Why doesn't the installation script prompt you to chmod OpenX_new/www/images ? It provides an entire list of folders to copy and paste on the command line except for this one. You get the red warning bar about it if you don't set it correctly.

Yep, that's what I followed to do the upgrade. During the upgrade it went through all of the old plugins including OXMarket and installed/enabled them. I guess it shouldn't do that?

I managed to sort this out by temporarily removing the oxMarket folder from www/admin/plugins and using the plugin maintenance screen to uninstall oxMarket and openXWorkflow. I probably could have edited the config file manually to make them disabled, not sure if I would have been able to remove them though. How/where can I check/update the plugins to their latest version? Should I remove the config entries for OpenX Market / openXWorkflow and the files still in www/admin/plugins?

So basically I need to uninstall the plugins. Which is fine, except I can't access anywhere now without that PHP fatal coming up.

Hi Just upgraded to Revive Adserver 3.0.1 and now I'm getting this PHP fatal error when accessing certain areas of the admin interface. I've checked and the M2M folder existed on the old installation but not in the new. It seems to be related to the OX Marketplace plugin. The install.log said it couldn't find the XML files for each plugin, however the interface shows they are all installed. What do I do? Cheers Jamie