Monthly Archives: June 2012

Discretion is a Corporate Bad Word

Mike Dunford of “The Questionable Authority” blog relates an on-going negative experience with United Airlines. His wife is in the US military and has 15 days of leave to meet with Mike. The 15 days began when her flight arrived from Afghanistan in the USA. However, her connecting flight on United Airlines was cancelled due to fires and weather conditions that disrupted flights on the eastern seaboard. United told her that the earliest that they could book a flight for her was over 24 hours later. When you have 15 days for family leave, over a day spent waiting in a Chicago air terminal is not an insignificant hiccup.

Here’s where things got more interesting, or infuriating. Mike started looking for flights himself, and he found seats for sale on earlier flights from where she is at to where he is at. On United Airlines. He passed along the exact seat specifications to his wife, who consulted with the agents where she is at, and was told that the agents do not have access that would allow them to assign those seats without payment.

Apparently, corporations have figured out that their bottom lines are improved if the will of the soulless bean counters in corporate can be imposed without the moderating influence of the compassion of local functionaries who actually get charged with dealing with the end customer. To that end, the information technology (IT) departments get assigned to create systems that restrict the actions that the customer service agents or anyone in that entire chain of command can actually do. This certainly appears to explain the Dunfords’ poor handling by United Airlines.

Diane and I have our own data point on this phenomenon. We had some credit card debt accrued back when MBNA was a going concern. MBNA was bought out by Bank of America (BoA). Let’s say for brevity’s sake that our further experiences on that account were not pleasant. Earlier this year, we finally had the opportunity to pay off the account early. An electronic payment was set up and sent late one day. The next day, Diane tried to login to retrieve the payment records from the online system. She could not even login; the system said that there was no such account. Over the course of an acrimonious hour-and-a-half phone session with BoA, we learned a few things. Because the previous year BoA had “offered” an annual fee to go with the account that had never had one, we declined. They said that the account would be closed when the debt was settled on the account. According to BoA’s representatives, that meant when our balance payment arrived, the account was closed, and with it went our access to the online system. We explained that our only access to the records of our payments was via the online system, they said that there was nothing they could do about that. Oh, and by the way, because of the timing of our payment, there was a further finance charge that was billed to the account. How were we supposed to know about and pay such a charge if we couldn’t actually get to see our account balance? The BoA reps had no good answer on that. Could the BoA people send us our records in electronic format, just like we used to get when we had access to our account on the online system? No, they had no means of getting to a closed account themselves. I asked them what happens when law enforcement comes by with a warrant and requests the records of a closed account. They weren’t sure, they said, but in any case it wasn’t something that they could do anything about.

Now, on any scale of evil, BoA is certainly going to be found to be headquartered on a lower circle of Hell than United Airlines. But the same impetus and mechanism of corporate skin-flinting can be seen in play in both. Perfectly personable customer service representatives are forced into frustrating the end customer in order to uphold corporate policy. The effect of frustrated customers is assumed to either be negligible or to be outweighed by the savings the corporation achieves by denying customers whatever might be sought. The only way that this will change is if we frustrated consumers can figure out how to change that economic assessment. We need to identify the corporations that remove discretionary power from their customer service people and give our custom to corporations who leave discretion to their customer service agents. This is not a simple task, and that’s what those soulless bean counters are relying upon.

FreeBSD: Good-bye, md5crypt

The author of “md5crypt” considers it no longer safe for use in password encryption. This affects various *BSD systems, including FreeBSD, since md5crypt was long the default encryption applied to passwords in the system. Now, though, md5crypt is susceptible to brute-force attacks using GPU hardware that makes breaking an 8-character password something that can be done in a couple of days. Some recent security failures around the internet are now attributed to breaking of md5crypt password systems.

To find out if your *BSD system needs to be changed, do the following:

grep passwd_format /etc/login.conf

If the line returned by that includes “md5”, you have a problem. (If it says “des”, you’ve had a big problem for a long time.)

If you have a problem, do the following:

su vi /etc/login.conf

Change “md5” to one of the newer encryption methods, like SHA (sha256 or sha512) or Blowfish (blf).


cap_mkdb /etc/login.conf


Then change at least the root password and the password for everyone in “wheel” group. New passwords and changed passwords will be stored with the new default encryption. You can verify this by looking at the password hashes in /etc/master.passwd.

Not Everything is Easy in the Land of Raspberry Pi

I had the chance to work with my Raspberry Pi some more late last night and this morning. Quite a lot of stuff works, given that the board design is essentially at a state of “ready for the software developers to do their thing”. But some things are not quite there, or behave oddly.

My first boot-up that I talked about was on a bench without networking. That turns out to be significant. When I tried to run my RasPi with the full load of peripherals in the USB hub and also have the wired Ethernet on, I got a lot of “kevent 4 may have been dropped” error messages and no network connection. The canonical answer on the RasPi forum is that this is a power supply issue, where marginal power to the board means there isn’t enough to properly run the Ethernet circuitry. Some respondents have noted that their circumstances don’t fit into that neatly. I suspect that I may be joining them, but I have some more experimentation to do before saying so categorically. My get-it-working solution so far is to run the RasPi off a dedicated power supply and have all the peripherals on a powered hub. This isn’t ideal for something I hope to deploy remotely. I need to figure out really reliable, comes-up-on-power-on every time configurations.

I spent entirely too much time dealing with something that I should have caught early. The RasPi is a UK invention, and its default settings are convenient for people in the UK. I have a firewall here, and I set my RasPi to enable SSHD so I could login over the net. I logged in from an Ubuntu box and changed the “pi” user password to something approaching a strong password, you know, one with odd case, numbers, and symbols. That’s all to the good, but then I rebooted and ran into the network interface being offline. Fine, I thought, I’ll login directly. But I couldn’t, because no matter what I did, I could not generate one of the symbols in the new password from the directly-connected keyboard, not even with alt-codes. Stripping the RasPi down to just power and network allowed it to boot and establish the network interface, and I could login once again from a remote computer. I changed the password to avoid the bad symbol and worked on localization. The involves “dpkg-reconfigure” applied with three different targets, the keyboard, the locale, and the timezone.

I’ve been able to install a batch of additional software. I installed Cmake and libncurses5, then tried building Avida on the RasPi. The Avida build doesn’t get far. tcmalloc apparently is known to have build issues on ARMv6, plus multiple classes got an “out of virtual memory” error. That still holds with the boot switched to the 224MB main memory setting. But python-scipy and python-gps installed without issues. I even installed VLC to check if the final piece of a media center was anywhere close to done. While the VLC and its dependencies went on without complaint, plugging in a USB DVD drive and pointing VLC at it did not go much of anywhere. There was no continuous playback, and if I changed the media pointer, it would display a single frame. I think that the color rendition was off, but I had plugged in a movie that I hadn’t watched yet, so it is just possible that the cinematographer thought a strange palette would be a good thing.

I tried out my USB GPS dongle. I installed “gpsd-clients” and ran cgps, which reported … absolutely nothing. That was disappointing. I plugged the GPS into my Ubuntu box, and cgps happily displayed a fix and chatter from the dongle. I went back to the RasPi, stopped gpsd, then used gpsmon. That displayed a fix and messages from the dongle. So I’m not sure why gpsd on the RasPi is doing things differently than on the Ubuntu box.

For those pulling up “Geany” to do some Python scripting, you’ll need to change the preferences so that the terminal of choice is not “xterm”, but rather “lxterminal” (this is for Debian Squeeze).

That’s it for now. I’m expecting to have to repeat this process whenever a new version of the operating system is released, so a set of notes on what gets done seems in order.

Notes on RasPi

Adding nameservers:
sudo nano /etc/resolv.conf

sudo dpkg-reconfigure keyboard-configuration
sudo dpkg-reconfigure locales
sudo dpkg-reconfigure tzdata

Additional python modules:
sudo apt-get install python-scipy
sudo apt-get install python-gps

WiFi dongle —————————————–

Add to /etc/apt/sources.list:
deb squeeze non-free

sudo aptitude update
sudo aptitude install firmware-atheros

cd /lib/firmware
sudo wget
sudo wget