I need to go to the co-location facility to fix eskimo.com shell server.  I will be late in the office because it is a long drive during rush hour.

     The Fedora 21 shell server, fedora.eskimo.com, is back online with a new slightly larger virtual disk.

     It will be rebooted later assuming I am successful at building a working 4.0 kernel.

     Usenet News is back up.

     I am taking the Fedora shell server down for a short while to enlarge the virtual disk.  This should take about one half hour.  If you need relatively modern Redhat based servers, either centos7 or scientific7 should make a reasonable substitute while this upgrade is in progress.

     I haven’t received any complaints about this but when I fired up Pan this afternoon it wasn’t working.  I checked our status with NewsGuy and our account there did not automatically renew on the 12th like it is supposed to.  They took payment manually and are restoring our service and looking into why automatic payment failed.  So for any of you who missed news but didn’t tell us it was down, it should be back shortly.

      No likes?  Stuck at 93?  You didn’t like the Spring make-over?  Can’t remain winter forever you know!

     The Bayesian filtering database was corrupted causing the SpamAssassin failures.  In order to resolve this I had to initialize the database so all spam / ham training history is gone.

     Please help us train the filters again by bouncing spam to: spamtrap@eskimo.com

     It is also necessary for the filters to have examples of non-spam in order to be able to differentiate between the two.

     Please help us train the filters by sending examples of non-spam e-mail to: hamtrap@eskimo.com

     Again: spam goes to spamtrap@eskimo.com and non-spam to hamtrap@eskimo.com.

     Thank you for your patience.

Still problems with SpamAssassin. Disk space increased, doesn’t appear to be a resource issue:

Plenty of disk space:

     # df
     Filesystem 1K-blocks Used Available Use% Mounted on
     /dev/vda3 27016320 5755716 19907756 23% /

Plenty of memory:

     # free
     total used free shared buffers cached
     Mem: 4053548 1504976 2548572 6136 46200 595264
     -/+ buffers/cache: 863512 3190036
     Swap: 2097148 0 2097148

Plenty of CPU:

     # uptime
     14:45:14 up 3 min, 2 users, load average: 0.63, 0.62, 0.28

I am back to researching this.  Any suggestions most appreciated.

     I am still getting messages that are getting past spamassassin.  SpamAssassin is called from system procmail rules. Procmail provides an error that says program failed with an exit code of -25.  A Google search reveals that many people are experiencing these and suggests a possible resource shortage.

     These machines are short on disk space at this point so I am going to enlarge the virtual disks to see if this resolves the issue.

     If anyone else has any information about this error, please e-mail nanook@eskimo.com.

     Mx1 is restored with spamassassin.  It appears an update failed to complete properly, probably because I had left a test-updates repository enabled and it grabbed an update that was broken.

     This has been fixed, the server is restored to service and now spamassassin is operational on both mx1 and mx2.

     I am in the process of replacing these servers because spammers have adapted to old versions and can often sneak by.  Working on new servers based upon the latest and greatest so it will at least slow them down until they adapt again.