My latest quixotic quest, to get the Pine email program working on my experimental Solaris laptop, has had its intended effect, which was to force me to learn unexpected lessons about the Solaris environment and whatever else happened to pop up in the path to enlightenment. I find that solving each new challenge leads me down new and interesting paths. None of this would be possible without Internet research: maybe I should say that Google is my new best friend, now and forever.
As I wrote on July 7 (egad, have I been fooling around with this for 3 weeks?), I was having a mysterious problem connecting Pine to the North American Sun email server. From the the message, "Server disables LOGIN, no recognized SASL authenticator," it was evidently a security problem, but what? I started checking out obscure mailing lists, and asking around, to no avail. Finally, finally, I realized that more than one mailing list entry I'd already read held the answer -- I just hadn't believed it: the Pine binary that I was using had not been compiled to use the SSL and TLS security protocols, and the Sun email server required them. Sure enough, when I read through the Pine Help facility on my installation, there was actually a nifty little page that told me whether that particulary binary had been compiled to make use of the security protocols, and it had not been. Aha! Clearly, this is one of the pitfalls of not compiling your own binaries, but I'm not at that level of enlightenment yet. I had gotten the Pine 4.64 binary from the wonderful sunfreeware.com, the number one site for free software packages for Solaris, and my guess is that they compiled it without security because the majority of downloaders probably don't have to access an encrypted server like Sun's.
Where to get another binary that had been compiled for SSL and TLS? Fortunately, a kind commenter pointed me to blastwave.org, another treasure trove of Solaris binaries. It's a community-driven site, with hundreds of contributors, and it's filled with helpful articles. And yep, it has a Pine binary, maintained by none other than Sun's own Eric Boutilier. I thought I was home free.
However, any time you're dealing with software, it ain't over until it's over. Lurking ahead of me was a landmine of diabolical subtlety.
Blastwave.org is more complex to use than sunfreeware.com. You have to download a program called pkg-get in order to download any of the hundreds of Solaris binaries they offer. And pkg-get is about the only program you download from Blastwave itself: you get the rest from one of 40 or so mirrors that are in operation around the world. Ibiblio.org is the default mirror, but the Blastwave site warns you that it is slow, and urges you to instead use a mirror that is close to you, so I obediently checked the mirror list for a server near me. The closest one was at the University of Southern California, just a few miles away. Excellent!
In order to tell pkg-get which mirror to use, you have to edit a little file called pkg-get.conf. My vi skills are still rudimentary, so I approached this task with some trepidation. Then I caught a break, or so I thought. Examining the file, I saw that all the 50 or so lines were commented out with the # sign, except for one that said "url=http://www.ibiblio.org/pub/packages/solaris/csw/unstable". This was preceded by a comment that said it was the default mirror. Then came a comment that said the secondary default site was none other than USC, followed by this line:
This was too easy! All I had to do was remove the # from the USC line, and add one to the front of the Ibiblio line. Even so, between vi's weird modes and my fat fingers, this took a while. But I got it done, saved the file, and told pkg-get to go get me a Pine binary!
Nothing happened. Oh, there was an error message: "URL http://mirrors.usc.edu/pub/blastwave/unstable not found." What the @#$%!? How could this be? I typed the URL into my browser and went directly to the USC mirror site with no problem. What could be wrong? I was stumped.
This condition persisted for a couple of days. I tried various remedies, none of which worked, and concocted wild theories, like maybe I was supposed to do something with the commented-out firewall lines in pkg-get.conf. I consulted various mailing lists. But mostly I just stared glumly at pkg-get.conf, hoping for inspiration.
Finally -- finally!-- I saw the problem. It's hard to see in the lines above, but it's there: an unwanted space after the = sign in the USC line. The Ibiblio line doesn't have a space. What's maddening about this is that the bad URL is actually repeated in the error message, but without the = sign you just don't see it. I wondered if I had inadvertently introduced the offending space myself, but I checked another copy of the original pkg-get.conf, and there it was.
I removed the space, and voila! Pine downloaded from the mirror site, along with all the packages it depends on, another cool feature of Blastwave. Eagerly, I fired it up and checked Help to see if this version had been compiled with SSL and TLS support. Hurray! It had been!
I entered the Sun server's address into the Pine configuration file, saved, restarted Pine, and there was my Sun mailbox! Hee-hee!
Actually, it took me two tries. The first time, Pine helpfully explained in great deal that, for my own good, it couldn't let me into the Sun server, because the Sun server has a self-signed security certitificate, which I couldn't match. This could expose me to a "man-in-the middle" attack, which I already knew from one of the interesting byways I had wandered down during the weeks I was trying to get Pine going. That's what I mean when I say I have been forcing myself to learn unexpected lessons. Pine advised me that I could get around this by using the novalidate-cert option, which I had also already read about, and thus knew was a legitimate option. Once I did that, my Inbox opened up. One of my next steps will be to actually retrieve and install the Sun security certificate, but for now I am content with my working Pine instance, and the lessons I have learned.