SPAM, Maintenance, & Migrations So meanwhile on the career ranch. It's been busy. I wouldn't say I've been doing a bunch of things I really love. I am however doing things that are beneficial, and greatly appreciated. It's nice to be needed, I just wish I could be doing some more coding. When I actually get to it, I am usually to tired to get my head into it, or I just never get to it period.

There was a rash of complaints about the amounts of SPAM coming into several clients. So off I go into the foray of fighting SPAM. There are lots of different ways to tackle SPAM, and let me say I end up using all of them. Good thing I get to test out spamassassin on my own mail server, and then propagate onto the fortress servers before we move onto the client servers. First things first, pump in the SBL lists directly into the kolab/templates/main.cf.template. Apparently the spamassassin module doesn't use them correctly. Besides that, I'd prefer to have them dumped by the mail server as opposed to processed by the mail scanner to find out they are bad.

For some clients not running spamassassin (yet), I ended up using postfix header_checks options to use a set of rules I created myself (with some help on the internet to dump certain bad things. It has apparently helped somewhat, and no one has complained in the weeks since I put that in place.

For those of us running spamassassin in Kolab, I really had to experiment and tweak things. First things first, amavis runs spamassassin on it's own, and has it's own configurations to control SPAM. This overrides the user_prefs file. Took me a bit to find that out, but it's all good. I am wondering why the amavis default level is 6.3, yet the spamassassin default is 5.0? I had to crunch that down ... normal I use a 3.0 for clients. There's just so much spam out there. I prefer to lower the level, and customize the rules for their system, and opposed to leave a higher level. I've had no complaints thus far.

The last thing I went on to do was search for some more intense SA rule sets. There are a few sites that offer rule sets for people, and you can even automate the update. I'm not worried about that. I found some really inventive rules by some people. I created an SVN module, and a script to install and check the syntax after installation. this makes my updates much easier. Plus it's easy for all the clients to benefit at the same time from my SPAM fighting efforts. Update and run the script, and you are good to go.

I've been dealing with the issue of client maintenance. We have some clients who are signed up for bi-weekly maintenance. What do we deliver for the reports. I wrote a step by step procedure (commands, expected output, comments) on what do do for maintenance. Performing the maintenance is not supposed to be my job. We're working on that as well. The colleague who was supposed to do that actual maintenance is pretty green. He's also new to linux, so I spent some time doing "type this ... now this" kinda help. He missed the mark on what needed to get done. I ended up re-doing the report myself.

When I realized I was redoing all this work, I decided it would be nice to automate this. the time invested in this would payoff huge in the end. I wrote an entire suite of scripts that can be run to gather system information needed for the maintenance report. This is configurable for each client, and all stored in SVN modules. Just check out the SVN module you need for the client, and run their scripts for each server. I spent quite a few hours writing the original scripts. So I decided to time myself on the second server for fortress. Start to finish, with a checkout, running, and debugging the scripts and config, committing, and creating the report from a template took all of 16 minutes. That's pretty awesome. We can now condense the maintenance reports for someone at the company all at once. That's really really awesome. I told Gregg about it, and he was super excited, as he should be because I just saved him a ton of hours, and money. Good on me. :D

I also spent last weekend mostly not sleeping, and installing and migrating the L&Y office onto a redundant Kolab system. I ended up running into a system problem, with the PHP modules, and realized that the apt-get repositories were #@$%!. Some mix up between 64/32 bit, not using universe. I decided it would be easier to just re-install correctly, than try to fix it. I was right, but it encroached upon my sleepy time. The next day Andy H and I started the transition of client workstations. From about 1-7 we finished the entire south office (~35 desktops). That's account setup, and mail exports. This still left 5 satellite offices. I said I'd go to south bend, get Rich to let me in, I haven't seen him in forever anyways. It's only 5 computers ... should be quick right?

I got there about 9 P.M. Was still in the office when Dan came in @ 8:30. Dans computer was slow as molasses is the Yukon, 10 MB network. Plus his computer was having memory issues, and I ended up getting a blue screen of death on windows 2000 reboot. Wow. Rich's network card died after I upgrade him to Office 2003. That office install took over 3 hours. We had some really really unhealthy computers. Jim's import took 7.5 hours for his 1 Gig of email. That's what you get for remote upload over a VPN I guess. Tara' computer I ended up doing manually because she had like 100+ folders all with special characters not allowed like slashes etc. It took forever running the round robin from PC to PC. I was slightly tired after the 30+ hours of work in 2 days. But they are up and running. End users bitch and complain of course because it is not the same as before ... what else is new.  ¶ 4:43:00 AM