iPad Gmail Mail “password missing” error

This randomly happened after we set up a slew of iPads with the same email account (Gmail on Mail), and sending messages put the outgoing message into the Outbox with an error that the password is missing, with the options to Cancel or go to Settings. Going to Settings, though, offers no option to input a password.

You can see here other users frustrated with this problem:
GMAIL Accounts unusable after 8.3 update!

Some workarounds offered are to use the Gmail app or to add Gmail as an Exchange account (if you're using Google Apps and not a regular home Gmail account).

The workaround we employed was to double-click the home button, swipe away the Mail application, and then launch it up again. After a minute or so, there would be an error about the missing password again. This time, though, the prompt for Settings would take you to a screen to enter the password.

Very odd issue.

Munki error “ERROR: Adobe Setup error: 79: Unknown error”

I prepared a nice little Adobe Acrobat Pro package for Munki, and I tried to install it and got this error (ERROR: Adobe Setup error: 79: Unknown error).

Turns out, that isn't a Munki error at all:
Re: [munki-dev] CS6 package wont install > Adobe Setup Error: 79

It has to do with some processes running in the background that prevent the installation from going through. I rebooted my computer (didn't launch up any other programs), ran it again, and all was good.

sudo managedsoftwareupdate --installonly
Managed Software Update Tool
Copyright 2010-2014 The Munki Project

Performing preflight tasks...
Installing Adobe Acrobat X Pro (1 of 1)...
Mounting disk image Adobe Acrobat Professional X_Install-10.1.1.dmg...
Starting Adobe installer...
Completed payload 1 of 4 - Suite Shared Configuration CS6...
Completed payload 2 of 4 - Acrobat X Pro...
Completed payload 3 of 4 - CS6 Master Collection...
Completed payload 4 of 4 - Acrobat X Pro...
Performing postflight tasks...
I hope that helps someone out there.

Google Maps’ “an error occurred, your last action was reverted” import error

If you're importing a .csv (or .xlsx) file into a Google Maps map, you may have seen an error like an error occurred, your last action was reverted.

Unfortunately, there doesn't seem to be official word on all the situations under which that happens and what the estimated timeframe is for a full fix (even if the functionality isn't fixed, a more informative error message would certainly help).

Here are a couple of threads on the matter:
Creating New Layer in My Maps "An error occurred, your last action was reverted"
Error Importing Spreadsheet: "An Error occurred, your last action was reverted."

I don't know that this will work for all or even most situations, but we had this come up here once, and the issue was selecting too many address/location fields.

So, if you've had experience checking all the fields and it working, sometimes it does appear to work. Other times, if you check all the fields... importtogooglemaps01
... you may later get this error before the import finishes... importtogooglemaps02

In our particular situation, checking only the box with the location/address appeared to make the error go away (and make the import successful).

Enabling https for Apache server on Yosemite

I found a bunch of different instructions, but these are the instructions that actually worked for me (regular Mac running Apache server) to get https working (self-signed certificate, so you will get the certificate warning from your web browser):

Step 1

Self-signed SSL Certificate on Mac Yosemite

Step 2

Enable HTTPS in Apache on Mac Yosemite

Step 3

Step 2 gave me an error (AH00526: Syntax error on line 73 of /private/etc/apache2/extra/httpd-ssl.conf: SSLSessionCache: 'shmcb' session cache not supported (known names: ). Maybe you need to load the appropriate socache module (mod_socache_shmcb?).), so I edited the /private/etc/apache2/httpd-conf and followed these instructions.

Prevent a partition from mounting at boot time

Cheating a bit here, because I'm just linking to an excellent blog post on the procedure:
OS X Tip: Prevent a Volume From Mounting at Startup

It's very helpful if you've set up a Boot Camp dual-boot with Windows, and you don't want to have the Windows partition automatically mount when you boot into Mac OS X.

One working fix for “filter failed” printer message on a Mac

There seem to be several "working" (your mileage may vary) fixes for the "filter failed" message when you try to print on a Mac (may happen in Linux, too, since Mac uses CUPS for printing), and they all seem driver-related:
'Filter' failed error when printing from EPSON
Yosemite and a printer driver that broke

The one that fixed it for me was checking on another computer that's working fine with that printer and going to System Information > Printers to find out what the exact driver is that's used, and then deleting the printer from the computer having issues, and then re-adding it manually (not with a script) and manually selecting the correct driver.

Manually adding icons to Munki-imported packages

As with all Munki tutorials, this one assumes you already know some Munki basics. If you don't, you might want to start with Absolute beginner's guide to setting up Munki (not monkey).

When you use munkiimport to import software packages, it will either find icons automatically or prompt you to try to extract icons from the package. In some cases, the extraction doesn't work, and you may have to create an icon manually.

First, go into your munki_repo and then within the pkgsinfo subdirectory, find your package info. As an example, we'll use Inkscape. Open it up in a text editor (e.g., TextWrangler).

What we want from this is the name of the package (which may be different from the display name). The name here is Inkscape, so that's what we're going to call the .png file we create.

Alternate Method to Find Names: If you run

sudo managedsoftwareupdate -vvv
on your server on a client machine, you can see all the names of the .png files that did not download because of a 404 (not found) message. This may be quicker, actually.

Mac software packages usually have a .icns file for the icon, but Munki is looking for a .png, so we'll do a conversion.

On a computer that has installed the program you want (in this case, Inkscape), you want to run something like the following command:

sips -s format png /Applications/Inkscape.app/Contents/Resources/Inkscape.icns --out /Users/Shared/munki_repo/icons/Inkscape.png
If Inkscape is not installed on your Munki repository server, you can just output it to somewhere else temporarily and then put it in the munki_repo's icons folder later.

Then, if a user launches up Managed Software Center, she should see the new icon associated with the software package, instead of the generic placeholder.

Troubleshooting Suggestion: If your icons still aren't showing up, and you're 100% certain the name matches, the permissions may be wrong. I thought 644 on the icons directory content would be a enough (read/write for owner, read for everyone else), but I had to change it to 755 recursively to get all the icons to work, for some reason.

More details at the Munki Google Code page about icon guidelines.

Creating an installation package for a scheduled Adobe Remote Update Manager

This is kind of a dual-purpose Mac tutorial—how to automate Adobe Remote Update Manager and how to create an installation package using a point-and-click graphical interface.

Automating Adobe Remote Update Manager

You can find the Adobe Remote Update Manager on Adobe's Creative Suite Enterprise Deployment page. Just scroll down a bit until you find it.

When you launch up what appears to be an installer, it's not an installer at all. It's just a folder with a bunch of files in it.

For our purposes here, the only file that matters is RemoteUpdateManager. That is the actual executable binary that initiates the updates. You don't really need to install the RUM man(ual) page. If you want to find the update options (including how to use a proxy instead of getting updates directly from Adobe), you can find those on Adobe's website.

Remember where the RemoteUpdateManager file is. We'll need that file later.

Then create a text file called local.rum.plist and put in the following contents:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
<plist version="1.0">
<!-- <key>Day</key>
<integer>0</integer> -->
<!-- <key>Month</key>
<integer>0</integer> -->
You'll see that day, month, and weekday are commented out. You can uncomment those and pick a particular recurrence. Right now it's also set to run every day at 18:15 (or 6:15pm), but you can change those values as well.

The text file you just created is the launch daemon that will run the Adobe Remote Update Manager (RUM) once a day at 18:15 (or with whatever frequency you set up).

Creating the distributable package

If there are multiple machines you want to set this up for, you don't want to be manually copying files to two different locations on each computer. We're going to set it up so you can install a .pkg file on each computer, or distribute the .pkg file to each computer using something like Munki.

Apple provides its own official documentation on how to build a .pkg file. If you can use those instructions, good on you.

I found it much easier to use a program called Packages to do it the point-and-click way.

When you go to the Packages website, click the Download link.

Once you open the download, double-click Install Packages.pkg.

Click Continue.

After you read the agreement, click Continue again.

Click Agree.

Click Install.

Authenticate and then click Install Software.

Click Close.

Now that it's installed, go ahead and launch up the Packages program.

For this situation (Adobe RUM), we're just going to select Raw Package and then click Next.

Name your project accordingly.

By default, the project will be a subdirectory of your /Users/username folder, so you may want to pick a different directory. If you're fine with the default, just go with it.

In Settings you can change the Identifier to represent your actual company/school/organization instead.

Click on Payload and then select LaunchDaemons (under Library) and the plus sign below it to add to that folder (sorry—I accidentally cropped the plus sign out of this screenshot).

Then go find the RemoteUpdateManager binary you downloaded from Adobe earlier.

Click Add.

The default permissions should be fine here (644 or -rw-r--r--).

Click on Scripts (under /Library) and the plus sign below.

Then select your local.rum.plist file you created earlier.

Click Add.

These permissions should be fine. It just means any user will be able to run RemoteUpdateManager, which is fine. Only the script will probably run it, but there's no harm in the users being able to invoke it manually, too, if they want.

Go ahead and save the project.

Then click Build and select Build.

The project should build successfully (and fairly quickly).

Then you'll see your installer file in the directory you should earlier, under the subdirectory build. If you're using Munki to distribute, then you can do a munkiimport directly on this .pkg file.

Installing MunkiReport

What is MunkiReport

MunkiReport is a web-based reporting interface for Munki clients. It's cool to deploy a bunch of Munki clients, but it'd be nice to know how many are out there, and any errors or pending installs there may be on those clients.

If you haven't set up your Munki server yet, do that first!

Assumptions (for simplicity's sake)

There are many different possible scenarios for installing MunkiReport, but for simplicity's sake, we're going to make some assumptions. If you're really advanced, you can obviously adapt these instructions for your particular case. If not, follow as is.

  • You are using a Mac computer as a server.
  • You installed munki_repo to a subdirectory of the server directory.
  • You are going to install MunkiReport to the root directory of your web server.
  • You are going to do all of these instructions from your web server (and not from a client computer).

Making sure the web server is PHP-ready

Apparently, Mac OS X by default does not interpret PHP correctly when you launch up the Apache service. So let's make sure that's good first.

In the Terminal.app, edit the appropriate file using nano (or your editor of choice)

sudo nano -B /etc/apache2/httpd.conf
If you see a line that looks like this:
#LoadModule php5_module libexec/apache2/libphp5.so
change it to look like this instead
LoadModule php5_module libexec/apache2/libphp5.so
Then save out (if you're using nano, Control-X we save).

Then restart apache

sudo apachectl restart

A) Downloading MunkiReport with Git

If you have Git installed, you can do a git clone on MunkiReport.

cd ~/Downloads
git clone https://github.com/munkireport/munkireport-php.git munkireport-php-master

B) Downloading MunkiReport with a web browser

Using a web browser on the web server itself, go to the MunkiReport GitHub repository and click the Download ZIP button to download the latest version. When you get the .zip file, you may have to double-click it to unzip it. Once it's unzipped, you should have a folder with all the necessary files in it.

Installing MunkiReport

Copy the contents of the folder (not the folder itself) to your web server's root directory. Make sure the file ownership/permissions match that of the other files or folders in there (e.g., whatever index.html file says It works! when you first got your web server up and running.

If you no idea, then make it all 755 permissions with ownership of root:_www.

Here's an example to paste into the Terminal.app:

sudo chown -R root:_www ~/Downloads/munkireport-php-master/*
sudo chmod -R 775 ~/Downloads/munkireport-php-master/*
sudo mkdir -p /Library/WebServer/Documents/munkireport
sudo mv ~/Downloads/munkireport-php-master/* /Library/WebServer/Documents/munkireport/
sudo cp /Library/WebServer/Documents/munkireport/config_default.php /Library/WebServer/Documents/munkireport/config.php
The last command just makes a copy of the default config to a new custom config file. You will need both (I thought, at first, that I could ditch the default config file, but then I got an error when I loaded up the page in a browser).

Note: If you're using OS X Server, the path is typically /Library/Server/Web/Data/Sites/Default and not /Library/WebServer/Documents

If all went well, you should be able to go to http://localhost/munkireport and enter a first username and password. This doesn't actually create a user. All it does is create a hash.

Once you have the password hash created, highlight the results and then paste them in at the end of the config.php file on the web server. If you ever need to generate another hash again, go to http://localhost/index.php?/auth/generate and enter in more credentials.

When you do log in, you should see... nothing. No clients.

To create a client, paste these commands into the Terminal.app

bash -c "$(curl http://nameofyourdomain/munkireport/index.php?/install)" bash -i ~/Desktop
/usr/local/munki/munkiimport ~/Desktop/munkireport-2.11.0.pkg
Replace nameofyourdomain with your actual domain name or the server's IP address.

Note: if you're using https with a self-signed certificate, you may want to run

bash -c "$(curl -k https://nameofyourdomain/munkireport/index.php?/install)" bash -i ~/Desktop
instead of the first command.

Note: the version number may change, so after you type ~/Desktop/munkireport-, just hit Tab to autocomplete, instead of typing in the number (it's faster to autocomplete anyway).

Once you have that package imported, and have rebuilt your Munki catalogs when prompted, go ahead and them to the appropriate manifests so they can be pushed out to your existing clients.

If you are well-versed in MySQL and prefer that to MunkiReport's default sqlite database, read Using MySQL with MunkiReport for some implementation tips.