Referencing a PHP variable by using another variable as part of the name

This is kind of a niche scenario, but when you Google making a variable from another variable php, most of the examples involve using a double dollar sign, which may not be what you want to do.

Yes, whenever possible, it makes sense to use arrays instead of weirdly-constructed variable names, but that may depend on the type of data you're working with and how it's stored in the (possibly legacy) database.

$variableaspartofname=1;
${'firstpartofname_'.$variableaspartofname.'_lastpartofname'}='whatevervalueyouwanttoassign';
That's it. If you do that, it will assign whatevervalueyouwanttoassign as the string value to a variable called $firstpartofname_1_lastpartofname.

Word 2016 in Windows printing embedded images zoomed in and cropped

One Windows user ran into an issue in which embedded images in a Word document would appear fine in the print preview but then would print zoomed in and cropped. In other words, the area on the printed document where the image should be is the same size as the image should be but only part of the image is printed inside that area but zoomed in and pixelated.

In this situation, saving to PDF would allow the user to print it properly.

Someone else online had a similar situation and was able to fix it by adjusting the dpi of the original images.

Turns out the fix was even easier than that: the documents had been created in an older version of Word, and they were saved as .doc files. Once the user saved them as .docx, everything printed just fine.

iTunes 12.8 on 10.13.6 not seeing iOS devices

If iTunes 12.8 on macOS High Sierra isn't seeing iOS devices, you may get a prompt to install software to see the iOS device, and then the installation may seem to take a while. For example, you may see this for a long time (over 20 minutes):

And even this might stay for a few minutes:

Once that's installed, it should work. If you don't see that prompt on one machine but do see it on another, you can grab the installer from /Library/Updates/041-14491 and install that manually.

iPhone cookie error when adding a Google account

If you are on iOS 12.0.1 and getting a you've reached this page because we have detected that cookies are disabled in your browser error message every time you try to add a Google account to Mail—and you're certain that cookies in Safari are indeed not blocked—update iOS (to 12.1, as of this writing), and that message will go away, and you can go ahead and add Google accounts.

Getting osTicket to schedule ticket creation from emails

If you go to Admin Panel > Emails > Settings > Incoming Emails, right now (as of release 1.10.4—the latest stable release as of this writing), you'll see something called Fetch on auto-cron, which isn't super useful, because it will fetch emails only if an agent is logged into osTicket.

There is an external scheduler option. Unfortunately (again, as of 1.10.4), that Using External Task Scheduler link is broken. I believe it's supposed to go to RECURRING TASKS SCHEDULER (CRON JOB).

There, you see on a *nix system, you're supposed to put in a cron job of

*/5 * * * * nobody /path/to/php /path/to/api/cron.php
but that didn't work for me on Ubuntu 16.04.5 (Xenial). If I ran the command
sudo /path/to/php /path/to/api/cron.php
manually, it would fetch the emails and create a ticket. And, even when a ticket wasn't automatically created, I could still see in /var/log/syslog the cron job actually having been run.

I even tried changing the user to root instead of nobody (but if you create a cron job using

sudo crontab -e
it runs as root anyway... not really sure what nobody is supposed to do there.

It didn't work until I substituted in this line instead:

5 * * * * /usr/bin/php /path/to/api/cron.php
Now, again, I don't really know what that nobody was supposed to do. According to the Ubuntu community docs, having the username in there is supposed to run it as that user, but when I had nobody or even root as the specified user, the command would run, but no ticket would be created.

I had to leave out the user altogether. Also, again according to the Ubuntu community docs, you should be able to put an */# in front of the four asterisks to run it every # minutes, but I found the command executed properly if I just put a single number in there.

Any cron job experts out there who can explain this, I'd love to learn more of the nuances of how this all works (or doesn't work)?

Getting up and running with InstallApplications

Erik Gomez did a presentation in 2017 on his InstallApplications project:
Macbrained SF Pinterest April 2017

Now that Apple's deprecating monolithic imaging, a lot of workflows have gone to DEP=>MDM=>something else (like Munki).

After doing some testing with InstallApplications, I think we're probably going to stick with our custom script workflow, but I didn't want our tinkering with it to be in vain, so hopefully some of these notes should help another school, org, or company that wants to get its feet wet with InstallApplications and may actually find it better suited for their situation than for ours.

This isn't a comprehensive guide on how to set up InstallApplications—just some implementation notes that may help people on a few of the things we got hung up on when trying it. For more comprehensive details on InstallApplications, check out the README for it and also this blog post: CUSTOM DEP - PART 9: A PRACTICAL EXAMPLE OF INSTALLAPPLICATIONS, CRYPT, DEPNOTIFY AND MUNKI.

You will need a signing certificate for InstallApplications.

The kind you want, though, can't be obtained by an admin. It has to be created by the Team Agent.

When you add a certificate, make sure you select macOS from the drop-down menu, and then select Developer ID.

Then select Developer ID Installer

Once you go through the steps of setting up the certificate, you should have a certificate on your Mac to import into your Keychain. Import it into your login (not system) keychain.

Then, make a note of this part: Developer ID Installer: YOURDEVELOPERDESCRIPTION (AWHOLEBUNCHOFSTUFF). You'll use that later in the build-info.json file.

When you download the project from GitHub (or git clone it), you'll see a bunch of files and folders.

For the simplest set up, the only things you'll modify are build-info.json and com.erikng.installapplications.plist.

The generatejson.py file you'll use to generate a .json to put on a server somewhere (or build into your package).

When you run munkipkg on the InstallApplications project folder, you'll get a .pkg in the build folder, which you can upload to your MDM.

Special note to other Mosyle users out there—don't be silly like me and forget to check the checkbox after you upload your InstallApplications .pkg file.

Hat tip to jacobfgrant on the Mac Admins Slack for telling me the minimal files to modify.

MathType formulas shrink after editing and saving them in Microsoft Word

March 2019 Update: WIRIS has now announced a workaround for randomly resized equations. I don't know for sure that that's exactly the same problem as the shrinking formulas, but it could be. Definitely worth checking out if you're experiencing this issue.

One teacher had an issue in MathType that involved saved formulas in a Word doc shrinking after editing and saving them again (even if the edit involved no actual changes).

The weird thing is that we tried with another user on the same machine with the same document and couldn't replicate the behavior, so it seemed to be tied to the user profile, but then later, with a fresh user profile, the issue still seemed to persist. So maybe that was a weird anomaly (it not shrinking)?

I did a bit more digging and Googling and came across this answer from WIRIS:

This is an issue with Retina displays, so that's one possible workaround: if you have a non-Retina display, use that when inserting or editing equations. The equations will be fine if merely viewed or printed when using a Retina display, but when you insert or edit one is when the sizing issue happens.

As Charles suggested in an earlier reply, "Consider reverting to Version 16.15." This is, in fact, Microsoft's recommendation as well. The answer on an earlier question in the Microsoft Community answers forum describes how to do that.

"[F]ine if merely viewed or printed" means, as far as I can tell, if you have already existing formulas that haven't been edited.

We tried reverting to 16.15, and that seemed to fix the issue.

For Munki users trying to downgrade Word to address this particular MathType issue, this is what worked for us:

  • Import Word 2016 (version 16.15).
  • Get the installs array of the binary at /Applications/Microsoft Word/Contents/MacOS/Microsoft Word, and put that in the pkginfo.
  • Modify the pkginfo to also change the version to be higher than 16.16. For us, 16.16.18091015 was sufficient for the change to take hold.
  • Create a new catalog called mathtype, and make that the only catalog for this pkginfo.
  • Put in a preinstall_script that checks for the existence of /Applications/Microsoft Word, and deletes it if necessary. If you don't do this, Munki will install 16.15, but it won't actually replace 16.16.
  • Add the mathtype catalog to the relevant manifest(s) you want to have this downgraded version of Word. Put this catalog before production, testing, or any of the other regular catalogs you have (more details on why).

Example of the preinstall_script:

#!/bin/bash

# Doesn't work if the newer version is already there, so delete it
existing_word='/Applications/Microsoft Word.app'

if [[ -a "$existing_word" ]]; then

/bin/rm "$existing_word"

fi

This downgrade procedure is modeled after the general approach to downgrading via Munki, outlined on the wiki.

P.S. The shrinking MathType formula problem persists in Word 16.17 (Word 2019).

Using Santa to block macOS upgrades

In the past, I'd used the fake installer approach to stop users from upgrading to the newest macOS version.

But with macOS 10.14 (Mojave), I started blocking using Santa (see Using Santa to block an .app for more details on general Santa use). It's likely this Santa-blocking approach also works for High Sierra and Sierra as well—I just haven't tested it on those.

Just download Mojave to your Mac, and then run

santactl fileinfo /Applications/Install\ macOS\ Mojave.app --key SHA-256
to get the hash to block.

Then run a modified version of this command (substituting in the actual SHA-256 hash for the placeholder) to add it to the Santa blacklist:

/usr/local/bin/santactl rule --blacklist --sha256 "actuallonghashyougotfromthepreviouscommand"

We were able to test this on two Mojave installers downloaded using two separate Apple IDs, so the binary seems to be the same regardless of which Apple ID is used to download it.

If a user then tries to run the Mojave installer, she or he will see a message like this:

Again, since it's based on the binary (and since you don't want to block by Apple certificate—which you may not be able to do anyway with Santa?—so you have to block by binary), you would have to create a new rule for every new macOS installer that comes out (10.14, 10.14.1, 10.14.2, 10.14.3... 10.15, 10.15.1... 10.16... and so on).

Special Note

Thanks to @elios (on Mac Admins Slack) for pointing out that this probably would not block the startosinstall binary from running. I was able to test and verify blocking the .app binary does not, in fact, block the startosinstall binary from running.

Also, by default, Santa will get the binary for InstallAssistant_springboard. If you want to be super aggressive, you might also want to block the InstallAssistant and InstallAssistant_plain binaries. Otherwise, the user can still run those two to get the GUI assistant to launch up.

So you really have to ask yourself how aggressively you want to block Mojave. Are you preventing users from just accidentally upgrading? Or do you want to prevent from upgrading even the most determined users who have admin privileges?

If you want to block startosinstall as well, you can do that. Just find (and subsequently block) the SHA-256 hash it:

santactl fileinfo /Applications/Install\ macOS\ Mojave.app/Contents/Resources/startosinstall --key SHA-256
santactl rule --blacklist --sha256 "actuallonghashyougotfromthepreviouscommand"
One advantage you get from not blocking startosinstall is that you can still block users from double-clicking to install Mojave but not have Santa try to block Munki from installing Mojave, even if you have the InstallAssistant_springboard blocked.

If you block startosinstall, then try to install the upgrade with Munki, you'll see it mount the .dmg, then stop. The log entries will look something like this:

### Beginning os installer session ###
Starting macOS upgrade...
Mounting disk image Install macOS Mojave-10.14.2.dmg
[Errno 1] Operation not permitted
Starting macOS install failed with return code 1
ERROR: ------------------------------------------------------------------------------
ERROR: [Errno 1] Operation not permitted
ERROR: ------------------------------------------------------------------------------
ERROR: Error starting macOS install: startosinstall failed with return code 1
### Ending os installer session ###

Activating Geometer’s Sketchpad in macOS 10.13.6 (and beyond?)

In Licensing GSP Deployments by Terminal Command , I covered the officially sanctioned way to license GSP5 for Macs.

I believe that was still working even as of 10.13.5. It certainly was working in 10.12.

Unfortunately, with 10.13.6—unless you had an already activated GSP when you upgraded to 10.13.6 from 10.13.5 or earlier—you might get error messages like

usage: Sketchpad_Executable -license (register | deregister) -name LicenseName -code AuthorizationCode
in the terminal or like in the GUI, even if you're using an admin account.

So I opened a ticket with McGraw Hill, and they said:

The license for all users is stored in the "/Library/Application Support/The Geometer's Sketchpad/" so it must be a permissions issue with that folder, either creating it for a new install, or accessing it when deregistering an old install.

If you copy the "The Geometer's Sketchpad" folder for a non-admin user install (which would be found in "~/Application Support/The Geometer's Sketchpad", to the global /Library/Application Support/ folder, that should also work, provided that the folder permissions allow read/write.

Lo and behold, that was the the old non-sanctioned, unofficial way I used to license GSP5 on Macs.

Tested it out on 10.13.6. Works!

So, yeah, use the old way until McGraw Hill figures out what's going on.