Resharing NFS Mounts on OS X Server 10.6

Assume, there are two OS X Servers, one with lots of free space and another that acts as an OD/AFP share. To setup the first server (the one with lots of space) as an NFS share, do the following:

  1. In Server Admin -> Share Points: Add a new share point. Under “Protocol Options” go to NFS and check on “Export this item and its contents to client list”
  2. Add second OS X Server IP to the the client list. Set the mapping Root to Root.
  3. In terminal enter the command ‘rpcinfo -p’ and make note of the ports.
  4. In Server Admin -> Firewall, make sure all ports from the step above are are open

On the Existing AFP server:

  1. In Server Admin -> Share Points: Right click a volume and select “Mount NFS Share..” and enter in the URL of the NFS share. Now this share will show up in the list.
  2. Click on the share and on “Protocol Options” and select AFP and check on “Share this item using AFP”
  3. Grant users privleges to the share

This is useful when there is an existing AFP Server that users connect to (which is running out of space).
References:
[1]10.6 Server: How to get NFS disk serving working properly
[2]Resharing NFS Mounts as AFP Share Points

Munki and postinstall scripts

One the great features of Munki is that it will run postinstall scripts. This is great for creating quick and dirty custom pkgs as well as customizing vendor supplied pkgs for any environment. Three such cases in our environment are (1) Adobe Acrobat 9, (2) MS Office 2011, (3) Firefox 4.0.1

Adobe Acrobat 9

Acrobat is the enterprise’s standard application for editing/creating PDFs. As such it’s important to keep Acrobat up to date and working on client machines. The problem with this occurs at two places. The first being updates. Before the release of CS5, Acrobat had no real solution to packaging and deploying updates, and this has plagued Acrobat 9. The latest acrobat update requires you to have all previous updates installed (the reason for this will be explained a little later), and it requires you to select which acrobat installation to upgrade. This can be very troublesome, however Munki easily solves that problem with update_for and requires keys. The most annoying feature Acrobat has is the self-heal feature which requires the user to authenticate on first run after a patch install to “fix” the installation. There is documentation on the Munki wiki as how to bypass this:

              <key>postinstall_script</key>
        <string>#!/bin/bash
sed -i .bak 's/\&lt;string\&gt;AcroEFGPro90SelfHeal\.xml\&lt;\/string\&gt;//g' /Applications/Adobe\ Acrobat\ 9\ Pro/Adobe\ Acrobat\ Pro.app/Contents/MacOS/SHInit.xml
sed -i .bak 's/\&lt;string\&gt;AcroEFGDist90SelfHeal\.xml\&lt;\/string\&gt;//g' /Applications/Adobe\ Acrobat\ 9\ Pro/Acrobat\ Distiller.app/Contents/MacOS/SHInit.xml
        </string>

This suppresses the self heal and the user is happy. However with this fix, a CORE file in Acrobat’s setup has been altered and the patching process will break in the future. Going back to a little earlier, the reason Acrobat requires that all previous updates be installed is because it checksums the files it expects, if a patch has been skipped, the checksum on a later patch will fail. This is the same for the SHInit.xml file. The update process doesn’t always checksum the file, but for certain patches it does. Therefore, a preinstall_script is needed to fix the installation before the update starts:

        <key>preinstall_script</key>
        <string>#!/bin/bash
          if [ -f "/Applications/Adobe Acrobat 9 Pro/Adobe Acrobat Pro.app/Contents/MacOS/SHInit.xml.bak" ]
          then
          mv "/Applications/Adobe Acrobat 9 Pro/Adobe Acrobat Pro.app/Contents/MacOS/SHInit.xml.bak" "/Applications/Adobe Acrobat 9 Pro/Adobe Acrobat Pro.app/Contents/MacOS/SHInit.xml"
          fi
        </string>

Now with little effort on the sysadmin’s part, Acrobat has been fixed.

MS Office 2011

Munki installs office very nicely, and in our environment, we have a pkg that customizes and registers Office. However, it does so by writing files to the User Template directory. This way Office is registered for every new local user on the machine. However, existing users would still need to register and activate Office. In order to install the pkg for them, we use the following postinstall_script to copy the files from the User Template directory to existing users directories:

        <key>postinstall_script</key>
        <string>#!/bin/sh
dir="/System/Library/User*Template/English.lproj/Library"

for folder in /Users/*
do
if [ $folder != "/Users/Shared" ]
then
/bin/cp $dir/"Preferences/com.microsoft.autoupdate2.plist" $folder/Library/Preferences/
/bin/cp $dir/"Preferences/com.microsoft.error_reporting.plist" $folder/Library/Preferences/
/bin/cp $dir/"Preferences/com.microsoft.Excel.plist" $folder/Library/Preferences/
/bin/cp $dir/"Preferences/com.microsoft.language_register.plist" $folder/Library/Preferences/
/bin/cp $dir/"Preferences/com.microsoft.office.plist" $folder/Library/Preferences/
/bin/cp $dir/"Preferences/com.microsoft.outlook.database_daemon.plist" $folder/Library/Preferences/
/bin/cp $dir/"Preferences/com.microsoft.outlook.office_reminders.plist" $folder/Library/Preferences/
/bin/cp $dir/"Preferences/com.microsoft.Powerpoint.plist" $folder/Library/Preferences/
/bin/cp $dir/"Preferences/com.microsoft.Word.plist" $folder/Library/Preferences/
chown -R ${folder/\/Users\//} "$folder/Library/Preferences/"

fi
done

exit 0</string>

This allows for quick and messy pkgs (such as the one above) to be cleaned up with a postinstall_script.

Firefox 4.0.1

The case of Firefox is very similar to that of Acrobat, because vendor supplied software is being customized for the environment. Firefox is customized by writing to three files within the application that contain our settings:

        <key>postinstall_script</key>
        <string>#!/bin/bash
localsettings="/Applications/Firefox.app/Contents/MacOS/defaults/pref/local-settings.js"
touch -f $localsettings
echo "// MyOrganization additions
pref('general.config.obscure_value', 0);
pref('general.config.filename', 'firefox_CUL.cfg');" &gt; $localsettings

firefox_cul="/Applications/Firefox.app/Contents/MacOS/firefox_CUL.cfg"
touch -f $firefox_cul
echo "// 
// This file sets some default prefs for use at Columbia Libraries
// and locks down some other prefs.
// application updates
//
lockPref('app.update.enabled', false);
lockPref('app.update.autoUpdateEnabled', false);
lockPref('extensions.update.autoUpdate', false);
lockPref('extensions.update.enabled', false);
lockPref('browser.search.update', false);
lockPref('browser.startup.homepage_override.mstone','ignore');
// Password Manager
pref('signon.rememberSignons', false);
// Default browser check
pref('browser.shell.checkDefaultBrowser', false);
// Home page
pref('browser.startup.homepage','http://library.columbia.edu');
pref('browser.startup.homepage_reset','http://library.columbia.edu');" &gt; $firefox_cul

override="/Applications/Firefox.app/Contents/MacOS/override.ini"
touch -f $override
echo "[XRE]
EnableProfileMigrator=false" &gt; $override

exit 0</string>

The main difference between the Acrobat and Firefox case is that in this case files are being created and then written to. There are other use cases such as RealPlayer where the postinstall_script create plists to register the product and hide annoying prompts from the user, however those are better handled with MCX rather than Munki.