Packaging LightroomCC 5.4 for munki

Lightroom isn’t an easy install with munki. There are some tricks you have to keep in mind.

  1. Detect if Lightroom is already installed in installs section
  2. Write the license file as part of postinstall_script
  3. Write default settings as part of postinstall_script
  4. You need an uninstall_script as it doesn’t have an uninstaller

1. Detect if Lightroom is already installed.

For this munki has the installs section. You can create the necessary entry on a Mac that has Lightroom already installed issuing the makepkginfo command.

user@host: ~/Library/Preferences $ makepkginfo -f /Applications/Adobe\ Photoshop\ Lightroom\ 5.app/Contents/MacOS/Adobe\ Photoshop\ Lightroom\ 5

Which gives you this output that you can copy into the munki plist file:

<key>installs</key>
  <array>
    <dict>
      <key>md5checksum</key>
      <string>6ecaf256ee9ebc91cab0254a1c73b787</string>
      <key>path</key>
      <string>/Applications/Adobe Photoshop Lightroom 5.app/Contents/MacOS/Adobe Photoshop Lightroom 5</string>
      <key>type</key>
      <string>file</string>
    </dict>
  </array>

2. Write the license file

The license information is located in:
/Library/Application\ Support/Adobe/Lightroom/Lightroom\ 5.0\ Registration

This is written as part of the post_installscript section.

#!/bin/bash
mkdir -p /Library/Application\ Support/Adobe/Lightroom 

defaults write /Library/Application\ Support/Adobe/Lightroom/Lightroom\ 5.0\ Registration"<dict> 
  <key>serial_number</key> 
  <string>your serial number goes here</string> 
  <key>uuid</key> 
  <string>your UUID goes here</string> 
</dict>" 

chmod 644 /Library/Application\ Support/Adobe/Lightroom/Lightroom\ 5.0\ Registration.plist 

mv /Library/Application\ Support/Adobe/Lightroom/Lightroom\ 5.0\ Registration.plist /Library/Application\ Support/Adobe/Lightroom/Lightroom\ 5.0\ Registration 

3. Write default settings

The default settings go into: /Library/Preferences/com.adobe.Lightroom5.plist
You have to set the country_region settings according to your country.
Probably it isn’t necessary to write the settings in the Non_localized user template too.

This too is written as part of the post_installscript section.


rm /System/Library/User\ Template/Non_localized/Library/Preferences/com.adobe.Lightroom5.plist

defaults write /System/Library/User\ Template/Non_localized/Library/Preferences/com.adobe.Lightroom5 noAutomaticallyCheckUpdates true

defaults write /System/Library/User\ Template/Non_localized/Library/Preferences/com.adobe.Lightroom5 firstLaunchHasRun30 -bool true

defaults write /System/Library/User\ Template/Non_localized/Library/Preferences/com.adobe.Lightroom5 RegistrationField_CountryRegion -string 191

rm /Library/Preferences/com.adobe.Lightroom5.plist

cp /System/Library/User\ Template/Non_localized/Library/Preferences/com.adobe.Lightroom5.plist /Library/Preferences/

chown root:wheel /Library/Preferences/com.adobe.Lightroom5.plist

chmod 777 /Library/Preferences/com.adobe.Lightroom5.plist

4. You need an uninstall_script as it doesn’t have an uninstaller

This script goes into the uninstall_script section of the munki plist file.


#!/bin/bash
#remove license file
rm -R /Library/Application\ Support/Adobe/Lightroom

#remove default settings
rm /Library/Preferences/com.adobe.Lightroom5.plist
rm /System/Library/User\ Template/Non_localized/Library/Preferences/com.adobe.Lightroom5.plist

#remove Lightroom applikation
rm -R /Applications/Adobe\ Photoshop\ Lightroom\ 5.app

BitCasa First Impression

At the end of february 2013 BitCasa ended it’s beta phase. Until the end of the month there was a 50% discount on the one year membership. So I decided to give it a try and go for it.

BitCasa on the Mac

Over the first days BitCasa was really annoying. Files and folders I tried to copy to the unlimited drive din’t copy at all – even after days. The forums were full of complaints from Windows and Mac users. Meanwhile, after a month it got better. I am able do upload files in a reasonable time.

What annoys me still is that the BitCasa App on the Mac requires administrator rights. That is your user account that you use for uploading files has to have Administrator rights in the machine. This is a real no go!

Bitcasa uses a temporary directory for caching files while uploading them. This directory has more than 40 GB in size on my machine. If you have limited space on your disk because your have a SSD drive for example on a MacBook Air you should definitively have a look at the BitCasa settings and reduce the cache to a reasonable size. Second you should exclude the cache from your Time Machine backups.

For local folders on your harddisk BitCasa does support mirroring them to BitCasa but it doesn’t support mirroring of mapped network drives. Thus you can’t use BitCasa as a backup media for your NAS for example. Because I had some kind of backup in mind when I payed for BitCasa – well that doesn’t work for me now.

Bitcasa on the iPad

On the iPad access to my files required me to log out and in again. After that the folders were accessible but I can’t see any pictures in them. Definitively a serious bug. What I’m missing most in the iOS app is a tree view of my files for navigating and browsing through them. Under the Photos section pictures are accessible by the name of the folder they are stored into. But as I have a structure that always ends in the name of the family member that took the photo all albums have the same names. This is the same with the web interface.

After all

There are some more issues with BitCasa that do annoy me, but I don’t want to elaborate further on this because they just make things worse. To come to a conclusion I’d say for the 50% price reduction BitCasa is OK for me but it wouldn’t for the full price. If you plan to use the unlimited drive and pay for it I recommend testing every single feature that you intend to use out befor paying for the service. Read the BitCasa support forums and see which problems other users have.

 

DeployStudio Leaves Fusion Drive Rendered Useless

shapeimage_5storage_fusion

After we deployed our standard DeployStudio image to a brand new iMac with a 3TB FusionDrive for the first time we had to realized that in Disk Utility the volume showed up as corrupt after a check. Somehow DeployStudio (1.5.17) isn’t ready for now to handle FusionDrives.

The question was: “How do we fix the now corrupted drive?” After reading an article in the German Mac&i magazine (issue 9, page 150) and some googling we came to the solution described below. Especially one article on http://blog.fosketts.net was a valuable read.

1) Boot off a external drive e.g. a recovery disk on an USB-stick.
2) Unmount the disk that has the FusionDrive on it.
3) Open terminal and display the structure of your drive:
diskutil cs list
4) Delete the physical drives
diskutil cs removeDisk <ID of SSD>
diskutil cs remove Disk <ID of mechanical drive>
5) This step is not really necessary but it might be a good idea to delete the partition schema.
diskutil zeroDisk disk0
diskutil zeroDisk disk1
6) Now we reconstruct the FusionDrive
diskutil cs create <VolumeName> disk0 disk1
7) Finally we create the volume:
diskutil cs createVolume <ID of logical volume created in the step 6> jhfs+ <VolumeName> 100%

After a reboot you can check the Volume in Disk Utility. The volume test shouldn’t display any errors.

Good luck!