DocumentRoot with Redirect and the effect on logging and traffic stats

[ocitsupport]

Hello,

 

we successfully set up Froxlor on Ubuntu Bookworm 22.04.1. We mainly use it for redirecting domains. So far so good 😀.

Now we would like to messure using the traffic statistics (goaccess) how often a redirect is "triggered". But the statistics seem empty. Cron is running.

Investigating the issue we found that when using DocumentRoot to redirect, no logging configuration is made. Even if setting custom (SSL) vHost settings like "LogLevel info rewrite:trace6" these are not written to the configuration file. Is that correct?

Also in any case, even if DocumentRoot is not used for redirecting, the domain configuration option "Separate Logfile" can be set but is ignored. Meaning the next time the configuration page is opened the toggle button is off again.

 

Can you help me with that?

Thank you.

 

Ciao,

Rene

[d00p]

check the vhost, is there a "AccessLog" directive being generated? if yes, does the log file exist and do entries get logged on visit?

[ocitsupport]

no "AccessLog" directive is generated. The SSL vhost looks like this:

  ServerName xyz
  ServerAlias xyz
  ServerAdmin xyz
  SSLEngine On
  SSLProtocol -ALL +TLSv1.2
  SSLCompression Off
  SSLSessionTickets on
  SSLHonorCipherOrder off
  SSLCipherSuite ECDH+AESGCM:ECDH+AES256:!aNULL:!MD5:!DSS:!DH:!AES128
  SSLVerifyDepth 10
  SSLCertificateFile /etc/ssl/froxlor-custom/xyz.crt
  SSLCertificateKeyFile /etc/ssl/froxlor-custom/xyz.key
  SSLCACertificateFile /etc/ssl/froxlor-custom/xyzCA.pem
  SSLCertificateChainFile /etc/ssl/froxlor-custom/xyzchain.pem
  <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge
    RewriteRule ^/(.*) https://www.xyz.de$1 [R=301;L,NE]
  </IfModule>
  <IfModule !mod_rewrite.c>
    Redirect 301 / https://www.xyz.de
  </IfModule>

 

 

[d00p]

Yup, just checked, there are no log-directives generated when the domain is a redirect

[d00p]

try the following patch:

diff --git a/lib/Froxlor/Cron/Http/Apache.php b/lib/Froxlor/Cron/Http/Apache.php
index f3fe3f6b..609f9164 100644
--- a/lib/Froxlor/Cron/Http/Apache.php
+++ b/lib/Froxlor/Cron/Http/Apache.php
@@ -823,6 +823,7 @@ class Apache extends HttpConfigBase
                                        $modrew_red = ' [R=' . $code . ';L,NE]';
                                }

+                               $vhost_content .= $this->getLogfiles($domain);
                                // redirect everything, not only root-directory, #541
                                $vhost_content .= '  <IfModule mod_rewrite.c>' . "\n";
                                $vhost_content .= '    RewriteEngine On' . "\n";

 

[ocitsupport]

vor 52 Minuten schrieb d00p:

try the following patch:

diff --git a/lib/Froxlor/Cron/Http/Apache.php b/lib/Froxlor/Cron/Http/Apache.php
index f3fe3f6b..609f9164 100644
--- a/lib/Froxlor/Cron/Http/Apache.php
+++ b/lib/Froxlor/Cron/Http/Apache.php
@@ -823,6 +823,7 @@ class Apache extends HttpConfigBase
                                        $modrew_red = ' [R=' . $code . ';L,NE]';
                                }

+                               $vhost_content .= $this->getLogfiles($domain);
                                // redirect everything, not only root-directory, #541
                                $vhost_content .= '  <IfModule mod_rewrite.c>' . "\n";
                                $vhost_content .= '    RewriteEngine On' . "\n";

 

OK. LogLevel, ErrorLog and CustomLog are now generated.

Can you say why "Separate logfiles" is not permanently set? I found the "vhost_combined" option which helps me a lot already. But separate logs per domain would be nice too.

 

[d00p]

Just now, ocitsupport said:

Can you say why "Separate logfiles" is not permanently set?

This is a per domain setting and should be stored permanently of course. Let me run some checks and get back to you

[d00p]

Oh yeah there seems to be an issue with a ajax-request to for this option, need a bit more time for that

[d00p]

There is indeed a bug with this, missing csrf-tokens in some ajax-requests, I will have to make a bugfix release for that (or you would have to build the assets yourself with npm etc. if you want, let me know). Most like on friday this week then

[ocitsupport]

vor einer Stunde schrieb d00p:

There is indeed a bug with this, missing csrf-tokens in some ajax-requests, I will have to make a bugfix release for that (or you would have to build the assets yourself with npm etc. if you want, let me know). Most like on friday this week then

Thank you very much for the quick response. No problem. I can wait for a fix. No need to hassle.