Aaron Adams’s Lame-ass Blog

I spent some time this morning troubleshooting my television. It doesn’t matter how much time I actually spent trying to get it to work properly, if it’s one second it’s too much. I now add the television to my list of technologies that are getting worse, not better.

When I was a kid, I pushed the power button on the TV and turned a dial or punched in a number to select a channel and watched. There was nothing more to it, and it worked 99.99999% of the time. The only troubleshooting my parents ever had to do with a TV was, “It’s dead. We need a new one,” and, “Call the cable company because the cable’s out.” Likewise, for the first 2/3+ of my life I could pick up a phone and dial a number, and within a few seconds I was speaking clearly to the person on the other end.

Now I deal with a TV that has a thousand different connectors and options and yet doesn’t perform simple functional things that I, as a new user, discovered should be present in 15 seconds. I deal with a cable box that takes several minutes to boot, and with a remote that has a good 1.5 second delay for every action, where the TV we had 20 years ago was instant. And then I need to set all the settings on the cable box in coordination with all the settings on the TV to make sure I don’t end up with squashed faces and muffled audio.

I have a cell phone signal that’s full strength when I hold the phone one way, and completely gone when I move the phone 1/4 inch to the left. Signal strength depends on moisture in the atmosphere and whether there are leaves on the trees. 3/5 of my calls are eventually dropped, regardless of my location, and 1/3 of incoming calls never ring my phone to begin with but are sent straight to voicemail.

This is not progress. All the advantages brought to us by HDTV and cell phones are more than negated by the technical difficulties and the constant struggle to make them work properly. For all the alleged geniuses with degrees and certifications in Silicon Valley and elsewhere, why has it turned out to be so difficult to replicate the level of reliability these devices had 20 years ago? Maintaining things that work well in that same state should be their first priority.

Last night my friend Mike and I decided it was time to upgrade the Xserve that hosts this site from 10.4.10 to 10.5.0. We traveled downtown to the co-lo facility, and immediately discovered that we had been locked out. The card reader at the door did not respond to our swipes. We called someone from Time Warner to let us into the room, and he informed us that the card reader system had just been upgraded, so there may be some kinks.

We installed the Leopard upgrade, and when the server rebooted, it told us the serial number provided with the software was invalid. A trip to the Apple support discussion forums provided the answer. It’s a known bug. We entered the new serial number with Server Admin on another Mac, then rebooted the Xserve, and then re-entered the serial number again during the setup. Not a giant deal, but a tad annoying.

The server started and all of our settings had been migrated perfectly. All services were running that should be running. All OD users and their properties had been preserved. We tested to make sure web pages were being served. Everything seemed to be functioning properly, so we left, knowing that once the door closed behind us, we couldn’t get back in because TW had screwed up the card reader.

When we got back to Mike’s house, we discovered that nothing worked anymore, and we had no way to get back into the room because it was late and we doubted anyone from TW was going to be happy about helping us. Plus, our sites and personal e-mail hosted ont he Xserve aren’t that critical, so we left it down overnight.

This morning, the lady at TW informs us that she forgot to migrate our accounts from the old card server to the new one, and she apologizes and tells us it should be corrected within a few hours. Three hours later, Mike is able to get into the co-lo room.

The Xserve has kernel panicked. Somehow or another, both NICs had been assigned the same IP address (which wasn’t the case when the machine had been running Tiger) and that was enough to make the machine panic after a short but random amount of time. (I suspect there’s something more to it, but we wanted the server up ASAP so we didn’t go too deep.) Mike removed one NIC, assigned the correct IP to the internal NIC, and all was well again.

Until we noticed e-mail wasn’t being delivered. It turns out there’s a bug in Leopard server 10.5.0 where mail doesn’t get delivered to mailboxes defined by aliases in Workgroup Manager. And wouldn’t you know it, all the mailboxes on our server are WGM aliases. Luckily, this PDF at topicdesk.com explains how to implement Postfix aliases as a workaround until Apple fixes the problem. The error in the SMTP logs, by the way, for those of you who are curious, and for Google, was:

550-Mailbox unknown. Either there is no mailbox associated with this 550-name or you do not have authorization to see it.

So, after a TW screw-up and three Apple bugs, an upgrade and associated troubleshooting we should have had completed by the time we finished our pizza last night turned into roughly 24 hours downtime. I have truly wasted my life.

Take a good look at the following screen shot from Leopard’s Screen Sharing:

That’s how you make a new connection to another machine. Connection… New… - command-n.

See how simple that is? Now get coding.

At the suggestion of my friend Chris, who posted a comment to my most recent MacPorts complaint, I contacted the maintainer of the post, Mark D. After a few e-mails between each other discussing the issue, Mark instructed me to add the following two lines to the end of /opt/local/var/macports/sources/
rsync.macports.org/release/ports/net/ntop/Portfile :

build.env-append MACOSX_DEPLOYMENT_TARGET="10.3"
destroot.env-append MACOSX_DEPLOYMENT_TARGET="10.3"

I added those lines and ntop finally compiled correctly… but it still didn’t work. Something about a GDBM error, which I didn’t record. So I removed MacPorts, reinstalled it, re-ran the ntop install, and it failed this time compiling Perl 5.8. Just to be super duper sure, I re-ran the install one more time and it finally installed a working ntop and all dependencies, as if Perl had never been a problem. What a load of crap that I have to go to such trouble.

I do want to thank ntop port maintainer Mark D. for his help. In his e-mail, Mark stated that he had not tested a compile of ntop on a PowerPC system because he has an Intel Mac, and that the necessary changes will be added to MacPorts and available in a few hours.

The error, for those who don’t know, and the Google page crawler, was

ld: flag: -undefined dynamic_lookup can't be used with MACOSX_DEPLOYMENT_TARGET environment variable set to: 10.1

gnumake[2]: *** [libntop.la] Error 1
gnumake[1]: *** [all-recursive] Error 1
gnumake: *** [all] Error 2

The whole point of attempting to compile ntop to begin with is because I’d like to create a sort of network appliance that I can plug into customer networks, consisting of a Mac mini and ntop, that would monitor and record their traffic for a certain amount of time and assist with troubleshooting and other issues. I’ll likely keep plugging away with MacPorts and compile an mpkg with ntop and its dependencies as universal binaries. However, I can’t recommend using MacPorts to install software on any kind of production server - it’s just too flaky. What I would recommend is to have a second machine to create mkpg files containing dependencies, and compiling those as universal binaries for storage and installation elsewhere, as I stated that I will do.

Brand new, clean install of MacPorts 1.5 on a Tiger 10.4.10 server. The command line I used:

sudo port -v install ntop

Lots of bits and pieces configure and compile for about 30 minutes, and it all ends with this:

gcc -dynamiclib -undefined dynamic_lookup -o .libs/libntop-3.3.dylib .libs/address.o .libs/argv.o .libs/dataFormat.o .libs/fcUtils.o .libs/getopt.o .libs/getopt1.o .libs/globals-core.o .libs/hash.o .libs/iface.o .libs/initialize.o .libs/l7.o .libs/leaks.o .libs/ntop.o .libs/pbuf.o .libs/database.o .libs/plugin.o .libs/prefs.o .libs/protocols.o .libs/sessions.o .libs/term.o .libs/util.o .libs/utildl.o .libs/traffic.o .libs/vendor.o .libs/version.o .libs/ntop_darwin.o /opt/local/lib/libart_lgpl_2.dylib /opt/local/lib/libz.dylib /opt/local/lib/libpng12.dylib /opt/local/lib/libfreetype.dylib -L/opt/local/lib -L/usr/local/lib -lpthread -lc -lssl /opt/local/lib/librrd_th.dylib /opt/local/lib/libgdbm.dylib -L/usr/lib -lnetsnmp -lcrypto -lz -lm -lwrap -lpcap -install_name /opt/local/lib/libntop-3.3.dylib

gnumake[2]: *** [libntop.la] Error 1
gnumake[1]: *** [all-recursive] Error 1
gnumake: *** [all] Error 2

So I Google the error, read around a bit, and try this at the command line (per the suggestion of many sites):

export MACOSX_DEPLOYMENT_TARGET=10.4

It makes no difference. The compile still fails with the error:

MACOSX_DEPLOYMENT_TARGET environment variable set to: 10.1

As a non-developer, I have no real idea what this error means or how to correct it. As I’ve stated before, it was my understanding that MacPorts was intended to make software compilation like this simple for those of us who are non-developers.

This kind of problem eventually happens every damn time I use MacPorts (and previously, Fink). Clean installs. Simple compilation of a common app. Utter failure and no real way to fix it.

The other surprising part of all this is that I am completely unable to find any kind of installer package for ntop 3.3 Is there really no alternative to MacPorts out there for this kind of useful software? I’m extremely pissed because MacPorts simply doesn’t work, and hasn’t and I keep getting sucked back into it because it appears to be the only way to install some applications that are very useful.

MacPorts people, wake the hell up. Fix your software. This is completely unacceptable. Why should it be this hard and this frustrating for me to install software with your port system?

PS: I just checked my own site, and the last time MacPorts pissed me off, it was for the same reason: An environment variable that was set wrong which prevents the software from compiling. Do you not test? Do you not read feedback from your users? Do your users not provide feedback? How does this kind of error make it to a production product? My server is nothing special, with no odd software or configuration, developer tools properly installed, the first MacPorts ever installed on this machine, and it’s broken. Unacceptable.