I spent some time the other day wondering why:
It turned out that by default when you install named from FreeBSD's ports collection the named.conf contains this little bit of text:
// If named is being used only as a local resolver, this is a safe default.
// For named to be accessible to the network, comment this option, specify
// the proper IP address, or delete this option.
listen-on { 127.0.0.1; };
It took me most of a day before I realized that that was exactly my problem and all I had to do was comment out that line for everything to start working like I expected. I didn't couldn't find this idiotic mistake written about elsewhere on the web, so I'll leave this hear in the hope that it will help someone else.
tigeremailimapthunderbird
I just finished a journey through my e-mail configuration and while it was mostly frustrating, I thought others might find some parts of it of interest.
It all began innocently enough. I received my copy of MacOSX Tiger on April 29th. One of the first things I noticed after the upgrade was the new Mail application. The new UI is awful. I start to feel depressed by the colors in the new UI. (For folks who are interested in changing the UI, two programs I've heard about are Mail Fixer and Cage Fighter.
But, for me, even worse than the UI was the fact that Mail now refused to show me when I had new mail in my mailboxes. I mean what's the point of an e-mail program if you have to click on each mailbox to find out if there's a new message?
Before I continue, I should say a little bit more about my setup. I have a few Macs and a few PC's around the house. Since I never wanted to lock myself down to having to read e-mail at any specific machine, I long ago setup a machine (FreeBSD) to act as an IMAP server.
Rather than sort my email into mailboxes at the client, I sort my mail on the server using procmail. This makes sure that no matter what machine I'm using to read my email, I can have the same sort of sorting going on regardless of the platform and mail reader.
So here's where Mail has a problem. It's not just my INBOX that needs to be checked for new messages. New mail may get sorted into many different folders on the IMAP server. Sadly, and for reasons I cannot begin to fathom, Mail only checks the INBOX when it checks for new mail.
Now, this problem isn't new. It's existed on the Mac before. In face, I used to use an AppleScript I found on the net as a workaround. Unfortunately, with Tiger, this workaround no longer works. It doesn't force the Mail app to recalculate the number of unread messages in each mailbox.
I don't know why exactly, I was surprised by this. I guess, I just assumed that my configuration cannot be that uncommon and that surely someone at Apple would do the Right Thing (tm) and fix Mail so it worked properly with IMAP clients. Well, you know what happens when you assume.
After I noticed that Mail wasn't working the way I wanted it to, I managed to convince myself that I must be doing something wrong. So I thought I'd better check things out by making sure my IMAP server was up to date. I was running a copy of the UW-IMAP server from 2003. I installed the latest version from the FreeBSD ports collection which was the 2004a version. It's not quite the latest, but I didn't see anything in the UW-IMAP release notes about updating unread message count so I figured it would be safe.
Anyway, after getting the new server going, it didn't change Mail's behavior at all as I mentioned above. However, I did learn a little more about the UW-IMAP server in my travels. I came across this document about mailbox formats. It seems that by default the server is built to handle old-style UNIX mbox mail formats. I've always thought this was a great thing since the mail messages are stored in plain ASCII, but I have definitely been noticing that my larger mailboxes take longer to load in my mail programs.
After reading that document, it seemed that UW-IMAP was optimized more for their own mbx format. And, it turns out that the UW-IMAP distribution provides a handy little tool called mailutil which allows you copy your existing mailboxes into mbx format. For example, this command will copy the mailbox "foo" which is mbox format into a new "foo_mbx" folder in the mbx format:
mailutil copy '{localhost/novalidate-cert}Mailboxes/foo' '{localhost/novalidate-cert}#driver.mbx/Mailboxes/foo_mbx'
The novalidate-cert is necessary since I have a self-signed certificate on my IMAP server to do SSL connections. Without that option the command failed. I didn't do any benchmarks, but in my opinion, Mail seemed to be able to open the mailboxes much more quickly once they were converted to mbx format. Looks like someone else did do some benchmarks.
So, after spending all this time tinkering with the server, I found myself no better off than before I started. I was still stuck with the ugly new Mail 2 application which wouldn't tell me when I got new mail.
I thought about Thunderbird a few times and decided that even though it updated the unread count, I couldn't switch to it because I was addicted to being able to use Apple's Address Book.
But, wait...
I noticed that in the "General" tab of the preference panel of the Mail application there's a preference called "Default Mail Reader" You can specify any application you want and it will become the default application to handle mailto: URL's. Specifically, the following gets written into the com.apple.LaunchServices portion of the defaults database:
{LSHandlerRoleAll = "org.mozilla.thunderbird"; LSHandlerURLScheme = mailto; }
Now, I can go the Address Book, select a person's card and when I try to send mail to them, it open's in Thunderbird. It works well enough for now.
I ran into a big problem today on with my Windows XP machine. I was scanning something and OmniPage just went into a tailspin. It was eating 100% of the CPU and I couldn't get it to stop. It was hung. Normally, I would just get frustrated and reboot the machine, but I was actually doing something else in the background that I wanted to finish.
I thought, "No problem! I'll just bring up the Task Manager and kill it." Sounded good. But didn't work!
I read some more web pages and decided I should be able to do it from a command prompt. Learned about "tasklist" and "taskkill". Neither worked. Both aborted with some cryptic error about "server execution" or something that didn't make sense.
Then I found this and life was good. I don't even know what "ntsd" is. But it worked great to kill the unkillable OmniPage process.
I figure I won't remember this the next time I need it unless I write it somewhere.
Alan sent this to me today and I think it deserves its own space in the blogosphere.
I just spent a better part of yesterday and this morning trying to fix my Adobe Acrobat Reader, which out of the blue stopped working. I thought I would share what I learned in case you run into the same bug. A little while ago my Acrobat Reader stopped working on startup. I didn't install anything new, upgrade Reader, it just stopped working. It would just hang at the startup splash screen and eat up 100% of the CPU cycles doing nothing. It will sit there and never finish, you have to kill it with control-alt-del. I tried uninstalling, reinstalling, reverting to 5.0, cleaning the windows registry, removing all plug-ins, checked for viruses that might effect Reader, nothing worked. When I was about to throw the computer out the window, I did one more google search, got lucky and found this little gem! (Hooray for google, yet again)"As suggested, cleaning the "c:\documents and settings\yourusername\local settings\temp" directory helped tremendously. It appears Acrobat created 65,535 temporary files (0 KB each) named "Acr0000" through "AcrFFFF". I have a hunch that Acrobat uses a 16 bit counter for the temporary file names and that this counter overflows, which causes the application to hang."And that is exactly what happened to me. I'm guessing whoever wrote that code, just incremented the name by one and asked for the file, and the loop is conditioned on file not found. Which in this case will never happen, so the dumb program just sits there reading empty temp files forever. I removed those tmp files and everything works now. Apparantly this bug has been around and reported, but Adobe just couldn't be bothered to fix it. What a dumbass bug. Argh!
Hope this will save you time and a few grey hairs.
So in investigating my problem with mysterious spoofing packets, I learned/relearned some useful commands.
First "netstat -a -W" is good to see all the ports that are open. It also seems to give the same results if you're root and if you're not.
One problem I had with that output was that it doesn't relate the process to the socket. "lsof -i -n" on the other hand does just that. However, the output changes depending on whether or not your root. The info is much more complete when you're root.
Slashdot pointed me to "Open Source Desktop Technology Road Map" by Jim Gettys. It's a great overview of many of the technologies that make up an Open Source desktop solution.
With layer upon layer of libraries and processes, I can't help but wonder when we'll start considering many of these lower layers as the base for our computing platform rather than add-ons.