Exporting GarageBand to Google Drive on the iPad

When you try to share a GarageBand project out from the iPad, the immediately apparent options may include only Facebook, SoundCloud, and YouTube (yes, even if you select the More option).

If you want to export your project to Google Drive, you may have to take a few extra steps.

export garageband to google drive 01
Select your project by either tapping Select or long-pressing on the project icon itself.

export garageband to google drive 02
Once it's selected, click the share button (looks like an up arrow pointing out of a rectangle).

export garageband to google drive 03
Select Open in...

export garageband to google drive 04
Before you can select what to open the project in, you'll have to fill in some details about the song. Fill those in.

export garageband to google drive 05
Then you should see a lot more applications appear to share it in, including Open in Drive. You may have to do a bit of horizontal scrolling to get it to appear, depending on how many shareable-to apps you have installed.

export garageband to google drive 06
Once Google Drive opens, you'll then be prompted to upload the song. Select Upload.

Absolute beginner’s guide to setting up Munki (not monkey)

Table of Contents

Why this guide?
What is Munki?
What are the basic requirements for this setup?
Install on the server Mac the needed software
Prepare the server to be a Munki software repository.
Use MunkiAdmin to set up your repositories, catalogs, and manifests.
Import software into your repository manually
Figure out your server Mac's IP address
Set up the Munki client
Set up AutoPkgr

Why this guide?

While there's no dearth of comprehensive guides to Munki out there, many of them are too comprehensive (to the point of being potentially overwhelming to new users). The focus of this guide is to get you up and running with Munki, not to give you a comprehensive, in-depth explanation of everything Munki can and cannot do.

Interested in the more comprehensive guides instead? Check out the following links:

Still here? Okay. Let's proceed with the non-comprehensive guide...

Return to top

What is Munki?

Munki is a tool to deploy software out to Mac clients. You can force updates from the server or create optional software for clients to install themselves.

Return to top

What are the basic requirements for this setup?

  1. One Mac (OS X 10.8 or higher) that can act as a server (yes, you can actually run the server on Linux, Windows, etc., but again—the point of this tutorial is to get you up and running in at least one fashion and not to provide a comprehensive guide to all use cases).
    N.B.: you do not have to have OS X Server installed or have an actual Xserve machine. It can be any Mac that you want to repurpose as a Munki "server."
  2. At least one Mac that can act as a client (you will, supposedly, have many clients eventually).
  3. The latest Munki Tools release (this is the same installer for both the client and the server, but we'll tweak the installation slightly for the server).
  4. The latest MunkiAdmin release (not necessary for Munki operations in general but necessary for this tutorial).
  5. The latest AutoPkgr release (again, not necessary for Munki but extremely helpful).
  6. A working Internet connection... of course.

Return to top

Install on the server Mac the needed software

On the Mac that's going to be the server hosting the software, install all three downloads.


munkiadmin Once you double-click the .dmg for MunkiAdmin, it's a simple drag-and-drop to the Applications folder (option to copy to Utilities instead, if you'd prefer).


autopkgr Double-click the .dmg for AutoPkgr and then drag and drop that to the Applications folder.

Munki Tools

Munki Tools has more of a wizard-style installer.

munkis01 Click Continue.

munkis02 You probably have only one drive you want to install to, but if you have two or more, pick the one you want, and then click Continue.

munkis03 For the server, click Customize.

munkis04 Uncheck Managed Software Center and Munki launchd agents, and make sure Munki core tools and Munki admin tools are checked.

munki11b Authenticate with an admin username and password. Then click Install Software.

munkis06 Click Close.

Return to top

Prepare the server to be a Munki software repository.

The standard in all the guides is to put the Munki repository in the shared users folder and then create a symlink to the web server directory (the equivalent of /var/www or /var/www/html for you Linux geeks out there). For consistency's sake, we'll keep that standard here, but if you're dedicating this machine to being a Munki repository, there isn't any reason you couldn't just make the repository directly (not just symlinked) in the web server directory.

We're still on the server Mac (until further notice).

Open up the Terminal.app (you can find it in /Applications/Utilities or search for it with Spotlight).

Then, paste in these commands:

cd /Users/Shared
mkdir -p munki_repo/catalogs
mkdir munki_repo/manifests
mkdir munki_repo/pkgs
mkdir munki_repo/pkgsinfo
mkdir munki_repo/icons
chmod -R a+rX munki_repo
sudo ln -s /Users/Shared/munki_repo /Library/WebServer/Documents/
sudo apachectl start

To sum up (in case you don't speak bash), we just created a directory and a few subdirectories for Munki business, made sure the proper permissions on that directory are in place, made a symlink to that directory from the web server directory, and then started up the Apache web service.

Note: If you're using OS X Server, the path is slightly different—more details at Setting Up Munki With OS X Yosemite Server.

You may also want to configure munkiimport:

/usr/local/munki/munkiimport --configure
It will ask you some questions. For the path to the Munki repo, put in /Users/Shared/munki_repo, since that's where we just created the Munki repository location.

For the repo fileshare URL, leave it blank. The rest you can decide for yourself or just stick with the defaults by hitting Return/Enter instead of typing something in. (Personally, I prefer a .plist extension and TextWrangler.)

Return to top

Use MunkiAdmin to set up your repositories, catalogs, and manifests.

Launch up MunkiAdmin (you installed this earlier).

When it launches up the first time, it'll immediately prompt you to Select a munki Repository. Go ahead and navigate to the /Users/Shared/munki_repo directory and then click Open.

Once you do that, it should be fairly empty, that's because all you have are the empty directories you'd created earlier.

You may want to make it so that MunkiAdmin remembers your repository instead of asking you every time at startup which repository you want to use.

munki07a Go to MunkiAdmin > Preferences....

munki07b Then, next to On Startup, select Open previous repository.

munki07c Once that's selected, you can close the Preferences window.

munki08 Go to File > New Catalog. The catalogs are general lists of what software is available in the repository—a sort of table of contents.

munki09 Call your new catalog production.

I'd also recommend creating a testing catalog. That's what most AutoPkg recipes will default to, and it's a good idea in general to have a set of testing clients install updates or new packages before you move the packages into production.

munki10 Go to File > New Manifest. Manifests pick out of the larger catalog(s) and then select software available to certain users. Each machine should have its own individual manifest, but each individual manifest can also include other manifests.

munki11b Call your new manifest the serial number of your test machine.

Note: Why the serial number? I explain more about this in Another opinionated guide to Munki manifests.

Return to top

Import software into your repository manually

One way to get software into your repository is manually—you download Firefox, for example, and it comes as a .dmg file.

In (still) MunkiAdmin (still on the server Mac), go to File > Import Items.

munki13 Find your .dmg file and open it.

munki14 Save it, when prompted.

munki15 You may see a dialogue pop up that says Status: Running makepkginfo.

munki16 When prompted to save, save again.

Note: With a lot of basic packages, it's fine to import it this way using MunkiAdmin. I've found that some packages import better using the command line (e.g., Adobe Creative Suite), so you may—after you get the swing of the point-and-click way—want to try using munkiimport at the command line instead).

munki17 If you go to catalogs (Cmd-2), you'll see your production catalog. If you click on production, you should see your one imported package there unchecked. If you want to include that package in your catalog, check (or tick) the box next to it. Then click the Save button above it.

munki18b Same deal if you go to manifests (Cmd-3), you'll see your serial number manifest that's empty.

You'll also see some different categories within the manifest. Managed Installs is for software you want definitely installed (Managed Uninstalls is for software you want definitely removed). Managed Updates are for software you definitely want updated (whether originally installed through Munki or not). Optional Installs are items you want the clients to have the option to add or remove. Click on the category you want to add the package to.

munki19 If you click the + (plus sign) near the bottom, you can now select the package you'd previously added to your catalog.

munki20b Again, click the Save button to save your changes.

Return to top

Figure out your server Mac's IP address

Here are four ways to do that. I'd recommend


in the Terminal.app as the quickest method.

Make a note of the IP address. We'll need that later for the Munki client(s).

Note: if you are on a domain, you can also use your server Mac's host name to reference it instead of using the IP address (e.g., munki.yourorganization.edu).

That's it for the server side (for now... until we come back for AutoPkgr).

Return to top

Set up the Munki client

As I mentioned before, Munki Tools is the same setup package, whether you're on the server Mac or the client Mac.

munkis07 So for the client Mac, just install those tools (you don't need the Munki admin tools here). This time, however, you will have to reboot immediately after installation.

Then, in the Terminal.app, put in your own version of this command:

sudo defaults write /Library/Preferences/ManagedInstalls SoftwareRepoURL ""

where is whatever your actual IP address is for the server Mac. For the sake of this demo, we're using http, but you may want to check out Using Munki With SSL Client Certificates or Using Basic Authentication for details on using https instead.

The Munki client should check in with the server every hour or so (not exactly an hour—there's a random bit of time tacked on so if you have a bunch of clients checking in at once, they're not clobbering the server together).

managedsoftwarecenter But you can also manually check for updates by going to Managed Software Center (in your Applications folder).

Return to top

Set up AutoPkgr

As we saw with the Firefox example above, you can manually import packages. There are, however, repositories for software that's pre-packaged and ready to work with Munki. These AutoPkgr repositories of cooked "recipes" can be especially helpful, for example, if you want to automatically push out updates to Flash and Java, and you don't want to deal with the promotion-ware Adobe and Oracle sometimes include in the installer.

You should already have AutoPkgr installed from a previous step, but here's a handy link in case you need to install it on your server Mac right now.

autopkgr01 When you launch up AutoPkgr the first time, you may be prompted for your password a couple of times. Go ahead and authenticate.

Once it's launched, it will have little red dots letting you know Git and AutoPkg are not installed. Go ahead and start with clicking Install Git.

autopkgr03 You'll see it download Git and then start installing Git. At a certain point, it may prompt you for your password. Go ahead and authenticate.

autopkgr04 Then click the Install AutoPkg.

autopkgr05 Same deal. Let it download and try to install. Authenticate, when prompted.

autopkgr07 Once they're both installed, you may want to change the other settings below. I like to check Launch AutoPkgr at login, for example. You may or may not want to hide in the Dock—your choice.

autopkgr08 There are a bunch of recipe repositories. If you're unsure where to start, just check the first one, and it will give you a good, basic selection of software. Obviously, the more repositories you check, the more software recipes you'll have available to you.

For this example, we're going to get the Oracle Java 8 package. For our purposes starting out, you'll need to check only the .munki recipes. You can leave the .download, .install, and .pkg recipes alone. Start by creating an override. Overrides allow you to specify other options without touching the original recipe, but they're also important for security (more on that later). autopkgr09a Then, go ahead and check the box next to your override.

Then, skip over Schedule for now, and go straight to Folders & Integration.

autopkgr11 AutoPkgr will just use what's grayed out, but if you want to change any of these directories for the integration piece, you may want to click Choose.

autopkgr12 Then you can choose your Munki repo.

autopkgr13 You'll see it's essentially the same except in black instead of gray.

Then go ahead and go to Schedule.

autopkgr14 Check both Run AutoPkg every 24 hours and Check for repo updates before each AutoPkg run.

N.B.: Please make sure you read AutoPkg and recipe parent trust info to get more information on a workflow for auditing changes to recipes.

autopkgr15 autopkgr16 It will run automatically in the background, but this first time, you may want to manually run both processes. Again, there may be a password authentication. Just roll with it.

autopkgr17 If everything worked, you should return to MunkiAdmin and see your OracleJava8 package in your Munki repo, ready to be added to a catalog and to a manifest (if you don't, click Reload).


Special thanks to Munki creator Greg Neagle for creating Munki but also for having a look this page and suggesting a couple of minor tweaks. Thanks also to the open source community surrounding Munki, AutoPkg, and another fun Mac-admin tools.

Create an auto-logoff script for Windows 7

One Use Case

I'm not really sure how useful this is to other folks, but we're in a primarily Mac environment and have a Windows computer joined to Active Directory that's handy to use for people's password changes.

Once people have changed their passwords... no need to be logged in any more, so this just logs people out shortly after they've changed their passwords.

You may, of course, find other uses for this, and you can adapt the script as necessary.

Create the script

Using Windows' Notepad (or another downloaded text editor like Notepad++), create a new document and paste this code in:

:: Don't display commands
@echo off

:: Display message to user
echo You will be logged out at the end of the countdown.
echo Close this window if you want to stay logged in.

:: Wait 10 seconds
timeout /t 10

:: Log out
shutdown /l

Save the file as autologout.bat on your desktop or someone else you can easily reference later.

Test the script

Now find the autologout.bat file you saved and double-click it. It should have a countdown and then log you out.

Move the script to the startup folder for every user

If the script worked, go to C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup

Then, copy or move your autologout.bat file to that new location.

It should now log people out 10 seconds after they log in.

Enable AirDrop on wired connections

AirDrop for wireless only by default


By default, Apple enables AirDrop only for wireless and not for wired connections. So if you'd like to enable AirDrop for wired connections, launch up the Terminal.app (which you can find in Applications > Utilities), and then paste in one of the following two commands.

Command for only the logged-in user

defaults write com.apple.NetworkBrowser BrowseAllInterfaces 1

Command for all users

sudo defaults write /Library/Preferences/com.apple.NetworkBrowser BrowseAllInterfaces 1

Refresh AirDrop

You may have some luck relaunching Finder, but I'd recommend rebooting your computer entirely, particularly if you're changing the setting for all users, and not just the logged-in one.

Cloning an image using Thunderbolt and Disk Utility

Why would you do this?

  • It's fast. Over Thunderbolt, cloning a roughly 30 GB (of used space) image takes only a few minutes.
  • Minimal additional cost. Sure, you probably paid money for your Macs, but this method uses only included software... and one US$40 cable.
  • No external media or extra setup. You don't have to network your computer, install additional software, or have an external hard drive. You can go straight from computer to computer with just a Thunderbolt cable.


  • Two Macs—one source, one target.
  • Rename the hard drive on the source Mac to something unique (don't call it Macintosh HD, which is the default). Easiest way to do this is to go to Finder > Preferences and then check or tick Hard Disks under Show these items on the desktop. Then, when you see the hard drive icon appear on your desktop, you can rename it.
  • A Thunderbolt cable.
  • The main hard drive partition of the source Mac must be equal to or lesser in size than the target Mac hard drive. For example, if you are imaging from 250 GB to 250 GB, that's okay; if you're imaging from 250 GB to 500 GB, that's also okay; but if you're imaging from 1 TB to 500 GB, that won't work.


Note: If you're using El Capitan (10.11) or later, the procedure has changed. More details at Cloning an image using Thunderbolt and Disk Utility (post–El Capitan)

The procedure below is for Yosemite (10.10) and earlier.

  1. lightningboltOn the target Mac, reboot the computer while holding down the T key on the keyboard to boot it into Target Disk mode. If you have done so successfully, you will see what appears to be a white lightning bolt on the screen.
  2. On the source Mac, reboot the computer while holding down the Cmd and R keys on the keyboard to boot into Recovery Mode.
  3. Then, connect the Thunderbolt cable to both Macs.
  4. On the source Mac, select Disk Utility from the available options.
  5. diskutility
    Once Disk Utility launches up, click on the main partition (the one you renamed earlier) of the source Mac. Since Disk Utility can sometimes load up the target Mac visibly higher or lower than the source Mac, it's critical that you have them uniquely named (that's why we renamed the drive earlier). So click on that unique name.
  6. Click Restore. You should see the source as the uniquely-named drive.
  7. Then drag the main partition of the target Mac over to the Destination area.
  8. Click Restore.
  9. That's it! Once it's done, you can boot your target Mac into regular mode, and it should be a clone of your source Mac.

Acer Monitor and Mac Computer

We had a bit of trouble at first getting some Acer K272HUL monitors to work with some Macs on campus, and Google searches came up with threads like this, which offered some helpful tips, but not a full solution.

So if you happen to have an Acer K272HUL (or perhaps a similar model) and some Mac desktops, you may find this post helpful.

Problem: We couldn’t get the Acer monitors to recognize our Mac computers (running Yosemite, though I’m not sure that made a difference) using HDMI cables. Then we tried using a MiniDisplayPort-to-DVI cable, and the Acer monitor recognized the connection but wouldn’t display at full resolution (we could get tiny resolution in the center of the screen or pixelated stretched resolution).

Solution: First, on the monitor, go to the settings and make sure the DP version is set to 1.1 and not 1.2.

Then get a MiniDisplayPort-to-DisplayPort connector.

That’s it. Full resolution.

Deleting Mac Keychains in an Active Directory Environment

Update: The easiest way to do this is actually to install Offset and then put a RemoveLastUserKeychains script into /usr/local/offset/logout-every (make sure it's owned by root:wheel and has 755 permissions).

What's the problem?

If you're in a primarily or exclusively Mac environment, but you're managing logins through Active Directory, password changes on the AD level confuse the local Macs, which will log you in just fine but will not know what to do with your previous login keychain.

One potential solution is to delete the keychains after a mandatory password change... or just at a regular interval. Here are two ways to do that.

Method #0: Use a Launch Agent

Go to Deleting keychains at user logout for the best way to do this.

Method #1: Use a Logout Hook

Why you might not want to use the logout hook

Apple deprecated the login/logout hooks as of Mac OS X 10.4 (Tiger), and—as of this writing—we're up to OS X 10.10 (Yosemite), and the hooks still work. In theory, though, Apple could yank support for the login/logout hooks at any time.

Credit where credit is due...

If you'd like to use a logout hook, this is what you do (credit to How to delete Keychains at logout for being the basis of these instructions).


Make a location for your script

Amsys recommends creating one special for your organization (they use /Library/amsys, and we would use /Library/siprep), so create one appropriate for your organization.

In the terminal, you can create that directory using this command:

sudo mkdir -p /Library/nameofyourorg

Make your script

To make the script, you can use the graphical text editor of your choice (e.g., TextWrangler or Sublime Text). If you prefer Mac OS X's built-in TextEdit, just be sure you're saving as plain text and not rich text format. Just remember, once you copy the script to /Library/nameofyourorg, that you need to change ownership of the file to root (owner) and wheel (group).

A simple way to use the terminal to make the script (and avoid having to change ownership of the file later) is to just use the built-in text editor, nano:

sudo nano /Library/nameofyourorg/CleanKeychain.sh

Then, paste in this code:

rm -Rf /Users/$1/Library/Keychains/*
exit 0

Then save (Control-X).

Amsys had $USER instead of $1, but I couldn't get the script to work unless I used $1.

Make the script executable

Whether you used a graphical text editor or a terminal based one, you'll still want to change the permissions on the file so anyone can execute it:

sudo chmod 755 /Library/nameofyourorg/CleanKeychain.sh

Add your script to the logout hook

To get the logout to invoke your script, use this command

sudo defaults write com.apple.loginwindow LogoutHook /Library/nameofyourorg/CleanKeychain.sh

Method #2: Use a Launch Daemon at boot time


This second method uses a Launch Daemon (which is not deprecated), but it also assumes you will reboot the machine from time to time (for example, if you have your machines scheduled to reboot every night or every weekend).

The advantage, of course, is that if Apple decides to no longer support the logout hook, this method will likely still work. The disadvantage is that this will work only when you reboot the machine and not every time a user logs out.

I haven't found a way to successfully create a launchd process that executes at logout (instead of just login). someone on Stack Exchange claims to have been able to do it, but I couldn't replicate those steps with success.

So what this does is, at boot time at a system level, just delete all user keychains.


Create the shell script

Similarly to the other method, we're going to create (if it doesn't already exist yet), a custom directory for your organization:

sudo mkdir -p /Library/nameofyourorg

Then make the script (again, you can do this in your favorite graphical text editor, move it over to the directory, and then change ownership to root user and wheel group, but this is a fairly straightforward way to do it one fell swoop without having to change ownership later):

sudo nano /Library/nameofyourorg/CleanKeychains.sh

In the text editor, paste in:


# Delete keychains for all users
rm -rf /Users/*/Library/Keychains/*

exit 0

Then save (Control-X).

Make it executable

sudo chmod +x /Library/nameofyourorg/CleanKeychains.sh

Create the Launch Daemon

You're going to create a custom .plist file

sudo nano /Library/LaunchDaemons/local.clean.keychain.plist

In the text editor, put in:

<plist version="1.0">

Save the file (Control-X) and reboot.