A few Answer Gang biographical notes

Greetings from Heather Stern

Hello, everyone, and welcome once more to the world of the Linux Gazette Answer Gang.

The peeve of the month having been Non-Linux questions for a few too many weeks in a row, The Answer Gang has a new address. Tell your friends:

linux-questions-only

...at ssc.com is now the correct place to mail your questions, and your cool Linux answers. It's our hope this will stop us from getting anything further about pants stains, U.S. history, etc. Cross platform matters with Linux involved are still fine, of course.

For some statistics... there were over 31 answer threads, 25 tips (some were mini threads) and over 600 messages incoming - and that's after I deleted the spam that always leaks through. 200 more messages than last month. I'm pleased to see that the Gang is up to the task.

Now at this point I bow humbly and beg your forgiveness, that, being a working consultant with more clients than usual keeping me busy, I wasn't able to get all of these HTML formatted for you this time. In theory I can put a few as One Big Column but the quality is worse and we drive the search engines crazy enough already. I can definitely assure you that next month's Answer Gang will have tons of juioy answers.

Meanwhile I hope I can mollify you with some of the Linux tools that have been useful or relevant to me during my overload this month.

Mail configuration has been a big ticket item here at Starshine. You may or may not be aware that by the time we go to press, the MAPS Realtime Blackhole List is now a paid service. That means folks who have been depending on the RBL and its companion, the Dialup List, have to pay for the hard work of the MAPS team... and their bandwidth. You can find other sources of blacklisting information, or start enforcing your own policies ... but I would like to make sure and spread the news that they aren't going exclusively to big moneybags - file for hobbyist, non-profit or small site usage and you don't have to pay as much. Maybe nothing. But you do have to let them know if you want to use it, now.

Mail Abuse Prevention System:

http://www.mail-abuse.org/

My fellow sysadmins had been seeing this coming for a long time. Many actually prefer to know what sort of things are being blocked or not, anyway. Censorship after all, is the flip side of the same coin. Choosing what's junk TO YOU is one thing, junking stuff you actually need is entirely another. If others depend on you then you have to be much more careful. Plaintext SMTP isn't terribly secure but it's THEIR mail, unless you have some sort of contract with them about it.

So, I've been performing "Sherriff's work" for at least one client for a long while now anyway - just tweaking the filter defenses so that the kind of spam which gets in, stays out next time. There's a fairly new project on Sourceforge called Razor, which aims for anti-spam by signatures, the same way that antivirus scanners check for trojans and so on. I haven't had time to look into it, but I think they're on the right track.

Razor:

http://razor.sourceforge.net/

Procmail (my favorite local delivery agent) has this great scoring mechanism; it can help, or it can drive you crazy (depending on whether you grok their little regex language - I like it fine). I definitely recommend taking a look at "junkfilter" package of recipes for it even if you are planning to roll your own. The best part is that it is not just one big recipe - it's a bunch of them, so you can choose which parts to apply.

Do make sure you have at least version 3.21 of procmail though. It's actually gotten some improvement this month.

Procmail:

http://www.procmail.org/

Junkfilter:

http://junkfilter.zer0.org/

Folks who hate this stuff can try Sendmail's milters, Exim's filtering language, or possibly, do it all at the mail clients after the mail has been delivered to people.

Whether your filters are mail-client, local-delivery, or MTA based, making them sanity check that things are coming really to you, and from addresses that really exist, can have a dramatic improvement. The cost is processing power and often, a certain amount of network bandwidth, but if you're really getting hammered, it's probably worth it. Besides if my 386 can deal with just plain mail your PentiumIII-700 can actually do some work for a living and probably not even notice, until your ethernet card starts complaining. More on that 386 in a bit...

I've got a client who just switched from University of Washington's IMAP daemon over to Courier. The Courier MTA is just terrible (we tried, but ended up thoroughly debugging a sendmail setup instead, and the system is MUCH happier). But the IMAP daemon itself is so much better it's hard to believe. He's convinced that it is more than the switch to maildirs that makes it so incredibly fast. He does get an awful lot of mail, so I suspect Maildirs is what made the difference noticeable. We may never know for sure.

Courier-IMAP:

http://www.inter7.com/courierimap/

The world of DNS is getting more complicated every month, and slower. This has been clearly brought to light for me by two things - my client at last taking over his own destiny rather than hosting through an ISP, and my own mail server here at Starshine.

It used to be that there was only one choice for DNS, so ubiquitous it's called "the internet name daemon" - BIND, of course. And I'm very pleased to see that its new design seems to be holding up. Still it has the entire kitchen sink in it, and that makes it very complicated for small sites, even though there are a multitude of programs out there to help the weary sysadmin.

A bunch of folks - including some among the Gang - really enjoy djbdns, but you have to buy into DJ Bernstein's philosophy about some things in order to be comfortable with it. Its default policies are also a bit heavy handed about reaching for the root servers, which are, of course, overloaded. Still it's very popular and you can bet the mailing list folks will help you with it.

djbdns:

http://cr.yp.to/djbdns.html

However, his stuff (especially his idea of configuration files and "plain english" in his docs) gives me indigestion, so I kept looking. There are so many caching-only nameservers I can't count them all. It's a shame that freshmeat's DNS category doesn't have sub categories for dynamic-dns, authoritative, and caching only, because that sure would make it easier to find the right one for the job.

However, I did find this pleasant little gem called MaraDNS. It was designed first to be authoritative only, uses a custom string library, and is trying to be extra careful about the parts of the DNS spec it implements. It was also easy to set up; zone files are very readable. It looks like the latest dev version allows caching too... though whether that's a creeping-feature is a good question.

MaraDNS:

http://www.maradns.org/

For years I've been pretty proud that we can run our little domain on a 386. (Ok, we are cheating, that's not the web server.) But I could just kick myself for forgetting to put a DNS cache on it directly. So the poor thing has been struggling with the evil internet's timeouts lately and bravely plugging on... occasionally sending me "sorry boss, I couldn't figure out where to send it" kind of notes. (No, it's not qmail. I'm translating to English from RFC822-ese.)

So I look at the resolv.conf chain. No local cache. What was I thinking? (or maybe: What? Was I thinking? Obviously not.)

I tried pdnsd, because I liked the idea of a permanent cache... much more like having squid between you and the web, than just having a little memory buffer for an hour or two.

However, the binary packages didn't work. I wasn't going to compile it locally at the 386. I'll get to reading its source maybe, but if anyone has successful experiences with it, I'd enjoy seeing your article in the Gazette someday soon. I don't think I've tried very hard yet, but I had hoped it would be easier.

Meanwhile I had no time left and Debian made it a snap to have bind in cache only mode. Resolutions during mail seem to be much happier now.

pdnsd:

http://home.t-online.de/home/Moestl/

There are also more mailing list managers out there than plants in my garden. I've got a big project for a different client where the "GUI front end" is being dumbed down for the real end users, and I get to cook up a curses front end in front of the real features, for the staff to use. It's very customized to their environment. I do hope they like it.

If you're working on a mailing list project, I beg, I plead, try and have something in between the traditional thrashing through pools of text files, and the gosh-nobody-wants-security-these-days web based administration. That way I can take less time to make the big bucks, and folks are a little bit happier with Linux.

However, if you have in mind to do anything of the sort on your own, and you prefer to work with shell scripts, I recommend Dialog. Make sure you get a recent version though. There are a gazillion minor revisions and brain damaged variants like whiptail. Debian seemed to have the newest and most complete amongst the distros I have lying around, so I ended up grafting its version into another distro. But, I finally tripped across a website for it that appears to be up to date. Use the "home" link to read of its muddied past.

Dialog:

http://www.AdvancedResearch.org/dialog/left-frame.html

Lastly, Debian potato for Sparc isn't nearly as hard as I thought it was going to be, but configuring all those pesky services on a completely fresh box, that's the same pain every time. It wouldn't be, if every client had the same network plans, but - you know it - they don't!

I also had no ready Sparc disc 1, but a pressing need to get it, and my link is not exactly the world's speediest.

Debian's pseudo image kit is a very strange and cool thing. It's a bit clunky to get going - you need to fetch some text files to get it started, and tell it what files are actually in the disc you're going to put together. But, once you've fed it that, it creates this "dummy" image which has its own padding where the directory structures will go, amd the files go in between. If some of them don't make it, oh well. But you can get them from anywhere on the mirror system ... much closer to home, usually, Leave the darn thing growing a pseudo image overnight, then come back the next day and run rsync against an archive site that allows rsync access to its official Debian CDs. Instead of a nail-biting 650 MB download, 3 to 20 MB or so of bitflips and file changes If you either can't handle 650 MB at a time anyway, or like the idea of the heavy hit on your bandwidth allocation just being that last clump of changes, it's a very good thing.

All it needs now is to be even smarter, and programmatically be able to fetch newer copies of the packages, then compose a real directory structure that correctly describes the files. If someone could do that, you'd only have to loopback mount the pseudoCD and re-generate Packages files, to have a current- instead of an Official disc, including all those security fixes we need to chase down otherwise. Making it bootable might be more tricky, but I'd even take a non-bootable one so I can give clients a mini-mirror site just by handing them a CD.

Debian CD images information site:

http://cdimage.debian.org/

So, I hope some of you find this useful. I'm sure I'll see a number of you, and possibly some other members of the Answer Gang, at LinuxWorldExpo.

'Til next time -- Heather Stern, The Answer Gang's Editor Gal

This page edited and maintained by the Editors of Linux Gazette Copyright © 2001
Published in issue 69 of Linux Gazette August 2001

HTML script maintained by Heather Stern of Starshine Technical Services, http://www.starshine.org/

A few Answer Gang biographical notes