Log File Rotation: Permission Denied

[chrismcb]

Hi,

I'm having nightly emails at 00:00 regarding magic spam trying to rotate its log files:

Code: Select all

mv: cannot move `/var/log/magicspam/mslog' to `/var/log/magicspam/mslog.1': Permission denied

I have manually moved them around, but the permissions are set as:

Code: Select all

# ls -la
total 9560
drwxr-xr-x  2 magicspam magicspam    4096 Dec  4 11:08 .
drwxr-xr-x 23 root      root         4096 Dec  4 06:12 ..
-rw-r--r--  1 magicspam magicspam     500 Nov 30 23:59 .counter.dat.11
-rw-r--r--  1 magicspam magicspam     500 Dec  4 11:12 .counter.dat.12
-rw-r--r--  1 magicspam magicspam    3515 Dec  4 11:12 mslog
-rw-r--r--  1 magicspam magicspam 4570201 Dec  4 11:07 mslog.1
-rw-r--r--  1 magicspam magicspam 5166520 Dec  1 09:34 mslog.2

The email alert is coming from:

Code: Select all

Cron <qmaild@xxxxxx> /usr/share/magicspam/bin/rotate_logs /var/log/magicspam/mslog

I have not altered any cron tasks.

Should this task be running as qmaild? Is there anything else i should be looking at?



Thanks

[magicspam]

Hello Chris,

Did you recently change MTA backends on your Plesk Backend to/from Postfix / Qmail ? What is the active MTA you are running now?

It should be noted that for the QMail MTA backend, you will need to ensure that the contents of /var/log/magicspam (including the directory itself) should have the ownership:

qmaild:qmail

Whereas the Postfix MTA will require the ownership:

magicspam:magicspam

[chrismcb]

Sorry, forogot to return here to check for replies - I assumed I'd get an email alerting me (any chance you can enable this feature please?).

I did have to change from Postfix to Qmail back to Postfix to fix something in Plesk, however all permissions are set correctly.

I currently use Postfix and /var/log/magicspam has the ownership magicspam:magicspam as does all of its contents.


It is able to write to the logs, just not rotate them.


Anything else I should check?

[magicspam]

Would you be able to check the file:

/etc/cron.d/magicspam-update

and check the user that the job /usr/share/magicspam/bin/rotate_logs is set to run as? If it is set to 'qmaild' then changing that to 'magicspam' should resolve this issue. We have raised this topic to our packaging team as well to ensure that the rotation cron is updated properly in the future.

Thanks!

[chrismcb]

Thanks.

Both files you asked me to check were set as root:root.

I've set them both to magicspam:magicspam now and will let you know tomorrow once it's had time to run through.

[chrismcb]

Out of curiosity, should all files in /usr/share/magicspam/bin be ownd by magicspam:magicspam?

All of mine are currently root:root.

[chrismcb]

Totally misread that, sorry...

Checked contents of /etc/cron.d/magicspam-update and the user was set to qmaild.

I've now set it to magicspam.

[magicspam]

It sounds like you have the problem licked, and our development team has confirmed that the package updates will now ensure the settings for cases where MTA compatibility packages are swapped out.

To answer your question regarding the files in /usr/share/magicspam , root:root ownership is normal. It is just the configuration files primarily located in /etc/magicspam and the log files in /var/log/magicspam that will have different 'special' ownership based on the backend MTA integration.

[chrismcb]

Thanks - I can confirm it worked as expected overnight.

I am, though, having one last error show up in logs - probably related:

Code: Select all

magicspam[15072]: Failed to fetch entire file [37] from http://mirror1.bms.linuxmagic.com/bms_updates/ 

[magicspam]

Hello Chris,

This would appear to be a case of the IP Reputation list updates failing to retrieve the entirety of a download. This may be related to network timeout, DNS errors, or any other of a number of network related items.

Can you confirm that there are files in /var/cache/bms as well as the time stamps associated? (ls -al /var/cache/bms)