Some of the virtual servers showed Webalizer reports missing several months of data. I attempted to to generate Webalizer reports and in some cases the reports would fail. I would get message
Running Webalizer to generate report from /var/log/virtualmin/caitech.com_access_log ..
.. Webalizer failed! See the output above for details.
This was not helpful. I researched running Webalizer from the command line and it worked well. Looking into the disparity I realized I was running the command line version as root, and checking the log files in /var/log/virtualmin I first noticed the group was set to apache on all of the files. On page Virtualmin > Logs and Reports > Webalizer Report I changed "Run Webalizer as user" to apache and was able to run a set of reports.
I then looked at the files in /var/log/virtualmin more closely and noticed a very odd collection of owner names. I found one or more instances of the following:
- Owner the name of the account in Virtualmin (as expected)
- Owner the name of an ftp user of the related account (user.account)
- Owner the name of a completely unrelated account (unrelatedaccount)
- Owner the name of a completely unrelated ftp user (unrelateduser.unrelatedaccount)
I'd like to get these fixed. I can chown all the files in the directory, but how did they get this way in the first place and will chown'ing them cause the next log entry to fail on a permissions problem?
Comments
Submitted by JamieCameron on Mon, 12/21/2009 - 12:19 Comment #1
That's odd - those files should all be owned by the domain user, with the group "apache".
For the domains whose files are owned by some un-related user, were these recently renamed, moved under a different owner, or restored from a backup?
Submitted by sfbob on Mon, 12/21/2009 - 23:17 Comment #2
None were recently (nor as I recall, ever) renamed, moved under a different owner, or restored from backup.
Submitted by JamieCameron on Mon, 12/21/2009 - 23:39 Comment #3
If you create a new test domain, does it get log files with the right permissions?
Submitted by sfbob on Tue, 12/22/2009 - 13:10 Comment #4
Created new domain virtualmintest.com, two files were created in /var/log/virtualmin/ ..._access_log and ..._error_log, both have correct ownership, owner virtualmintest, group apache
Submitted by JamieCameron on Tue, 12/22/2009 - 13:37 Comment #5
How old are the domains with incorrect ownership? It is possible that they were created some time back when a bug existed in Virtualmin that set it wrongly, but which has now been fixed..
Submitted by sfbob on Tue, 12/22/2009 - 15:06 Comment #6
The first one was created on 8 May 09, all but one other were created 9&10 May 2009. The last one was created in Aug 09 and it has correct permissions
Submitted by JamieCameron on Tue, 12/22/2009 - 15:50 Comment #7
You may be seeing the remnants of a bug that has been already fixed. Apache and logrotate won't change the ownership on log files, so if they were created months back the wrong ownership would still be there ..
Submitted by sfbob on Tue, 12/22/2009 - 15:56 Comment #8
So is there a fix other than backup / delete / recreate / restore?
Submitted by JamieCameron on Tue, 12/22/2009 - 16:02 Comment #9
Oh, to fix your existing files you could just chown them to the correct users. This could be done with a command like :
for dom in \`virtualmin list-domains --name-only\`; do
user=\`virtualmin list-domains --domain $dom | awk '{ print $2 }' | tail -1\`
chown $user /var/log/virtualmin/${dom}_*
done
Submitted by sfbob on Tue, 12/22/2009 - 19:09 Comment #10
I can do that to change ownership of the existing files.
However I am assuming that if changing ownership of existing files is all I do, when the next log rotate occurs a new file will be created with the existing incorrect ownership.
Is that assumption correct? If so, is there another way to fix the ownership or is the backup / delete / recreate / restore process the only way?
Submitted by JamieCameron on Tue, 12/22/2009 - 19:15 Comment #11
The next log rotation should keep the new correct owership, as logrotate re-creates the files will the current permissions and owner.
Submitted by megamurmulis on Wed, 10/03/2018 - 12:21 Comment #12
This line will output a table with potentially trimmed username:
user=`virtualmin list-domains --domain $dom | awk '{ print $2 }' | tail -1`
Should instead use a
--user-only
param:user=`virtualmin list-domains --domain $dom --user-only`
It appears on an NGINX server all files in
/var/log/virtualmin
are owned by www-data:www-data meaning that Webalizer doesn't generate it's stats. Manually changing permissions on the log files fixes the problem, but as mentioned by @JamieCameron when the log files are re-generated they have the wrong permissions again. Is there a permanent fix for this issue?Check Webmin/System/Log File Rotation > Edit Log File > Re-create log file after rotation? and set mode manually.
Does it help?
Submitted by markkuit on Thu, 02/18/2021 - 09:04 Comment #15
I spent some time investigating on this as this has always impacted every virtualmin-nginx environment I've dealt with. Looking at the code, it would look like it is intended behavior, probably by mistake. Am I wrong? Shouldn't this be fixed by checking the log path like
set_apache_log_permissions
does?/usr/share/webmin/virtualmin-nginx/virtual_feature.pl
/usr/share/webmin/virtual-server/feature-web.pl
Submitted by JamieCameron on Thu, 02/18/2021 - 13:06 Comment #16
Yes .. we will include this patch in the next release : https://github.com/virtualmin/virtualmin-nginx/commit/8e789bdcd5072d3daa...
Submitted by markkuit on Thu, 03/18/2021 - 11:50 Comment #17
It looks like Virtualmin 6.15 includes the fixed code from that commit, but the issue is still occuring. nginx logs were just set to www-data. again after rotation, although "Re-create log file after rotation" is set as "Default (yes, with old permissions)".
Mentioned commit above refers to Virtualmin Nginx module which is only going to be released.