Jaharmi’s Irreality renewable hyperlinks with 0% transfat since 1999

The Mac turns 28 today. It has come a long way, and it’s amazing to think about how the original Macintosh compares to, say, a 27-inch LED-backlit aluminum-and-glass-clad LCD iMac of today. I think one could imagine the iMac being a successor to the original iMac, from its exterior design, through the software it runs, to the input devices used to interface with it.

But, will the Mac make it to thirty — and still be recognizable as a Macintosh? A lot can change in the next two years.

I had a repeat of a problem that I’ve probably had many times over the years. I wanted to write down the solution before I forgot it, because it had been long enough since the last time that I’d forgotten the fix.

Let’s set the stage: I wanted to SSH into a remote system. In my case, that remote system was a Mac OS Snow Leopard system. The client was also Mac OS X.

On that remote system, I had enabled sshd. This is done on Snow Leopard with System Preferences > Sharing > Remote Login. (In the Sharing System Preferences, you set up the users that are allowed to remote log in, either allowing all users or setting up an ACL that only allows specific users. If you set up the ACL, it should supercede whatever additional user/group login restrictions you’ve configured in /private/etc/sshd_config.)

Then, I tried to SSH from my client system. Instead of a successful login, I was told the following — before I was prompted for a password.

Scratching your head, you add verbosity to the SSH connection attempt.

I searched for other people having the same problem with “debug1: SSH2_MSG_KEXINIT sent,” because other people always have the same problem and some of them wrote about it and some of those solved it. Right?

Well, in this case, the other solutions I found were not helpful to my specific situation. But many people responding to pleas for help did mention the always-good advice to “check the server logs.” Which I could do, so I did.

In the secure.log, I found several groups of lines like this corresponding to the times I had tried to log in:

That reminded me of the common problem with SSH host keys on Radmind-managed computers. See, Mac OS X will try to create the host keys if they are missing, but not if they are zero-length. On Radmind-managed computers, it was trivially easy to get zero-length SSH host key files in /private/etc because the tendency was to manage them with negative transcripts. Files listed in negative transcripts would be created if they were missing, but they would be created as empty files (by design).

Empty SSH host key files will prevent you from logging into that system with SSH.

I checked the server and — sure enough — the host key files were zero length. I deleted them, then stopped and restarted Remote Login for good measure. This solved the problem, and I could log in from the client.

I was trying to install Dulwich on a Mac OS X Lion system this week and ran into difficulty. I kept getting installation failures that included a missing “python.h” and, eventually, llvm-gcc-4.2 failed to compile the module.

I found the situation frustrating, partly because I pretty much own the top search hits about how to install Dulwich and Hg-Git on Mac OS X Lion, thanks to some earlier article.

It turns out that I had reinstalled Lion about two weeks ago, and had not reinstalled Xcode 4. So, I updated to Xcode 4.2 and this completely eliminated my problem. Presumably, it would also work for you — and for future me, since I’m likely to repeat this — even if Lion hadn’t been reinstalled in between.

Things that didn’t work included but were not limited to:

• cursing under my breath
• stomping
• hand-waving
• complaining on Twitter
• the silent treatment
• waiting for 4, 12, and then 24 hours to see if it would fix itself
• installing the latest version of setuptools, v0.6c11, from an egg
• installing the current version of Distribute, new hotness or not
• any steps involving Linux distribution package managers like apt-get.

Hg-Git is the Mercurial extension to use if you want to connect to local or remote Git repositories. I exclusively use Mercurial and Hg-Git for all of my Github transactions, so I can personally vouch that it works.

Now that Hg-Git has been updated to better support Mercurial 1.9, let’s see if we can get an Hg toolchain working on Lion. Since I did that on Snow Leopard a few days ago, Hg-Git has made it into PyPI. The installation instructions this time are a bit more streamlined, because we can now use easy_install to get Hg-Git and its dependencies.

To get the toolchain set up, we’ll need Xcode. The Xcode suite includes tools we’ll need to make Python easy_install work, along with Subversion (a prerequisite for Hgsubversion, which I’ll talk about in a later article) and other useful tools.

The Xcode installation is a multi-step install process. Both current download methods — the developer download through connect.apple.com (if you have a paid Mac Developer Account) and the Mac App Store — give you an “Install Xcode” application. That application runs a second, real installer that you have to finish before you actually have the Xcode tools available in a ready-to-use state. This is very similar to the situation for Mac OS X Lion, so you may be developing a sense of familiarity with the situation.

To install Mercurial:

1. Download Mercurial 1.9.2 or later. The binary packages are standard Mac OS X packages; get the one for Lion.
2. Install Mercurial.

To add Hg-Git to Mercurial on Lion:

1. Download Xcode 4.1 or later if you don’t already have it. You can do this through connect.apple.com or via the Mac App Store.
2. Install Xcode if it is not already installed.
   • Open the developer disk image, run the installer inside it, and then run the “Install Xcode” application that was placed in /Applications.
   • Run the “Install Xcode” application that was placed in /Applications by the Mac App Store.
3. Open Terminal. Run the following command, which will install hg-git and its dependencies (including dulwich, of which you’ll want version 0.8.0 or later):
   
   $ sudo easy_install ‘hg-git>=0.3.1’
   Password:
   Searching for hg-git>=0.3.1
   Reading <a href="http://pypi.python.org/simple/hg-git/
   Reading" title="http://pypi.python.org/simple/hg-git/
   Reading">http://pypi.python.org/simple/hg-git/
   Reading</a> <a href="http://hg-git.github.com/
   Best" title="http://hg-git.github.com/
   Best">http://hg-git.github.com/
   Best</a> match: hg-git 0.3.1
   Downloading <a href="http://pypi.python.org/packages/source/h/hg-git/hg-git-0.3.1.tar.gz#md5=4b15867a07abb0be985177581ce64cee
   Processing" title="http://pypi.python.org/packages/source/h/hg-git/hg-git-0.3.1.tar.gz#md5=4b15867a07abb0be985177581ce64cee
   Processing">http://pypi.python.org/packages/source/h/hg-git/hg-git-0.3.1.tar.gz#md5=…</a> hg-git-0.3.1.tar.gz
   Running hg-git-0.3.1/setup.py -q bdist_egg —dist-dir /tmp/easy_install-_Uauza/hg-git-0.3.1/egg-dist-tmp-rERQMH
   zip_safe flag not set; analyzing archive contents…
   Adding hg-git 0.3.1 to easy-install.pth file
   
   Installed /Library/Python/2.7/site-packages/hg_git-0.3.1-py2.7.egg
   Processing dependencies for hg-git>=0.3.1
   Searching for dulwich>=0.8.0
   Reading <a href="http://pypi.python.org/simple/dulwich/
   Reading" title="http://pypi.python.org/simple/dulwich/
   Reading">http://pypi.python.org/simple/dulwich/
   Reading</a> <a href="http://samba.org/~jelmer/dulwich
   Reading" title="http://samba.org/~jelmer/dulwich
   Reading">http://samba.org/~jelmer/dulwich
   Reading</a> <a href="http://launchpad.net/dulwich
   Best" title="http://launchpad.net/dulwich
   Best">http://launchpad.net/dulwich
   Best</a> match: dulwich 0.8.0
   Downloading <a href="http://samba.org/~jelmer/dulwich/dulwich-0.8.0.tar.gz
   Processing" title="http://samba.org/~jelmer/dulwich/dulwich-0.8.0.tar.gz
   Processing">http://samba.org/~jelmer/dulwich/dulwich-0.8.0.tar.gz
   Processing</a> dulwich-0.8.0.tar.gz
   Running dulwich-0.8.0/setup.py -q bdist_egg —dist-dir /tmp/easy_install-bHRaTM/dulwich-0.8.0/egg-dist-tmp-MNy6RK
   dulwich/_objects.c: In function ‘py_parse_tree’:
   dulwich/_objects.c:101: warning: implicit conversion shortens 64-bit value into a 32-bit value
   dulwich/_objects.c: In function ‘cmp_tree_item’:
   dulwich/_objects.c:148: warning: implicit conversion shortens 64-bit value into a 32-bit value
   dulwich/_objects.c:152: warning: implicit conversion shortens 64-bit value into a 32-bit value
   dulwich/_objects.c: In function ‘py_sorted_tree_items’:
   dulwich/_objects.c:192: warning: implicit conversion shortens 64-bit value into a 32-bit value
   dulwich/_objects.c:224: warning: implicit conversion shortens 64-bit value into a 32-bit value
   dulwich/_pack.c: In function ‘py_apply_delta’:
   dulwich/_pack.c:98: warning: implicit conversion shortens 64-bit value into a 32-bit value
   dulwich/_pack.c:101: warning: implicit conversion shortens 64-bit value into a 32-bit value
   zip_safe flag not set; analyzing archive contents…
   dulwich.tests.__init__: module references __file__
   dulwich.tests.test_index: module references __file__
   dulwich.tests.test_objects: module references __file__
   dulwich.tests.test_pack: module references __file__
   dulwich.tests.utils: module references __file__
   Adding dulwich 0.8.0 to easy-install.pth file
   Installing dul-daemon script to /usr/local/bin
   Installing dul-web script to /usr/local/bin
   Installing dulwich script to /usr/local/bin
   
   Installed /Library/Python/2.7/site-packages/dulwich-0.8.0-py2.7-macosx-10.7-intel.egg
   Finished processing dependencies for hg-git>=0.3.1
4. Edit your ~/.hgrc to enable the Hg-Git Mercurial extension, as noted in the Hg-Git documentation.
   
   [extensions]
   hgext.bookmarks =
   hggit =

That’s it! Once Mercurial 1.9 plus Hg-Git 0.3.1 or later are installed and you’ve enabled Hg-Git in your ~/.hgrc, you are ready to use Mercurial with local and remote Git repositories.

I’m thinking about performing surgery on my Mac Pro. It’s been a while since my computer has felt fast, or like I had enough storage to do what I want to do with it.

I want a lot more storage in the case. I want to see the performance difference that upgrading to an SSD boot disk might make. I want to continue to support Boot Camp, since there is the off chance I may boot into Windows. Whatever happens, I want the new storage to be faster than what it’s replacing.

I already have a CalDigit RAID card, obtained late in 2010. I haven’t populated it yet, so I still have flexibility. The RAID card will allow me to add multiple drives into one larger volume, which should produce a performance benefit over having a single larger drive. (The latest generation of drives just hit 3 TB in capacity.)

Here’s the plan I am roughing out:

• Reroute the motherboard SFF-8087 (iPass) connection to the optical drive bay, breaking it out into SATA connections. From one forum post I found, I think that it would be good to have an iPass cable longer than the common 0.5 meter variety. The Adaptec 1 meter SFF-8087 to SFF-8482 cable seems to be a good choice; it has removable power cables that appear to be Molex-to-SATA. It’s also one of the least expensive options I uncovered, especially when considering cables that have SFF-8482 connectors that combine SATA data and power.
• Set up space for a 2.5 inch and 3.5 inch drive in the empty lower optical bay with the OWC Multi-mount 2.5“ to 3.5” and 3.5“ to 5.25” bracket and cable set for 2006-2008 MacPro. I don’t really need the entire kit, but I’m hoping the bundled Molex-to-SATA power splitter will work with the Adaptec iPass cable to support both drives from the single Molex cable in the bottom half of the bay.
• Get a relatively small OWC Mercury Extreme Pro SSD to set up as the primary boot disk, physically locating it in the OWC bracket in the optical bay. Connect it to the new iPass cable.
• Use one of my existing 3.5 inch drives in the optical bay as a Boot Camp disk. Connect it to the new iPass cable.
• Reroute the iPass connector from the motherboard to the CalDigit RAID card, so that the four 3.5 inch SATA drive bays are associated with that controller.
• Populate the four drive bays with matched drives for a RAID. These will hold user data that doesn’t fit on the SSD.
• Add a UPS that supports USB shutdown on Mac OS X. I’m looking at the CyberPower CP1500PFCLCD. Graceful shutdown during power outages will be critical for the RAID array.
• Optionally route the two remaining motherboard SATA connectors, which I’ve heard do not support booting or Boot Camp, to a back panel eSATA PCI Express insert. This would give me more options for external storage beyond FireWire 800. This will be important for faster local backup, if I can get to that point. (While the CalDigit RAID card does support external storage, it reportedly can only use CalDigit’s own enclosures.)
• Optionally add more RAM. Memory for my early 2008 Mac Pro is on the down side of the commodity curve, so it’s not getting any cheaper.

Of course, all of this is all more expensive than I would like — especially since right now it’s something of a gamble as to whether it would work or not — but the more I think about it, the more fun it seems. I haven’t taken on a project like this in a long time.

As you may know, I absolutely live to submit crash and bug reports to vendors.

Normally, these reports are staid affairs involving copious amounts of detail, exquisite reproduction steps, and both expected and actual results. I’m sure that these kinds of reports get a certain amount of attention from software developers. I say that with confidence because at least one person in that position has told me my bug reports are his favorite. Sure, it was a few years ago now, but I’m sure I’ve still got some mojo.

Occasionally, I get the opportunity to take some creative license with these submissions. For example, there was that one involving the hockey game. The standard was raised after I saw my current all-time favorite crash report.

So, when I had a particularly frustrating crash in Safari, I decided I needed to raise my game. After all, I’ve probably submitted 33 boring crash reports on Safari already. Here’s what I came up with this time:

For those of you reading with Lynx, the text of the submission was:

Safari was launched by me. It had tabs. The set of tabs evolved. They were created to help me. There were so many of them there may have been copies. And I had a plan for them.

I hope someone enjoyed this crash report. And, for all I know, they fixed the problem in Safari 5.0.3.

It’s certainly an understatement to say that there’s been a lot of talk about the Adobe Flash Player on Apple platforms in the last year. On Mac OS X, Apple bundles the Flash Player and tends to distribute some — but not all — updates to it.

I wanted compare the bundled Flash Player version against the latest version from Adobe, which is currently v10.1.82.76. So, let’s look at what comes with Snow Leopard from the perspective of a codesigned executable.

A quick look at the bundled plugin shows that it is codesigned. This means that it has a known signature. If the executable is modified, the signature will no longer be valid. The signature is tied to the identity of a signing authority, which is generally the source of the software.

It may be helpful to think of codesigning as a tamper-resistant seal from the manufacturer. It’s not going to protect you from lots of different kinds of vulnerabilities, but if its cryptographic signature is intact and valid, you have a good idea that the software hasn’t been modified by a third party.

Mac OS X Leopard and Snow Leopard have shipped with applications signed by Apple. The Flash Player plugin comes from Adobe. So, who signs the bundled Flash Player?

You’d be forgiven for not having your eye drawn to the answer immediately, but it’s right there on the “Authority” lines. Just as with the rest of Mac OS X, Apple signed the Flash Player plugin they bundled with the OS.

Now, let’s upgrade the plugin to the latest version available from Adobe and see what happens to the signature. Courtesy of Preston’s WatchedInstall tool, we can see that the plugin’s CodeResources file is removed during this upgrade. Interestingly, the “Adobe Flash Player Install Manager” application installed with the update is codesigned.

The newer Flash Player version, however, seems to consist of two new plugins contained within the overall structure of a parent plugin. Neither the parent nor the new applications within the same bundle install a new code signature. This results in three unsigned executables:

Therefore, you trade the known security vulnerabilities of the older version of Flash Player bundled with the operating system with a different kind of security problem with the new version. It would be silly to not make that trade if you are browsing the Web at all on a Snow Leopard-based computer.

However, it’s also difficult to understand why a large corporation with the resources of Adobe cannot codesign a piece of software as critical to the Mac OS X browsing experience as the Adobe Flash plugin is — especially when its “Install Manager” application is signed.

It’s also puzzling why Apple continues to trail well behind the latest releases of Flash Player. Add to that mystery the question of why Apple never updates the absolutely antique bundled version of the Shockwave Player plugin.

I came across this hint about display properties on StackOverflow and thought it was worthwhile to write down for later. If you want to get the screen or Desktop resolution of a Mac via Python, you can do so with PyObjC.

First, let’s get the information about the main screen:

If you want just the horizontal and vertical resolution from that blob of data, you can pull the width and height out:

This might be useful in situations where you don’t have any of the “hundred of portable libs in Python that give you access to that information” — such as in your stock Mac OS X Python installation. To clarify: I’m in no way meaning to belittle that there are portable libraries that would let you do the same thing, but you also have to program for your audience and its constraints. One of the reasons I appreciate Python over some scripting languages is that you get so much capability in the Standard Library. However, on Mac OS X, you don’t get modules like pygame by default (yet … and maybe never) while you do get PyObjC.

I had an odd situation over the weekend that resulted in the inability to view the passwords associated with keys in my Mac OS X user keychain. Every time I clicked on the “Show password” checkbox in a key’s detail window, I’d get an “Access to this item is restricted” dialog.

Needless to say, this was disconcerting. I happened to have a lot of data in that keychain — this is what I get for keeping the same one around since Mac OS X 10.0 or 10.1. While I could revert to a backup, the newest backup wasn’t as recent as I would like. Plus, I just wanted to know why the problem had cropped up.

So, I asked about my problem on the Apple-CDSA mailing list. If anyone would be able to help with the obscure corners of keychains, I figured the people there would.

Very promptly, I got a reply from Ken McLeod, which led me to check the validity of the code signature on the Keychain Access utility.

Clearly, the signature and the application didn’t match. Something was amiss.

I reinstalled Mac OS X 10.6.2 on the system, using the latest combo update installer package, and cleared up the problem signature mismatch.

In retrospect, although I wouldn’t have thought of this being a problem, this breakage between the signature and the app — and its affect on my ability to view stored passwords — gives me confidence that thought has been put into the code signing mechanism in Mac OS X. You wouldn’t want a compromised app displaying your unencrypted keychain items, after all.

I had interesting things happen when I ran out of disk space today.

The most notable one was that I saw “Process completed” — or some variant of that — every time I tried to open a Terminal window with a new shell session. I briefly staved it off by specifying Bash as my shell, but then it came right back after opening another tab or two in Terminal. Consulting Google led me to this “Terminal application quits” thread at Apple Discussions. On a lark, I tried deleting /usr/bin/login as one poster suggested. It worked!

…But only for a little while. The problem returned. In the meantime, I had freed up some disk space because I’d realized I couldn’t save files anywhere (“But ~/Pictures is writable!”). Clearly something else had become an issue, because disk space was available.

Then I found another thread, “Terminal’s ’Process Completed’ message and /usr/bin/login,” on Apple Discussions. The more permanent solution from that thread appears to be the removal of corrupted Apple System Log databases. Once I did that and restarted the ASL service, all was well and has stayed that way so far.

Filling up my disk must have corrupted the logs as they were being written or rotated, and led to this cascade failure. Like I said, interesting!

One of the posters in the second Apple Discussions thread indicated that the underlying database corruption issue is addressed in Snow Leopard. However, it seems that you could still see this on Leopard — my experience was with a recently-patched Mac OS X 10.5.8 system.