Due to my recent bad luck with electricity, I was using my home server as a desktop all last week. As a result, I have some more notes to add about using FreeBSD as a Desktop machine, which I hope others may find useful.
Read on for more about Printing, Firefox and Thunderbird interoperability, mounting a USB mass storage device, CD burning with K3B, and Video playback.
So a week ago I had a rather nasty shock. I was watching a TV show that I was playing on my laptop, which was hooked up to my DVD Recorder via S-Video and composite audio cables. Nothing I hadn’t done a few dozen times before. The difference was: I realized that I had not plugged in the laptop’s power cord. When I proceeded to plug in the laptop — *poof* — sparks flew and smoke rolled out of the laptop from under the headphone jacks. It’s an Acer not a Dell so this was truly a surprise :)
After some minor panicing, I found that the laptop would still boot (thankfully) but the audio was dead. I presume the S-Video port was also dead, but I was not about to test it. Sadly, my DirecTivo was also fried (also connected to the DVD Recorder via S-Video) but the DVD recorder is just fine. The jolt also fried a segment of coax cable between the Tivo and the Satellite dish: Specifically it was the segment that goes from the inside of the house to the grounding block outside.
Read on for all of the gruesome details…
So as a resident of Indiana, today is my first day of Daylight Saving Time and I am not happy at all. In addition to having to reset all of the clocks, I also had to change the time zones on all of the computers — Easy enough on Windows, you can just change the time zone to Eastern. However, all my FreeBSD servers required a download and recompile of new time zone definitions. Not just that, but most programs that were started before the time zone switch will not pick up the change until they are restarted. In some cases, it’s safer to just reboot the whole server to make sure everything is running on the same clock. And I hate having to reboot servers.
The reasoning behind the FreeBSD time zone updates is explained in this link. The gist of it is that past file dates can be miscomputed if the time zone is simply switched to Eastern.
Many users of calendaring programs will be bitten by similar problems, causing appointments set before the change to exhibit all kinds of odd behavior.
Personally, I have not seen enough compelling evidence to show that the clock changing business actually saves any energy. It does, however, mess with people’s internal clocks and cause many traffic accidents. Most of the figures done showing that it saves energy seem to be from the 1970’s. I doubt the governer thought about the thousands of man-hours lost in actually changing the clocks, on computers and servers especially – but he sure was sympathetic about the possible loss of an hours worth of drinking at bars!
The only positive effect is that the Indiana legislature will now debate over things that actually matter, instead of over DST.
I’m sure that come Monday I will have to deal with quite a few calls from people who, rather than changing the time zone on their PC, have simply run the clock ahead an hour – only to find out that the clock resets when the Internet Time function resyncs.
A couple weeks ago, the SORBS spamtrap list picked up a few Hotmail and Gmail servers, and a Yahoo mailing list server. This lead to me getting complaints that legitimate mail was bouncing. I’m all for letting the mail get blocked, because it’s the only way that large companies like Google and Microsoft will be forced to fix problems. Unfortunately, the end users don’t see it this way. They think because Hotmail user A can’t get mail to our user B, it’s a problem with our system and we need to fix it. Ignoring the fact that thousands of other ISPs who use the same RBL are also blocking mail from those people. Long story short, I was forced to remove the spamtrap RBL (by using all of the separate SORBS RBLs instead of the composite list) — the mail started flowing again and the complaints stopped.
This is leading to conversations on the general merit of RBLs in general, and whether or not we should use them because it’s allowing someone else to control whether or not mail gets to our users. Of course the people raising these questions do not have to listen to the end user complaints. People want all their mail and no spam, which of course is impossible.
Currently, between several different RBLs, we reject about 130,000 messages per day (~80% of the total daily mail volume) at the MTA level. Should we turn them off, everybody would notice. There are no other spam filtering techniques that have done as much to reduce our spam overall as RBLs. Sure, we could throw a million content filters at it, but that takes a lot of horsepower to run, and probably would not be as effective. I put more stock in RBLs than I do in content filtering. The only legitimate alternative to using RBLs at the MTA level is using them in SpamAssassin where they are ranked with scores based on the RBL’s reliability and such. However, performing the RBL checks in SpamAssassin also introduces a lot more delays in message delivery (and of course, if someone sends an e-mail and the other person doesn’t have it in less than a minute people call and complain too!)
Life would be so much easier if there was a secure and spam-resistant alternative to SMTP, but that won’t be happening anytime soon.
So it’s been quite some time since I posted anything, mainly because I’ve been rather busy on a project at work. It’s a fairly complex system that we used Ruby on Rails for. I had never used Rails before (or Ruby for that matter!) but it was easy to pick up (I suppose having coded in a dozen languages or so at one time or another makes picking up new ones easier…) Rails really excels at taking care of the grunt work (db access/mapping especially) and lets you focus on what you’re trying to accomplish.
I did all of my coding using Eclipse, with Ruby Develpment Tools, Subclipse (for Subversion access), and most importantly the RadRails plugin. For the most part is was a good experience. There were a few times when renaming a file or performing miscellaneous actions that Eclipse locked up on me (at home and at work) but restarting Eclipse worked ok. The only feature missing that would have been nice is Rails debugging. It’s in the works in RadRails, but it’s a ways off.
More about Ruby on Rails can be found elsewhere.
I found the book Agile Web Development with Rails invaluable during the entire process. (Programming Ruby is another fine choice, too!)
A little update on the Spam I had been seeing recently.
After looking a little deeper, it must have been a single spammer using that tactic, and relaying the spam through a bunch of other hosts (likely compromized PCs, since many were cable modems). After a while, those particular faked Received: header styles were not showing up as often.
I’ve added a couple more RBLs and RHSBLs, updated SpamAssassin, and tweaked some default scores, and things seem to have gotten happier.
The number of rejections at the MTA level has held steady, but the overall volume has ebbed while the number of detections by SpamAssassin increased. Result: Less spam. For now.