SWY's technical notes

Relevant mostly to OS X admins

Monthly Archives: March 2014

10.5 to 10.9 upgrade

The time came to upgrade my mom’s trusty iMac 8,1 to Mavericks: being stuck on Firefox 16 and no access to the App Store just wasn’t cutting it anymore.  Unfortunately, the minimum system requirements to install Mavericks is to already be on 10.6.8.  I didn’t want to sit through 2 OS upgrades, so instead I went with the following:

  1. Purchase Snow Leopard. Not a required technical step, but technically required to be legally compliant. If you opt to skip this step, Apple will never know.
  2. Partition a spare external drive into 2 volumes.  I took an unused 1TB drive, made a 50 gig partition, named it Tools, and named the rest Transfer.
  3. Use AutoDMG to make an unbooted 10.9.2 .dmg, including extra packages as needed. Since she’s a CrashPlan user, Java was appropriate.
  4. Use Disk Utility to duplicate that .dmg output to both the Transfer and Tools partitions.
  5. Boot my computer from the Tools partition, and go through the setup wizard.  I then downloaded Carbon Copy Cloner into the Tools volume.
  6. Take this disk to mom’s place, and boot from the Transfer volume.  The never touched 10.9.2 install will start, and Migration Assistant will be happy to see the computer’s internal drive and Time Machine as sources to migrate from, and import data and settings to this temporary boot volume.  Don’t let the icons confuse you- in this case, they’re backwards, and don’t represent what’s really happening:
    2014-03-15 13.27.57
  7. When this completed, I had a full copy of her stuff migrated into 10.9, and I’ve not yet touched her real boot volume.  In the small possibility that something might go awry, no real data was at risk.  At this point, I could confirm the new volume, see that Mail upgraded, printer drivers downloaded, ect.
  8. Once satisfied the import to the new OS was working properly, I rebooted from the Tools volume, and used Carbon Copy Cloner sync the internal disk to match the Transfer volume. It’s smart enough to see that there’s not a recovery partition on the old 10.5.8 disk, and handle making that.
  9. With that done, it’s all good to go, and I have one more copy of her iMac in case old harddrive starts acting old.

Repackaging NetExtender- updated method

While my earlier blogged method for repackaging SonicWall NetExtender gave solid results, I’d rather learn to use The Luggage, due to it being easier to repeat consistent results.  The issue to solve with NetExtender is that while Dell provides a drag and drop .app that’s simple to dump into the Applications folder, it’s not ready to run.  Without adjustments, on first launch, it makes this request from the user:Screen Shot 2013-01-28 at 1.01.02 PM

That wasn’t going to work in 2013, and it’s still not in 2014.  Approving this request leads to an authentication dialog, and once authenticated, “magic happens”, and NetExtender is happy, probably until the next MacOS update, where the dialog will return.  Therefore, the question was to determine what sort of “magic” happens there.

Enter fseventer.  Like opensnoop, it will answer the question “what file(s) are being modified?”  The answer I came up with was a group in /usr/sbin and in /etc/ppp (which was consistent with my Composer work last year)

Next was to gather these files into The Luggage, and create a makefile.  My first attempts to build the package included many more cp, chown, chmod steps than necessary, but with some help from @chilcote and @mikeymikey, the following was created:

USE_PKGBUILD=1
include /usr/local/share/luggage/luggage.make

TITLE=NetExtender_7.5.757
PACKAGE_NAME=NetExtender_7.5.757
REVERSE_DOMAIN=com.hiebing
PAYLOAD=\
    unbz2-applications-NetExtender.app \
    pack-script-postinstall \
    pack-Library-LaunchAgents-com.hiebing.netextender.plist \
    pack-usr-sbin-netExtender \
    pack-usr-sbin-nxMonitor \
    pack-usr-sbin-uninstallNetExtender \
    pack-config \
    pack-man1-netExtender.1 \
    pack-ppp \
    fix-perms

pack-config: netextender_config.sh l_Library
    @sudo mkdir -p ${WORK_D}/Library/Hiebing/Scripts
    @sudo chown -R root:wheel ${WORK_D}/Library/Hiebing
    @sudo chmod -R 755 ${WORK_D}/Library/Hiebing
    @sudo ${INSTALL} -m 755 -g wheel -o root "netextender_config.sh" ${WORK_D}/Library/Hiebing/Scripts

pack-ppp: ppp.tar.bz2 l_private_etc
    @sudo ${TAR} xjf ppp.tar.bz2 -C ${WORK_D}/private/etc
    @sudo chown -R root:wheel ${WORK_D}/private/etc/ppp
    @sudo chmod -R 755 ${WORK_D}/private/etc/ppp
    @sudo chmod 644 ${WORK_D}/private/etc/ppp/peers/sslvpn
    @sudo chmod 744 ${WORK_D}/private/etc/ppp/sslvpnroute
    @sudo chmod 666 ${WORK_D}/private/etc/ppp/netextenderppp.pid
    @sudo chmod 666 ${WORK_D}/private/etc/ppp/netextender.pid
    @sudo chmod 644 ${WORK_D}/private/etc/ppp/options

fix-perms:
    @sudo chmod u+s ${WORK_D}/usr/sbin/uninstallNetExtender
    @sudo chmod 744 ${WORK_D}/usr/sbin/nxMonitor

Postinstall: a 1 liner to suid /usr/sbin/pppd.  In retrospect- that could have gone in the fix-perms statement.

com.hiebing.netextender.plist: a LaunchAgent that runs a configuration script, defined in pack-config

netExtender, nxmonitor and uninstallNetExtender need to go in /usr/sbin, so pack-usr-sbin-<item> handles that

pack-config: the script, which checks to see if ~/.netextender exists, and if not, creates the appropriate config file, based on my account config.

pack-man1 handles the man file

pack-ppp unarchives the contents of /etc/ppp, and ensures ownership and permission match the source, as NetExtender is checking these on first launch.

fix-perms does just that.

After running make pkg to build the pkg, I have a nice installer to push to clients, and a LaunchDaemon to configure the connection for each user login.  While this handles packaging for install, there’s one more aspect to keeping a healthy NetExtender: MacOS updates may remove the suid on /usr/sbin/pppd.  It happened on 10.8.5, 10.9, and 10.9.2.  One way to handle this is puppet, another is an installer in munki- mine has the following components:

An installcheck_script that queries the permissions on /usr/sbin/pppd:

#!/bin/bash
#installcheck for /usr/sbin/pppd permissions

proper=-r-sr-xr-x
current=`ls -al /usr/sbin/pppd | cut -c1-10`

if [ $current == $proper ] ; then
    exit 1    
else
    exit 0
fi

 

A postinstall script that is run if the permissions vary:

#!/bin/sh
chmod u+s /usr/sbin/pppd

exit 0

Net result is that after any update that alters the suid of pppd, on next munki run, it will be reset, and users will not be asked to “do maintenance tasks”- and more importantly, not asked to authenticate.