What is Mail::SpamAssassin::DnsResolver for? 

From the perldoc DESCRIPTION section of DnsResolver.pm, it says :" This is a DNS resolution engine for SpamAssassin, implemented in order to reduce file descriptor usage by Net::DNS and avoid a response collision bug in that module.", what this description really refered to is bugs:

http://issues.apache.org/SpamAssassin/s ... gi?id=3997
http://issues.apache.org/SpamAssassin/s ... gi?id=4260

bug 3997 is really a long discussion, comment #73 finally sort out what the cause is

------quote-----
"....The problem is that there is nothing in the RFCs to prevent reuse of a UDP
source port once there is no active listener on that port. UDP connections are
not persistent, so there is nothing that IO::Socket can do to ensure that a
reply to a UDP port is not a response to some old packet that was sent from that
port.


This is a known problem in the DNS world, with a solution built in to the DNS
protocol. The DNS query packet has a header with an identifier field, which is
an arbitrary 16 bit number set by the sender. The nameserver copies it to the
identifier field of the header of the response packet. see http://www.tcpipguide.com/free/t_DNSMes ... #Table_169

This is above the IO::Socket layer, so the fix can't be there. Net::DNS can't
use the ID field to ensure that a bgread matches up with a bgsend unless it
cached every socket returned by bgsend in order to save the ID in a hash with
it. I don't think that is practical.

That leaves SpamAssassin as the right level for the fix.

---------quote-------------

[ add comment ] permalink ( 3 / 97 )
Perl Module installation from CPAN 

Today, when I am testing the latest SpamAssassin 3.1.4 release, I get a note "optional module missing: IO::Socket::SSL". while I run the command "perl -MIO::Socket::SSL -e 'print $IO::Socket::SSL::VERSION", it gives me version 0.96 and I do have this module. coincidently, I found out a SpamAssassin commiter running into a problem when he do make test, which is related to IO::Socket::SSL module too. here is quote from his email:

----
"Ok, it turned out to be IO::Socket::SSL version 0.993

The change log for version 0.994, dated yesterday, says:

"v0.994
- hide DEBUG statements and remove test to load Debug.pm
because packets like Spamassisin cannot cope with it
(at least the OpenBSD port)"

Unfortunately, for now 0.993 is the current one on CPAN.

perl -MCPAN -e'shell'

cpan> install S/SU/SULLR/IO-Socket-SSL-0.994.tar.gz

did the job and make test then worked fine.
"
-------

I learned that I could install the missing CPAN module directly from the author's archive directory from CPAN. for example, IO::Socket::SSL depends on Net::SSLeay module, I could not install it from CPAN neither, but I could search this module from search.cpan.org and get to know the author is Florian Ragwitz and his cpan archive directory is "F/FL/FLORA" search.cpan.org/, then I can

cpan> install F/FL/FLORA/Net_SSLeay.pm-1.30.tar.gz

nice eh?
[ add comment ] permalink ( 3 / 116 )
ClamAV upgrade on Fedora 

Upgrade ClamAV is plain easy on Fedora, backup ClamAV config file and downloaded the latest ClamAV source. ./configure --prefix=/usr/local, make, make install will do the installation in /usr/local. make sure the old config file consistent with new config file. be careful with the clamav unix socket file (/var/run/clamav/clamd.sock) and check it is right in the amavisd /etc/amavisd.conf. Remember to restart clamd, freshclam and amavisd
[ add comment ] permalink ( 3.1 / 71 )
Logrotate on Debian 

I have been running apache webserver on an lower end old PC (PII450/192RAM/10GHD) for two years now and it never gave me problem.
But today I found out my apache log file never got rotated since I upgrade apache to apache2 with openssl and WebDav support. After couple of minutes of poking around, the log file got rotated, here is what I did, change /etc/logrotate.d/apache2
/var/log/apache2/*.log {
weekly
missingok
rotate 52
compress
delaycompress
notifempty
create 640 root adm
sharedscripts
postrotate
if [ -f /var/run/apache2.pid ]; then
/etc/init.d/apache2 restart > /dev/null
fi
endscript
}

to:

/usr/local/apache2/logs/*_log {
weekly
missingok
rotate 52
compress
delaycompress
notifempty
create 640 www-data www-data
sharedscripts
postrotate
if [ -f /usr/local/apache2/logs/httpd.pid ]; then
/usr/local/apache2/bin/apachectl restart > /dev/null
fi
endscript
}

and manually run logrotate /etc/logrotate.conf. logrotate is called from /etc/cron.daily, so the apache log will be rotated weekly.
[ add comment ] permalink ( 2.9 / 83 )
PHP Fatal error: Call to undefined function: mysql_pconnect() 

Today, while I am trying to access the webcalendar from browser, nothing shows up, no error message. why would it suddenly stop functioning? my first instinct is to look for some clue from the log /var/log/httpd/ssl_error_log, ha, I see a PHP Fatal error: "Call to undefined function: mysql_pconnect() in /usr/share/webcalendar/includes/php-dbi.php on line 97" , looks like php failed to connect to mysql database. why it would suddenly failed, since upraded mysql to newer version in the previous upgrade, I haven't done any change to php setup, and it worked fine since the upgrade.
Something happened after the upgrade and I didn't notice? what about restarting mysql? I restarted mysql, no difference. how about restarting httpd, restarted httpd,and I noticed an error "PHP Warning: Unknown(): Unable to load dynamic library '/usr/lib/php4/mysql.so' - libmysqlclient.so.10: cannot open shared object file: No such file or directory in Unknown on line 0", seems Apache does not load php mysql library correctly, ah, I remembered that since the previous mysql upgrade, I symbolic linked the /usr/lib/mysql to my new mysql library /usr/local/mysql/lib/mysql. I deleted the symbolic link, changed it back to my old mysql library and restarted httpd, the error message is gone and the webcalendar worked again. I think while I upgraded the mysql, and linked the new mysql library to /usr/lib/mysql, the apache were still calling the old mysql library from memory, once apache restarted itself when finishing the weekly log rotation, it begins to call the new mysql library and failed to load PHP mysql library. the problem solved, but question still remains: why apache could not load PHP mysql library by calling the new mysql library from /usr/local/mysql/lib/mysql? do I have to recompile PHP with the new mysql library? probably
[ add comment ] permalink ( 3 / 73 )

Back Next