Log Format for combinedvhost not getting distilled / configured locally
The current logformat line:
LogFormat "%v:%p %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combinedvhost
isn't configurable through local /var/cpanel/conf/apache/ and isnt getting distilled either. The other ones are distilled successfully.
We're using mod_remoteip and need to change %h to the new format: %a instead to log the X-Forwarded-From ip address correctly.
The new line should read:
LogFormat "%v:%p %a %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combinedvhost
A workaround right now is to duplicate the whole mod_log_config block and put it in pre_virtualhost_global.conf, but it's not future proof ;)
<IfModule mod_log_config.c>
...
</IfModule>
Please make that LogFormat line configurable so we can choose different formats if we choose to.
More info / research available in cPanel Ticket id: 4961803
I like this idea 
cPanel, WebHost Manager and WHM are registered trademarks of cPanel, L.L.C. for providing its computer software that facilitates the management and configuration of Internet web servers.
As it stands, the product intentionally ignores all attempts to distill modified LogFormat lines that contain "combinedvhost" or "bytesvhost". The justification for this is simply that there are other product features that rely upon a specific formatting (such as our web statistics programs: awstats, analog, webalizer).
Modifying the LogFormat to something different can very well break all web statistics processing. However, in your particular case, you're actually fixing the improperly reported IP caused by your use of mod_remoteip. Your change would not break statistics in this particular case.
However, this is also an inconsistency between log handling in our product. When you are NOT using Piped Logging (which you seem to be using), the LogFormat just utilizes "combined", which we do permit to be distilled and modified.
Therefore, I agree that it's certainly reasonable to bring "Piped Logging (combinedvhost)" into the same functionality that "Non Piped Logging (combined)" benefits of being able to distill changes to the primary LogFormat used.
By extension of what I've mentioned, it is therefore currently possible to gain the functionality you want by going back to the standard logs processing method instead of Piped Logging. However, there's definite tradeoffs with that as you likely are aware.
The more feedback/votes we receive on this, the more likely it will be considered for a future release.
As it stands, the product intentionally ignores all attempts to distill modified LogFormat lines that contain "combinedvhost" or "bytesvhost". The justification for this is simply that there are other product features that rely upon a specific formatting (such as our web statistics programs: awstats, analog, webalizer).
Modifying the LogFormat to something different can very well break all web statistics processing. However, in your particular case, you're actually fixing the improperly reported IP caused by your use of mod_remoteip. Your change would not break statistics in this particular case.
However, this is also an inconsistency between log handling in our product. When you are NOT using Piped Logging (which you seem to be using), the LogFormat just utilizes "combined", which we do permit to be distilled and modified.
Therefore, I agree that it's certainly reasonable to bring "Piped Logging (combinedvhost)" into the same functionality that "Non Piped Logging (combined)" benefits of being able to distill changes to the primary LogFormat used.
By extension of what I've mentioned, it is therefore currently possible to gain the functionality you want by going back to the standard logs processing method instead of Piped Logging. However, there's definite tradeoffs with that as you likely are aware.
The more feedback/votes we receive on this, the more likely it will be considered for a future release.
As it stands, the product intentionally ignores all attempts to distill modified LogFormat lines that contain "combinedvhost" or "bytesvhost". The justification for this is simply that there are other product features that rely upon a specific formatting (such as our web statistics programs: awstats, analog, webalizer).
Modifying the LogFormat to something different can very well break all web statistics processing. However, in your particular case, you're actually fixing the improperly reported IP caused by your use of mod_remoteip. Your change would not break statistics in this particular case.
However, this is also an inconsistency between log handling in our product. When you are NOT using Piped Logging (which you seem to be using), the LogFormat just utilizes "combined", which we do permit to be distilled and modified.
Therefore, I agree that it's certainly reasonable to bring "Piped Logging (combinedvhost)" into the same functionality that "Non Piped Logging (combined)" benefits of being able to distill changes to the primary LogFormat used.
By extension of what I've mentioned, it is therefore currently possible to gain the functionality you want by going back to the standard logs processing method instead of Piped Logging. However, there's definite tradeoffs with that as you likely are aware.
The more feedback/votes we receive on this, the more likely it will be considered for a future release.
As it stands, the product intentionally ignores all attempts to distill modified LogFormat lines that contain "combinedvhost" or "bytesvhost". The justification for this is simply that there are other product features that rely upon a specific formatting (such as our web statistics programs: awstats, analog, webalizer).
Modifying the LogFormat to something different can very well break all web statistics processing. However, in your particular case, you're actually fixing the improperly reported IP caused by your use of mod_remoteip. Your change would not break statistics in this particular case.
However, this is also an inconsistency between log handling in our product. When you are NOT using Piped Logging (which you seem to be using), the LogFormat just utilizes "combined", which we do permit to be distilled and modified.
Therefore, I agree that it's certainly reasonable to bring "Piped Logging (combinedvhost)" into the same functionality that "Non Piped Logging (combined)" benefits of being able to distill changes to the primary LogFormat used.
By extension of what I've mentioned, it is therefore currently possible to gain the functionality you want by going back to the standard logs processing method instead of Piped Logging. However, there's definite tradeoffs with that as you likely are aware.
The more feedback/votes we receive on this, the more likely it will be considered for a future release.
Good grief guys - this has gone on long enough... It's easy enough to put the original code back into the template if one breaks it. Please lets include the combinedvhost LogFormat entry already!
Good grief guys - this has gone on long enough... It's easy enough to put the original code back into the template if one breaks it. Please lets include the combinedvhost LogFormat entry already!
Replies have been locked on this page!