1 (edited by annonman 2014-07-13 10:25:14)

Topic: Inaccessible permissions after scripts run - SA-update / AWstats

============ Required information ====
- iRedMail version: 0.8.7 (updated)
- Store mail accounts in which backend (LDAP):
- Linux/BSD distribution name and version: Centos 6.5
- Related log if you're reporting an issue:
====

Hello,

iRedMail  has been running GREAT since I went live with it.

However, a few irritations exist.

Each time the SA-update script and awstats scripts run, they change the permissions on the respective files to:

-rw-r-----   1 root   root

AWstats is affects  /var/lib/awstats/.

SA-update affects /var/lib/spamassassin.

Changing these permissions back has short lived success as the next run changes them back.


This results in either errors:

AWstats:

Error: Couldn't open file "/var/lib/awstats/awstats072014.smtp.txt" for read: Permission denied 

or-

in the case of Spamassassin, the rules are not read, therefore no filtering takes place.

I can stop the scripts, but that really defeats having the systems.

Any thoughts?

----

Spider Email Archiver: On-Premises, lightweight email archiving software developed by iRedMail team. Supports Amazon S3 compatible storage and custom branding.

2 (edited by annonman 2014-07-14 03:47:09)

Re: Inaccessible permissions after scripts run - SA-update / AWstats

More information:

/var/log/sa-update.log is blank.

Running

sa-update -D seems to work:


Jul 13 15:45:44.512 [4867] dbg: logger: adding facilities: all
Jul 13 15:45:44.512 [4867] dbg: logger: logging level is DBG
Jul 13 15:45:44.512 [4867] dbg: generic: SpamAssassin version 3.3.1
Jul 13 15:45:44.512 [4867] dbg: generic: Perl 5.010001, PREFIX=/usr, DEF_RULES_DIR=/usr/share/spamassassin, LOCAL_RULES_DIR=/etc/mail/spamassassin, LOCAL_STATE_DIR=/var/lib/spamassassin
Jul 13 15:45:44.512 [4867] dbg: config: timing enabled
Jul 13 15:45:44.513 [4867] dbg: config: score set 0 chosen.
Jul 13 15:45:44.517 [4867] dbg: dns: is Net::DNS::Resolver available? yes
Jul 13 15:45:44.517 [4867] dbg: dns: Net::DNS version: 0.65
Jul 13 15:45:44.517 [4867] dbg: generic: sa-update version svn917659
Jul 13 15:45:44.517 [4867] dbg: generic: using update directory: /var/lib/spamassassin/3.003001
Jul 13 15:45:44.614 [4867] dbg: diag: perl platform: 5.010001 linux
Jul 13 15:45:44.614 [4867] dbg: diag: [...] module installed: Digest::SHA1, version 2.12
Jul 13 15:45:44.614 [4867] dbg: diag: [...] module installed: HTML::Parser, version 3.64
Jul 13 15:45:44.614 [4867] dbg: diag: [...] module installed: Net::DNS, version 0.65
Jul 13 15:45:44.614 [4867] dbg: diag: [...] module installed: NetAddr::IP, version 4.027
Jul 13 15:45:44.614 [4867] dbg: diag: [...] module installed: Time::HiRes, version 1.9721
Jul 13 15:45:44.615 [4867] dbg: diag: [...] module installed: Archive::Tar, version 1.58
Jul 13 15:45:44.615 [4867] dbg: diag: [...] module installed: IO::Zlib, version 1.09
Jul 13 15:45:44.615 [4867] dbg: diag: [...] module installed: Digest::SHA1, version 2.12
Jul 13 15:45:44.615 [4867] dbg: diag: [...] module installed: MIME::Base64, version 3.08
Jul 13 15:45:44.615 [4867] dbg: diag: [...] module installed: DB_File, version 1.82
Jul 13 15:45:44.615 [4867] dbg: diag: [...] module installed: Net::SMTP, version 2.31
Jul 13 15:45:44.615 [4867] dbg: diag: [...] module installed: Mail::SPF, version v2.008
Jul 13 15:45:44.615 [4867] dbg: diag: [...] module not installed: IP::Country::Fast ('require' failed)
Jul 13 15:45:44.615 [4867] dbg: diag: [...] module installed: Razor2::Client::Agent, version 2.84
Jul 13 15:45:44.615 [4867] dbg: diag: [...] module not installed: Net::Ident ('require' failed)
Jul 13 15:45:44.615 [4867] dbg: diag: [...] module installed: IO::Socket::INET6, version 2.56
Jul 13 15:45:44.615 [4867] dbg: diag: [...] module installed: IO::Socket::SSL, version 1.31
Jul 13 15:45:44.615 [4867] dbg: diag: [...] module installed: Compress::Zlib, version 2.021
Jul 13 15:45:44.615 [4867] dbg: diag: [...] module installed: Mail::DKIM, version 0.37
Jul 13 15:45:44.615 [4867] dbg: diag: [...] module installed: DBI, version 1.609
Jul 13 15:45:44.615 [4867] dbg: diag: [...] module installed: Getopt::Long, version 2.38
Jul 13 15:45:44.615 [4867] dbg: diag: [...] module installed: LWP::UserAgent, version 5.833
Jul 13 15:45:44.615 [4867] dbg: diag: [...] module installed: HTTP::Date, version 5.831
Jul 13 15:45:44.615 [4867] dbg: diag: [...] module installed: Encode::Detect, version 1.01
Jul 13 15:45:44.615 [4867] dbg: gpg: Searching for 'gpg'
Jul 13 15:45:44.615 [4867] dbg: util: current PATH is: /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
Jul 13 15:45:44.616 [4867] dbg: util: executable for gpg was found at /usr/bin/gpg
Jul 13 15:45:44.616 [4867] dbg: gpg: found /usr/bin/gpg
Jul 13 15:45:44.616 [4867] dbg: gpg: release trusted key id list: 5E541DC959CB8BAC7C78DFDC4056A61A5244EC45 26C900A46DD40CD5AD24F6D7DEE01987265FA05B 0C2B1D7175B852C64B3CDC716C55397824F434CE
Jul 13 15:45:44.617 [4867] dbg: channel: attempting channel updates.spamassassin.org
Jul 13 15:45:44.617 [4867] dbg: channel: update directory /var/lib/spamassassin/3.003001/updates_spamassassin_org
Jul 13 15:45:44.617 [4867] dbg: channel: channel cf file /var/lib/spamassassin/3.003001/updates_spamassassin_org.cf
Jul 13 15:45:44.617 [4867] dbg: channel: channel pre file /var/lib/spamassassin/3.003001/updates_spamassassin_org.pre
Jul 13 15:45:44.617 [4867] dbg: channel: metadata version = 1609892
Jul 13 15:45:44.621 [4867] dbg: dns: 1.3.3.updates.spamassassin.org => 1609892, parsed as 1609892
Jul 13 15:45:44.621 [4867] dbg: channel: current version is 1609892, new version is 1609892, skipping channel
Jul 13 15:45:44.622 [4867] dbg: diag: updates complete, exiting with code 1

3

Re: Inaccessible permissions after scripts run - SA-update / AWstats

*) Did you execute sa-update as root user manually?
*) How did you update Awstats?

4

Re: Inaccessible permissions after scripts run - SA-update / AWstats

Hi Zhang,

*)The about output from sa-update -D was run as root manually.
Running manually does not seem to change any permissions on files.

*)Awstats has been run vi cron.

I am guessing the issues here are related to the cron jobs and called scripts.

From what I can see...

sa-update called by cron once a day ( /etc/cron.d):
10 4 * * * root /usr/share/spamassassin/sa-update.cron 2>&1 | tee -a /var/log/sa-update.log


------

Awstats is called by 2 cron jobs via root :(crontab -e)
1   */1   *   *   *   perl /usr/share/awstats/wwwroot/cgi-bin/awstats.pl -config=web -update >/dev/null
1   */1   *   *   *   perl /usr/share/awstats/wwwroot/cgi-bin/awstats.pl -config=smtp -update >/dev/null

and one other cron job hourly (/etc/cron.hourly):

#!/bin/bash
exec /usr/share/awstats/tools/awstats_updateall.pl now         -configdir="/etc/awstats"         -awstatsprog="/usr/share/awstats/wwwroot/cgi-bin/awstats.pl" >/dev/null
exit 0

5

Re: Inaccessible permissions after scripts run - SA-update / AWstats

annonman wrote:

in the case of Spamassassin, the rules are not read, therefore no filtering takes place.

How did you check no filtering takes place?

6 (edited by annonman 2014-07-14 23:34:51)

Re: Inaccessible permissions after scripts run - SA-update / AWstats

ZhangHuangbin wrote:
annonman wrote:

in the case of Spamassassin, the rules are not read, therefore no filtering takes place.

How did you check no filtering takes place?


1)I sent the GTUBE string in an email as a test.

2) INBOX flooded with spam.

3) All emails show score of 0.

7

Re: Inaccessible permissions after scripts run - SA-update / AWstats

I did a test on a local vm:

1) Updating SA rules with command defined in cron job "/usr/share/spamassassin/sa-update.cron", it works:

# pwd
/var/lib/spamassassin/3.003001

# ls -l
total 16
drwxr-xr-x 2 root root 4096 Jul 15 18:57 sought_rules_yerp_org
-rw-r--r-- 1 root root  123 Jul 15 18:57 sought_rules_yerp_org.cf
drwxr-xr-x 2 root root 4096 Jul 15 18:58 updates_spamassassin_org
-rw-r--r-- 1 root root 2695 Jul 15 18:58 updates_spamassassin_org.cf

# ls -l updates_spamassassin_org/
total 908
-rw-r--r-- 1 root root   8703 Jul 15 18:58 10_default_prefs.cf
-rw-r--r-- 1 root root   2452 Jul 15 18:58 10_hasbase.cf
-rw-r--r-- 1 root root   7612 Jul 15 18:58 20_advance_fee.cf
-rw-r--r-- 1 root root   9046 Jul 15 18:58 20_aux_tlds.cf
-rw-r--r-- 1 root root   7005 Jul 15 18:58 20_body_tests.cf
-rw-r--r-- 1 root root   1894 Jul 15 18:58 20_compensate.cf
-rw-r--r-- 1 root root   9779 Jul 15 18:58 20_dnsbl_tests.cf
-rw-r--r-- 1 root root  15055 Jul 15 18:58 20_drugs.cf
-rw-r--r-- 1 root root  11492 Jul 15 18:58 20_dynrdns.cf
-rw-r--r-- 1 root root   8517 Jul 15 18:58 20_fake_helo_tests.cf
-rw-r--r-- 1 root root   3017 Jul 15 18:58 20_freemail.cf
-rw-r--r-- 1 root root  42825 Jul 15 18:58 20_freemail_domains.cf
-rw-r--r-- 1 root root  26363 Jul 15 18:58 20_head_tests.cf
...

As you can see, all files are readable by every user.

Files updated by command "sa-update -D" (executed manually) are not readable by all users. So maybe you should stop updating with 'sa-update' manually.

8 (edited by annonman 2014-07-15 12:13:54)

Re: Inaccessible permissions after scripts run - SA-update / AWstats

When I try to run the cron command as root manually, it just hangs.  Something is not right, sa-update log file is blank as well.

However, when running the awstats command manually (all 3 of them), the perms get set correctly.

When cron runs the awstats, it's back to 640 perms.

9

Re: Inaccessible permissions after scripts run - SA-update / AWstats

annonman wrote:

When I try to run the cron command as root manually, it just hangs.

it's not hang, it sleeps for many seconds, that's why it looks like hang.

You can comment out line "sleep ..." in file /usr/share/spamassassin/sa-update.cron, then execute for testing. It's better to uncomment it after you finished testing.

10

Re: Inaccessible permissions after scripts run - SA-update / AWstats

ok..let me see try it.

11

Re: Inaccessible permissions after scripts run - SA-update / AWstats

After commenting out the sleep and running it did not change any of the permissions.

Cron seems to be the culprit here...

Any thoughts?

12

Re: Inaccessible permissions after scripts run - SA-update / AWstats

No idea.

13 (edited by annonman 2014-07-16 00:05:21)

Re: Inaccessible permissions after scripts run - SA-update / AWstats

I removed a line in /etc/sysconfig/init that set umask to 027 and restarted my server.

So far, it seems to have worked.