Archive

Archive for March, 2016

Checking XProtect and Gatekeeper update status on Macs

March 28, 2016 9 comments

As part of making sure that XProtect and Gatekeeper are providing up-to-date protection, it can be worthwhile to see when your Mac received the latest updates from Apple for both XProtect and Gatekeeper. As both are background processes, as well as also receiving Config Data updates silently in the background, it’s not always obvious when updates have been applied.

To assist with this, I’ve written a couple of scripts to report the last time that Gatekeeper and XProtect have been updated on a particular Mac. For more details, see below the jump.

Read more…

Running processes in OS X as the logged-in user from outside the user’s account

March 25, 2016 3 comments

One challenge that can crop up for Mac admins is the problem of running a script or other tool with root privileges and using it to launch and run another tool, script or application as if the logged-in user had launched it. An example of this would be installing Dropbox using an installer package, then launching the Dropbox application as the logged-in user as a post-installation task. One reason to do so would be to give the user the opportunity to sign into their Dropbox account.

To accomplish this task, Apple has provided functionality in the launchctl tool.

For 10.9.x and earlier, launchctl‘s bsexec function was used for this purpose. bsexec allows you to start a process like a tool, script or application in a specific context. One way to get the correct context for the logged-in user is to identify the process identifier (PID) for the loginwindow process associated with the logged-in user, which can be accomplished by using the command below:

ps auxww | grep "/System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow" | grep logged_in_username_here | grep -v "grep" | awk '{print $2}'

For example, if I logged in with an account named username, running the command shown below should provide the PID for the username account’s loginwindow process:

ps auxww | grep "/System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow" | grep username | grep -v "grep" | awk '{print $2}'

Screen Shot 2016 03 25 at 1 08 11 PM

 

Once the PID has been identified, it can be used to identify the context that I want to start a process in. For example, the commands below can be run with root privileges to first identify the correct PID for the username account’s loginwindow process, then launch Safari as the username account using the open command:

ps auxww | grep "/System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow" | grep logged_in_username_here | grep -v "grep" | awk '{print $2}'
launchctl bsexec PID_number_here open "/Applications/Safari.app"

Screen Shot 2016 03 25 at 1 17 19 PM

 

Screen Shot 2016 03 25 at 1 19 46 PM

 

When we check the process list for which account is was launched from, the Safari process should show up as being run by the username account.

Screen Shot 2016 03 25 at 1 18 37 PM

 

If you wanted to automate opening Safari as the logged-in user, you could run a script like the one below with root privileges:

Starting in OS X Yosemite, Apple made a number of changes to the launchctl tool and added a new asuser function. The asuser function is designed to take the place of the bsexec function, in the context of starting processes in the context of a specific user account. This makes it easier, as you now just need to figure out the username and do not have to figure out the PID of the user’s loginwindow process.

You can identify the user by either the user’s account name, or by the account’s UID. One way to identify an account’s UID is to use the id command as shown below:

id -u username_goes_here

To continue with the example of opening Safari, you can run the commands below to first identify the correct UID, then launch Safari as the username account using the open command:

id -u username_goes_here
launchctl asuser username_uid_goes_here open "/Applications/Safari.app"

 

Screen Shot 2016 03 25 at 2 09 27 PM

Screen Shot 2016 03 25 at 2 07 21 PM

 

Screen Shot 2016 03 25 at 2 49 03 PM

If you wanted to automate opening Safari using the logged-in user’s UID, you could run a script like the one below with root privileges:

As mentioned earlier, you can also use just the account name with launchctl‘s asuser function. In that case, you can run the command below to launch Safari as the username account using the open command:

launchctl asuser username_goes_here open "/Applications/Safari.app"

If you wanted to automate opening Safari using the logged-in user’s account name, you could run a script like the one below with root privileges:

Creating a DNAStar Lasergene 13.x installer

March 17, 2016 5 comments

As part of my day job, I support some medical research software packages that most Mac admins have likely never heard of. One of these software packages is DNAStar‘s Lasergene software suite. Up until now, this software used an Installer VISE installer, which required me to completely repackage the software for deployment. However, as of Lasergene 13.x, DNAStar has switched to using Bitrock’s InstallBuilder for the Lasergene installer. This tool does not produce standard installer packages, but InstallBuilder installer applications do support installation and uninstallation via the command line. That allows me to run an installation or uninstallation of the Lasergene suite by using the commands shown below:

To install a copy of DNAStar Lasergene which uses a network license server:

"/path/to/DNASTAR Lasergene Installer.app/Contents/MacOS/installbuilder.sh" --mode unattended

To install a copy of DNAStar Lasergene which uses an individual license code:

"/path/to/DNASTAR Lasergene Installer.app/Contents/MacOS/installbuilder.sh" --dnastarProductKey XXXXX-XXXXX-XXXXX

To uninstall DNAStar Lasergene:

"/Applications/DNASTAR/Uninstall Lasergene 13.app/Contents/MacOS/installbuilder.sh" --mode unattended

While this installation method is still not ideal, I can at least script it. That makes it an improvement over the hand-crafted installers I previously had to create for Lasergene.

Unfortunately, there is a quirk of Lasergene’s installation process which carries over from the Installer VISE days, which is that the Lasergene installer assumes that the account running the installation is going to be the owner of the application. So if you install Lasergene as your local admin, that may mean that your users aren’t able to run the Lasergene applications because they may not have permission to run the applications or access one or more of the application data files.

To address both the installation and permissions issues, I was able to create an installer using this method that handles both the installation and then fixing the permissions as a post-installation task. For more details, see below the jump.

Read more…

Speaking at X World 2016

March 17, 2016 3 comments

I’ll be speaking at X World 2016 in Sydney, Australia, where I’m planning to do a couple of sessions. This is the first time I’ve had the pleasure of traveling to Australia, so I’m looking forward to this opportunity to meet and learn from the Australian Mac admin community.

X World 2016 will be held at the University of Technology Sydney (Broadway City Campus) and is scheduled for the week of July 6th. Hope to see you there!

Categories: X World 2016

Using AutoPkg recipes with alternate software downloads

March 15, 2016 Leave a comment

An issue that crops up occasionally for AutoPkg is that a vendor will release a new version of their software but be slow to update the download location which an AutoPkg recipe is looking at. Alternatively, there may be instances where a software vendor releases two versions of their software and AutoPkg only picks up one of them. A good example of this is Oracle’s Java 8, where the past few releases of Java 8 have actually had two versions of Java 8 released simultaneously.

Fortunately, if you can manually download the needed software, there is a way to leverage AutoPkg to generate the needed installer without needing to change your AutoPkg recipe. See below the jump for details.

Read more…

Deploying Word, Excel and PowerPoint templates for Microsoft Office 2016

March 6, 2016 2 comments

In many shops, Mac admins have a requirement to deploy templates for Microsoft Word, Excel or PowerPoint. With Microsoft Office 2011, this is a relatively straightforward process as there is an existing directory for Word, PowerPoint and Excel templates at the location shown below:

/Applications/Microsoft Office 2011/Office/Media/Templates

Template files deployed to this location are available to all users on the Mac.

Screen Shot 2016 03 05 at 9 29 10 PM

 

In contrast, the necessary support directories for templates are not created by Office 2016 by default, so they are not likely to exist unless templates had previously been installed. The reason for this is that Office 2016 apps are sandboxed and don’t have the ability to write to locations outside the application sandbox unless granted permission. Fortunately, the Office team at Microsoft has documented in the PDF document linked below where templates should be installed:

Installing User Content in Office 2016 for Mac:
http://macadmins.software/docs/UserContentIn2016.pdf

When I read the documentation, it showed that the correct place to store template files is at the location shown below:

/Library/Application Support/Microsoft/Office365/User Content.localized/Templates.localized

Template files deployed to that location are available to all users on the Mac.

Screen Shot 2016 03 05 at 10 12 32 PM

 

As mentioned previously, the necessary support directories for templates are not created automatically when Office 2016 is installed. To address this, I’ve written a script that will create the needed directory structure. For more information, see below the jump.

Read more…

%d bloggers like this: