Check the screen resolution from the command line.

About 2 years ago, Edward Marczak created screenrez. The goal was simply to offer a tool to OS X admins that would run on a remote client machine and report the screen resolution in use. Pretty handy, especially in scenarios where a projector is attached to the Mac in question.

The original version only supported one screen, which meant you were in good shape if the client machine’s displays were mirrored. I’ve just forked the project and added multiple screen support along with a little more detailed information, such as the screen’s device name.

You can download the tool here, or the package installer here. (Only tested on 10.8)

Advertisements

Tales of Woe From /var/log/system.log ~or~ Exited: Killed: 9

For those of us who have a bit of development experience on Apple’s iOS platform, we’re very aware of the fact that memory management can be a bit aggressive within your applications; ivars get garbage collected before you were done using them, etc. In iOS, you simply retain the object you wish for the garbage collector to ignore and the problem is no more. Well, now it seems OS X is starting to take extra notes from iOS, but so far, the only fix is to buy more RAM. (more…)

Gimp on OS X

Gimp on OS X

Just pure awesome coming from the GIMP project. September brought version 2.8.2 to OS X, which no longer requires X11 or XQuartz to run. OS X 10.8.0 or higher is required. So far I’m very impressed. Good job to all involved!

Sandboxing vs. LocalMCX

This is a (albeit late) follow up post to a conversation started over on MacEnterprise as well as the MunkiDev list.

If you use LocalMCX to manage machines, this post by Greg Neagle is probably very familiar to you. In it, Greg outlines some of the changes that came with dscl in Mountain Lion and how those changes affect Local MCX management. Basically, the changes were such that you could no longer use dscl or Workgroup Manager to create or modify MCX settings and groups in your custom (non-“Default”) node.

It turns out, we can still use those tools to edit and manage our custom nodes. The problem isn’t a rewrite of dscl to specifically reject custom local MCX nodes, as many of us suspected. It’s sandboxing.

So what changed? Mountain Lion is all about Sandboxing (which is a very good thing). Apple’s goal with its App Sandbox is to split applications into collections of binaries so that each of those binaries can be assigned only the permissions and resources that it needs to do its job. When Apple sandboxed opendirectoryd, they rightly gave it read/write access to /var/db/dslocal/nodes/Default and nothing else. This is actually very good news for us because sandbox permissions can be modified, meaning we can get Workgroup Manager to edit users/groups/etc directly in our custom node. Here’s how:

  1. Open /System/Library/Sandbox/Profiles/com.apple.opendirectoryd.sbin your favorite text editor
  2. Find the line referring to /var/db/dslocal/nodes/Default, should be line 43 (notice how this is under the allow file-write* container?)
  3. Insert a new line after that one with the following contents, making adjustments where needed for your local MCX path:
    #"^(/private)?/var/db/dslocal/nodes/MCX(/|$)"
    
  4. Reload the daemon, effectively forcing sandboxd to reload the permissions:
    killall opendirectoryd

Keep in mind, this only solves the problem of getting our favorite MCX editing tools back in our hands without the need to copy records back and forth between nodes, so it really wouldn’t make sense to push this out to all of your OS X client machines.

That’s it. You should now be able to use Workgroup Manager again to edit your local MCX settings, in place.

Disabling Automatic Updates on Mountain Lion

Here’s another “just so I don’t forget” script for OS X. This performs two tasks:

  1. Turn off auto updates
  2. Point Software Update to a custom SUS URL (I’m using reposado, but it should also apply to an Apple SUS).

The script supports OS X 10.6 (Snow Leopard) through 10.8 (Mountain Lion). (more…)

Checking for iPrint Objects With Missing PPDs

A few days ago I posted some notes about using iprntcmd to display some information about the print objects in your iPrint server. Today I’m going to talk about using iprntcmd to do a little sanity checking as well. If your institution is anything like mine, you’ve got pockets of Mac users and pockets of Windows users. They all need to print, and very seldom do they dare cross into each other’s realm. Generally this means that everyone is happy when it comes to printing. But from time to time, someone does cross into the opposing realm and discovers that they are unable to install a printer on their nice new Mac. (more…)

Installing IPP Printers With iPrint

This one is for anyone out there using iPrint clients and servers from Novell to deliver print services. Did you know the iPrint client (at least as of iPrint v5.0.0 as best I can tell) includes a command line utility called iprntcmd? Well, it does. And it comes so close to being truly useful. It will allow you to add and remove printers given nothing more than an ipp:// url, but alas, there is no functionality baked in to allow modification of a printer once it’s installed. What modifications am I looking for you ask? Well, ideally I’d be able to use this tool to install a printer and turn on duplexing by default. I know, I know, this should be done in the PPD stored on the server, but it’s just nice to have some flexibility, you know? On to business: (more…)

InstaDMG and Mountain Lion

This is mainly just a followup to derflounder’s excellent post on the same topic for 10.7. For the most part, the details on that page work perfectly for OS X 10.8, but I felt it was a good idea to update it just a little and basically repost it here. After all, Googling for this topic currently shows quite a few people specifically asking about InstaDMG and 10.8, but very few people answering. The reason there aren’t many answers? It’s really not that hard to do! (more…)