Logrotate can't access roundcube/phpmyadmin logs

Arieh

Arieh

Verified User
Joined
May 27, 2008
Messages
1,308
Location
The Netherlands
I saw this from a root mail which couldn't be delivered:

Code: 
/etc/cron.daily/logrotate:
error: failed to rename /var/www/html/roundcube/logs/errors to /var/www/html/roundcube/logs/errors.1: Permission denied
error: failed to rename /var/www/html/phpMyAdmin/log/auth.log to /var/www/html/phpMyAdmin/log/auth.log.1: Permission denied
run-parts: /etc/cron.daily/logrotate exited with return code 1

If I remember correctly there were recently some changes to the access of /var/www/html ?
 
Shouldn't matter if cron.daily runs logroate as root. Does it?

Jeff
 
Same problem this morning on one of our servers with the phpMyAdmin log:

Code: 
/etc/cron.daily/logrotate:
error: failed to rename /var/www/html/phpMyAdmin/log/auth.log to /var/www/html/phpMyAdmin/log/auth.log.1: Permission denied
run-parts: /etc/cron.daily/logrotate exited with return code 1
 
What does your setup file show:
Code: 
cat /etc/logrotate.d/webapps
I believe we were toying with adding "su apache webapps" after missingok.

If that is set, what are the permission on the logs?
Code: 
ls -la /var/www/html/phpMyAdmin/log/*
John
 
I just checked some things, /var/www/html/phpMyAdmin/log/auth.log contains log entries starting Feb 22, is that normal?

cat /etc/logrotate.d/webapps
/var/www/html/roundcube/logs/errors /var/www/html/squirrelmail/data/squirrelmail_access_log /var/www/html/phpMyAdmin/log/auth.log {
missingok
su apache webapps
}
Click to expand...
ls -la /var/www/html/phpMyAdmin/log/*
-rw-r--r-- 1 webapps webapps 3051394 Feb 27 03:21 /var/www/html/phpMyAdmin/log/auth.log
Click to expand...
 
What about the log directory? That's probably what the issue is:
Code: 
[COLOR=#333333]ls -lad /var/www/html/phpMyAdmin/log[/COLOR]
just need to sort out how picky the "su" part of logrotate is.
 
Can you try editing:
Code: 
/etc/logrotate.d/webapps
and change
Code: 
su apache webapps
to be
Code: 
su webapps webapps
and let us know if the errors go away.
If that works, we'll likely need to dynamically change the /etc/logrotate.d/webapps based on the current apache/php settings.

John
 
I had done the modification and waited a day for the cron to run; now the log entries start today (march 1). So I guess this fixed it. Something I don't understand is that I only had the cron error mail only once, but it didn't rotate the logs for many days.
 
Ok thanks. I'll look at having CB2 do a regex based on the apache/php modes.

As for not getting errors, logrotate only rotates a log if it meets the criteria.. so if it's not old enough, or not large enough, it might not need to be rotated.

John
 
Where are those settings? my auth.log is now 6.1M and still starting from march 1. I guess that's good?
 
logrotate settings are in /etc/logrotate.conf and /etc/logrotate.d/*

to test the settings run

Code: 
logrotate -d /etc/logrotate.conf

to see errors you may run

Code: 
logrotate -d /etc/logrotate.conf 2>&1 | grep error --color

I've got these:

Code: 
reading config info for /var/www/html/roundcube/logs/errors /var/www/html/squirrelmail/data/squirrelmail_access_log /var/www/html/phpMyAdmin/log/auth.log
error: webapps:3 error verifying log file path /var/www/html/roundcube/logs: No such file or directory
error: found error in file webapps, skipping

In my case it would mean I have no logs at all.


p.s. to force logrotate to do its jobs, run this:

Code: 
logrotate -f /etc/logrotate.conf
 
FYI, I forgot to push the SVN last night. The CB2.0 changes are now on files1.
Code: 
[TABLE="width: 1664"]
[TR]
[TD]        WL=/etc/logrotate.d/webapps[/TD]
[/TR]
[TR]
[TD][/TD]
[/TR]
[TR]
[TD="bgcolor: #F8E4CC"]        if [ -s ${WL} ]; then[/TD]
[/TR]
[TR]
[TD="bgcolor: #F8E4CC"]                return;[/TD]
[/TR]
[TR]
[TD="bgcolor: #DDFFDD"]        if [ ! -s ${WL} ]; then[/TD]
[/TR]
[TR]
[TD="bgcolor: #DDFFDD"]                getFile webapps.logrotate webapps_logrotate[/TD]
[/TR]
[TR]
[TD="bgcolor: #DDFFDD"][/TD]
[/TR]
[TR]
[TD="bgcolor: #DDFFDD"]                CWL=${CWD}/webapps.logrotate[/TD]
[/TR]
[TR]
[TD="bgcolor: #DDFFDD"]                if [ ! -s ${CWL} ]; then[/TD]
[/TR]
[TR]
[TD="bgcolor: #DDFFDD"]                        echo "Download of $CWL failed";[/TD]
[/TR]
[TR]
[TD="bgcolor: #DDFFDD"]                        return;[/TD]
[/TR]
[TR]
[TD="bgcolor: #DDFFDD"]                fi[/TD]
[/TR]
[TR]
[TD="bgcolor: #DDFFDD"][/TD]
[/TR]
[TR]
[TD="bgcolor: #DDFFDD"]                cp -f ${CWL} ${WL}[/TD]
[/TR]
[TR]
[TD="bgcolor: #DDFFDD"]                chmod 644 ${WL}[/TD]
[/TR]
[TR]
[TD]        fi[/TD]
[/TR]
[TR]
[TD][/TD]
[/TR]
[TR]
[TD="bgcolor: #F8E4CC"]        getFile webapps.logrotate webapps_logrotate[/TD]
[/TR]
[TR]
[TD="bgcolor: #F8E4CC"][/TD]
[/TR]
[TR]
[TD="bgcolor: #F8E4CC"]        CWL=${CWD}/webapps.logrotate[/TD]
[/TR]
[TR]
[TD="bgcolor: #F8E4CC"]        if [ ! -s ${CWL} ]; then[/TD]
[/TR]
[TR]
[TD="bgcolor: #F8E4CC"]                echo "Download of $CWL failed";[/TD]
[/TR]
[TR]
[TD="bgcolor: #F8E4CC"]                return;[/TD]
[/TR]
[TR]
[TD="bgcolor: #DDFFDD"]        AW_COUNT=`grep -c 'su apache webapps' ${WL}`[/TD]
[/TR]
[TR]
[TD="bgcolor: #DDFFDD"]        if [ "${AW_COUNT}" -gt 0 ]; then[/TD]
[/TR]
[TR]
[TD="bgcolor: #DDFFDD"]                perl -pi -e 's/su apache webapps/su webapps webapps/' ${WL}[/TD]
[/TR]
[TR]
[TD]        fi[/TD]
[/TR]
[TR]
[TD="bgcolor: #F8E4CC"][/TD]
[/TR]
[TR]
[TD="bgcolor: #F8E4CC"]        cp -f ${CWL} ${WL}[/TD]
[/TR]
[TR]
[TD="bgcolor: #F8E4CC"]        chmod 644 ${WL}[/TD]
[/TR]
[TR]
[TD="bgcolor: #F8E4CC"][/TD]
[/TR]
[TR]
[TD="bgcolor: #DDFFDD"][/TD]
[/TR]
[TR]
[TD]        if [ "${PHP1_MODE_OPT}" = "mod_php" ] && [ "${MOD_RUID2_OPT}" = "no" ]; then[/TD]
[/TR]
[TR]
[TD]                #if we have a newer version of logrotate, set the su value.[/TD]
[/TR]
[TR]
[TD]                LR_V=`logrotate_ver`[/TD]
[/TR]
[TR]
[TD]                if [ "`version_cmp ${LR_V} 3.8.0 'logrotate version check'`" -ge 0 ]; then[/TD]
[/TR]
[TR]
[TD]                        perl -pi -e 's/#su /su /' ${WL}[/TD]
[/TR]
[TR]
[TD="bgcolor: #F8E4CC"]                fi[/TD]
[/TR]
[TR]
[TD="bgcolor: #DDFFDD"]                fi[/TD]
[/TR]
[TR]
[TD="bgcolor: #DDFFDD"][/TD]
[/TR]
[TR]
[TD="bgcolor: #DDFFDD"]                perl -pi -e 's/su webapps webapps/su apache apache/' ${WL}[/TD]
[/TR]
[TR]
[TD]        fi[/TD]
[/TR]
[TR]
[TD]}[/TD]
[/TR]
[/TABLE]

So now any call to one of
Code: 
./build squirrelmail
./build phpmyadmin
./build roundcube
will check the /etc/logrotate.d/webapps file. The "su" value should end up showing either webapps webapps, or apache apache.

It might need more tweaking, as it only uncomments "#su" to "su" for the mod_ruid2=no + mod_php... so we'll see if the "su" is going to be needed for the webapps webapps method.
eg: if you have
Code: 
    #su webapps webapps
do you get rotation errors?

John
 
I just put the # in place, but I also updated PMA so the log is reset. I also wondered if it's good that if you update the logs are gone.

I did the logrotate test call which didn't give any error, but I don't know if it would actually would try to rotate it would? I rather not force the logrotate, I don't know if it would mess up the normal rotations.
 
Just got this error this morning after doing a:

./build update
./build squirrelmail

yesterday on a Debian 7 server:

Code: 
/etc/cron.daily/logrotate:
error: skipping "/var/www/html/squirrelmail/data/squirrelmail_access_log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
 
You must log in or register to reply here.
Back
Top