zmtrainsa broken after upgrade to v 4.0

[neilmc]

Originally Posted by pepijn

To verify, I symlinked /opt/zimbra/conf/spamassassin to /etc/mail/spamassassin and reran zmtrainsa for a user who badly needs to train spam. Lo and behold it worked and processed his entire Junk folder.

...........snip...........

Hopefully others can report their findings.

pepijn.

Thanks pepijn, that seemed to fix it for us. (no more message about the site rules directory being missing).

[lightman]

Originally Posted by pepijn

To verify, I symlinked /opt/zimbra/conf/spamassassin to /etc/mail/spamassassin and reran zmtrainsa for a user who badly needs to train spam. Lo and behold it worked and processed his entire Junk folder.

Hopefully others can report their findings.

pepijn.

Creating the symlink also worked for me as well. My server is now processing 2200+ messages on one of my accounts. Thank you for mucking around in the configs and noticing that.

Phoenix - this seems straight forward, but is there a chance we are messing anything up? I assume that some subsequent version of Zimbra would just have a modified config if it turns out this is the answer.

[KevinH]

Anyone file a bug on this?

[pepijn]

I haven't as of yet, mostly because I'm not sure whether:

1. I am just providing a workaround for something that is configured by Zimbra someplace else, and this config is missing and was not being recreated during a previous upgrade
2. There should be a symlink in place at the two locations mentioned in the amavisd script and they somehow did not get recreated during a previous upgrade

I'd gladly file a bug if it is deemed to be one.

pepijn.

[dijichi2]

So a quick check of the amavisd script at /opt/zimbra/amavisd/sbin/amavisd seemed to suggest that by default all rules are looked for at /etc/mail/spamassassin and /usr/local/share/spamassassin:

Code:
# DEF_RULES_DIR => '/usr/local/share/spamassassin',
# LOCAL_RULES_DIR => '/etc/mail/spamassassin',

the # means the line is commented out, although if there is no other override that indicates the default value. however, zimbra amavis uses /opt/zimbra/conf/amavisd.conf as the config file which is created from /opt/zimbra/conf/amavisd.conf.in each invocation. the sa rules dir is specified by $sa_site_rules_file - what does this say in yours?

[pepijn]

Originally Posted by dijichi2

the # means the line is commented out, although if there is no other override that indicates the default value. however, zimbra amavis uses /opt/zimbra/conf/amavisd.conf as the config file which is created from /opt/zimbra/conf/amavisd.conf.in each invocation. the sa rules dir is specified by $sa_site_rules_file - what does this say in yours?

Right, I know it's commented out and as you note it typically indicates a default setting. This is why I am thinking that I'm just providing a workaround for something that should be coming from a Zimbra config file like /opt/zimbra/conf/amavisd.conf. Mine contains the following (logical looking) settings:

$sa_rules_file = '/opt/zimbra/conf/salocal.cf';
$sa_site_rules_file = '/opt/zimbra/conf/spamassassin';
$sa_userprefs_file = '/opt/zimbra/conf/sauser.cf';

Looks like these settings are not making it through to zmtrainsa when it runs.

pepijn.

[tyco]

hi

i have the same here on my box running debian sarge with 2.6.x kernel

Learned from 0 message(s) (1 message(s) examined).
ERROR: the Bayes learn function returned an error, please re-run with -D for more information
fetchmail: MDA returned nonzero status 25
 not flushed
reading message user@mydomain.com@localhost.localdomain:46 of 1901 (566 header octets)  (759 body octets) .config: could not find site rules directory
bayes: cannot open bayes databases /opt/zimbra/amavisd/.spamassassin/bayes_* R/O: tie failed: 
bayes: cannot open bayes databases /opt/zimbra/amavisd/.spamassassin/bayes_* R/W: tie failed: File exists

zimbra what is the proper solution?

thanx

[SeanG]

Filed this in bugzilla as http://bugzilla.zimbra.com/show_bug.cgi?id=11425