Share logrotate config with all domains... doesn't share.

Submitted by Kintaro on Fri, 08/18/2017 - 07:08

I still have this problem: https://www.virtualmin.com/node/37409

In a 5.99 Debian 8 system with nginx and in a newly installed 6.03 Ubuntu 16.4 system with Apache2.

Am I the only one?

Status: 
Closed (fixed)

Comments

Submitted by andreychek on Fri, 08/18/2017 - 09:12

To save Jamie a little time, can you summarize the nature of the issue you are seeing?

There's a number of posts/comments in the Forum thread there, just summarize all that into one post here if you could. Thanks!

Submitted by Kintaro on Mon, 08/21/2017 - 02:47

Virtualmin 5.99:

I set "Share logrotate configuration with all domains?" to YES in server template.

I'm expecting to see a single configuration in log rotate with all the Virtual Servers files "inside", instead Virtualmin created a different configuration for each.

Did I misunderstand something?

I really think that I misunderstood something in this HELP:

When this is set to No, Virtualmin will create a separate block in the logrotate configuration file for each virtual server. This allows each to have different settings but will cause the web server to be restarted after the rotation of each domains' logs - possibly interrupting service. Selecting Yes will cause all new domains to share a single configuration block, which means the web server only has to be restarted once. However, it is not possible to have different rotation settings for each domain.

I set it to YES but if I create a new Virtual Server have separated blocks anyway.

I found that if in an already created server or sub-server I disable the log rotation, "stand alone" configuration is correctly deleted and if I re-enable it the configuration this time is correctly shared!

Virtualmin 6: I helped a friend with a new Virtualmin 6 installation and it behaves in the same way. virtual servers have separated log rotation configuration even is the "Share logrotate configuration with all domains" is set to yes (actually I don't know if the un-check/re-check fix it also on V6).

The same issue is been reported from RopertoPastor: https://www.virtualmin.com/comment/747721#comment-747721 https://www.virtualmin.com/comment/747763#comment-747763

Submitted by JamieCameron on Mon, 08/21/2017 - 10:10

Did you enable that "Share logrotate configuration with all domains?" option before or after creating your virtual servers? Because it only applies to domains created afterwards, unless you disable and then re-enable log rotation for all domains.

This can be easily done from the command line as root with :

virtualmin disable-feature --all-domains --logrotate
virtualmin enable-feature --all-domains --logrotate

Submitted by Kintaro on Fri, 08/25/2017 - 16:38

it seems to work... but for some reason domainsI under https get this error:

"SSL cannot be enabled unless a website is configured"

I confirm that those domains are working in SSL without any problem.

This is my standard configuration for https websites:

server {
server_name domain.com www.domain.com;
listen xxx.xxx.xxx.xxx;
root /home/domain/public_html;
index index.html index.htm index.php;
access_log /var/log/virtualmin/domain.com_access_log;
error_log /var/log/virtualmin/domain.com_error_log;
fastcgi_param GATEWAY_INTERFACE CGI/1.1;
fastcgi_param SERVER_SOFTWARE nginx;
fastcgi_param QUERY_STRING $query_string;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
fastcgi_param SCRIPT_FILENAME /home/domain/public_html$fastcgi_script_name;
fastcgi_param SCRIPT_NAME $fastcgi_script_name;
fastcgi_param REQUEST_URI $request_uri;
fastcgi_param DOCUMENT_URI $document_uri;
fastcgi_param DOCUMENT_ROOT /home/domain/public_html;
fastcgi_param SERVER_PROTOCOL $server_protocol;
fastcgi_param REMOTE_ADDR $remote_addr;
fastcgi_param REMOTE_PORT $remote_port;
fastcgi_param SERVER_ADDR $server_addr;
fastcgi_param SERVER_PORT $server_port;
fastcgi_param SERVER_NAME $server_name;
fastcgi_param HTTPS $https;

listen xxx.xxx.xxx.xxx:443 ssl http2;
ssl_certificate /home/domain/ssl.cert;
ssl_certificate_key /home/domain/ssl.key;

location ~ \.php$ {
try_files $uri =404;
fastcgi_pass localhost:8006;
}
   
location / {
try_files $uri $uri/ /index.php?q=$uri&$args;
}

location ~* \.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|js|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$
    {
    expires 30d; log_not_found off; access_log off;
add_header "Access-Control-Allow-Origin" "*";
add_header Cache-Control "public";
    }

location ~ (^|/)\. {
    return 403;
}

}

Submitted by JamieCameron on Sat, 08/26/2017 - 11:59

Do you get that error when enabling or disabling logrotate?

Submitted by Kintaro on Sun, 08/27/2017 - 09:14

yes:

sudo /usr/sbin/virtualmin disable-feature --domain domain.com --logrotate
sudo /usr/sbin/virtualmin enable-feature --domain domain.com --logrotate

Submitted by JamieCameron on Tue, 08/29/2017 - 00:31

I mean, during which of those two commands do you get the error message?

Submitted by JamieCameron on Tue, 08/29/2017 - 21:54

Were these domains perhaps originally created using Apache as the webserver?

Submitted by Kintaro on Thu, 08/31/2017 - 09:37

Yes, it could be possible. What can I do to fix that?

Submitted by andreychek on Fri, 09/01/2017 - 10:58

I talked to Jamie about this one... unfortunately, one of the issues here is that we don't actually support switching to Nginx once Apache has been in use.

Doing so can cause some problems as you've seen.

We only recommend using Nginx on new installations.

Now, Jamie offered it may be possible to get rid of some of the remaining Apache bits by using this command:

virtualmin disable-feature --all-domains --web --ssl                                                                                                                        

After doing that, then look into re-enabling logrotate.

If you're still seeing issues at that point, since you're using Virtualmin GPL and it's not a setup we support, you'd unfortunately need to use the Forums for additional help on this one.

Submitted by JamieCameron on Mon, 09/04/2017 - 12:43

Ok, that would explain it.

Submitted by JamieCameron on Mon, 09/04/2017 - 12:43

Status: Active » Fixed

Submitted by IssueBot on Mon, 09/18/2017 - 12:56

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.