North Star Labs

I constantly use keyboard sharing software like synergy2, teleport, x2vnc, x2x, etc… I’ve settled on synergy since it’s relatively platform independent. I use the command line program rather than synergyKM, just because I find it far more reliable. I also tunnel through ssh and found the certificate stuff in synergyKM to be less than ideal.

In any case, I wrote a small shell script which fires up the synergy server on the machine with the physical keyboard attached, then reaches out via ssh to the client machine, copying the synergyc client binary, establishes a reverse tunnel back to the synergy server on my laptop, launches the client in the background on the remote machine and connecting to the tunnel, then finally detaches the ssh session. When I close my lid and walk away at the end of the day, the tunnel and synergy processes gracefully clean up after themselves.

I find this setup ideal, because whenever I bring my portable machine into the office in the morning, I just run

kvmc ford

and the script takes care of everything for me.

The scripts are located in the northstarlabs repository. As usual, most of their usefulness is derived from password-less ssh authentication using public keys and ssh-agent.

I’ve been using a relatively new application called Jing to create nice looking flash screen-casts. The application is currently free (as in beer), runs on Mac and Windows, and allows me to quickly convey the exact problem I’m working on. My only gripe so far is that it doesn’t work at all with network homes. I’ve filed a bug, hopefully they fix it soon.

I think I’m also going to have my students re-do some of our more tedious documentation, like our rather long Thunderbird setup guide, using a screencast instead of screenshots.

I’ve also used vnc2swf, but Jing is far easier to work with.

Jing is at: http://www.jingproject.com/

You may have been given a package provided by some vendor, and they didn’t package things quite to your standards. Perhaps they’re installing setuid root executable programs with world-writable permissions all over your system, or they have problematic post flight scripts which try to modify the dock or open up a web page.

Having an Apple Installer.app package is nice, but it’s not much good if you can’t easily deploy it to a large number of hosts. I generally go about fixing poor quality packages using the following methods.

To fix misbehaving scripts, I generally just dive right in and hack the script itself. If you right click on the package and “Show Package Contents” you can dive into the Resources folder and directly modify the preflight, post-flight, pre-upgrade, and post-upgrade scripts as you see fit. Apple has a Knowledge Base article on the subject: Software Delivery Guide.

To fix file permissions, I manually unpack the package archive, change any permissions that are wrong, and then re-package everything.

1. Unpack the archive

   1. mkdir /tmp/RootFileSystem/

   2. cd /tmp/RootFileSystem/

   3. sudo pax -z -pe -r -f /Volumes/foobar/Foobar-1.2.3-4.pkg/Contents/Archive.pax.gz

2. Open PackageMaker.app (Distributed with Xcode Tools.)
   1. Re-use the bundle identifier and version from the source package:

      /Volumes/foobar/Foobar-1.2.3-4.pkg/Contents/Info.plist

   2. You can optionally overwrite permissions when installing the package
   3. Ensure your permissions match the system default permissions on folders like /, /Library, /Applications, etc…
   4. To check what the system default permissions shoudl be, look at the owner, group, and file mode in the bill of materials file from the BaseSystem package:

      lsbom /Library/Receipts/BaseSystem.pkg/Contents/Archive.bom | less

   5. Finally, repackage your cleaned up RootFilesystem by building your Package Maker project.
3. Bundle the resulting package into a DMG (Optional):

   1. hdiutil create -srcFolder /tmp/Foobar.pkg /home/archive/osx/pkgs/apps/Foobar-1.0.0-1.dmg

This procedure allows you to verify (lsbom) and manually modify (pax + Package Maker) packages that don’t meet your requirements.

I added most of the iLife applications to our base image today, and received the error:

installer: Error – You are attempting an unsupported installation. If you wish to install an individual application, please use the iLife installer and select the Custom button.

However, using the CM_BUILD environmental variable, I’m able to install packages via the command line from the Mac OS X second DVD that ships with all new machines. For example:

export CM_BUILD=CM_BUILD

If you need to install packages to an alternate volume, say another machine booted in Firewire Target Mode, or a disk image, then you might want to enable the CM_BUILD option.

I’m not entirely sure what CM_BUILD stands for, but I got the idea from the Mac OS X chroot installation HOWTO documents floating around.

Adobe Products have a self healing feature which checks quite a few of the files on disk at launch and attempts to modify them if they’re different than the installed versions. This is a huge problem for me, as a system administrator, as I’ve created my Adobe CS3 package with tighter permissions than Adobe installs. For example, many of the files are owned by the account I installed CS3 with, but I need them to be owned by the root account.

At launch, Adobe Acrobat gives an error: “Type an Administrator’s name and password to make changes to Acrobat.” Clearly, normal users don’t have permissions to do this and your phone may end up ringing quite a bit.

The solution is to disable the Self Healing feature entirely by telling the programs not to enforce any of the checks it’s making. To do this, edit /Library/Application Support/Adobe/Acrobat/AcroENUPro80SelfHeal.xml and replace all instances of “YES” and “REQUIRED” (all caps) with “NO”. Distribute the new xml file, and the self healing checks will no longer be enforced and you’re free to manage permissions and access how you see fit.

I received a request to deploy Gap (Groups, Algorithms, Programming – a System for Computational Discrete Algebra). The installation process is a bit involved, so these packages might help, as they work well with Apple Remote Desktop. This package places gap at /usr/local/gap4r4 and places the executable at /usr/local/bin/gap The package does not modify the PATH, so you’ll have to manage that yourself.

The package is: Gap-4.4.9-1.dmg