I’d like to give a big thanks to Watchman Monitoring for becoming the second sponsor of krypted.com. I like the fact that thus far, I’ve managed to keep all sponsorship talks within the Mac Admin community and hope this is a trend I can continue as time goes on. I also like the fact that it’s all products that I believe in! Watchman provides an excellent service, and if you haven’t had a chance to check it out then I encourage you to do so!
As you may have noticed, we’ve been working on building some links between the App Store and patch management tools such as Casper, FileWave and Munki. We’ve been looking at policy-based management of apps as well. In this semi-new world of signing and stores and the such, there’s actually a good bit you can ascertain about an app both inside the app as well as inside metadata OS X keeps about the app. I’ve discussed signing (apps and packages) in the past, but let’s look at using some commands to help us out with some tasks.
The first command is to determine some information about apps that are on the computer. Spotlight keeps a fair amount of information about these apps and can be invoked using the mdls command. Running the command with no additional parameters looks like this (I’m gonna’ use iMovie in these examples, although note that there are spaces in a lot of app names and paths as you start scripting things – so use IFS rather than trying to use traditional array):
mdls /Applications/iMovie.app
This results in output similar to the following (I’ve stripped out a few fields as they consume a lot of space and aren’t super pertinent to what I’m trying to do here):
kMDItemAlternateNames = (
"iMovie.app"
)
kMDItemAppStoreCategory = "Video"
kMDItemAppStoreCategoryType = "public.app-category.video"
kMDItemCFBundleIdentifier = "com.apple.iMovieApp"
kMDItemContentCreationDate = 2011-09-28 08:04:34 +0000
kMDItemContentModificationDate = 2012-09-22 02:13:45 +0000
kMDItemContentType = "com.apple.application-bundle"
kMDItemDisplayName = "iMovie"
kMDItemExecutableArchitectures = (
i386
)
kMDItemFSContentChangeDate = 2012-09-22 02:13:45 +0000
kMDItemFSCreationDate = 2011-09-28 08:04:34 +0000
kMDItemVersion = "9.0.8"
To just ask for one of these attributes, run the command along with the -name option in addition to the metadata attribute you’d like returned. For example, to see the bundle ID (kMDItemCFBundleIdentifier), use:
mdls /Applications/iMovie.app -name kMDItemCFBundleIdentifier /Applications/iMovie.app
Now, if you’d like to just quickly ascertain what apps on the system came from the App Store, use the mdfind command, along with whatever of the attributes matches what you want to know. Running mdfind for kMDItemAppStoreHasReceipt of 1 would look like the following and would result in a list of all apps on the system that came from the App Store:
mdfind kMDItemAppStoreHasReceipt=1
Blacklisting all apps that are part of a specific category (and with regard to customer requests, that category seems to always be Games) is something we get a lot of banter about with customers. To determine this information for apps, you can run mdfind on kMDItemAppStoreCategory for Games:
mdfind kMDItemAppStoreCategory=Games
You could then dump the contents of those into something that can blacklist apps (or whitelist based on other categories). Now, version control is another hot topic at various organizations. To see the version type of a given app, use the -name option with mdls kMDItemVersion
mdls /Applications/iMovie.app -name kMDItemVersion /Applications/iMovie.app
Then you can track the version of the app and take action through other ways to remove old versions and force users to upgrade. The mdfind command can also be leveraged to find apps that have escaped their traditional homes of /Applications and /Applications/Utilities, with the ability to obtain a full list by querying for kMDItemContentType of app bundles, as follows:
mdfind kMDItemContentType="com.apple.application-bundle"
Loading a list of apps (output from `mdfind kMDItemAppStoreHasReceipt=1` or `mdfind kMDItemAppStoreCategory=Games`) into an array and then querying each one of them for more information is pretty trivial beyond the steps we’ve already taken. This information can then be fed into some kind of Managed Prefs script to deny or allow access to various objects or an admin could even chmod the bundle, mark it as invisible, poison it (keep in mind, if you alter it you’ll break the signing), etc in order to get some desired outcome.
You can also use defaults to read a users com.apple.storeagent.plist file for the AppleID field to see what AppleID is currently logged into the AppStore, providing another variable that can be reported on:
defaults read /Users/cedge/Library/Preferences/com.apple.storeagent.plist AppleID
And yes, it’s worth noting that users from another account or a system image, etc can be used to download apps so this one isn’t exactly certain but the purchaser isn’t stored anywhere within the bundle nor is it permissioned in a way that we can use to find the purchaser that way.
There’s still a bit of a gap right now with regards to some of these technologies that Mac SysAdmins are managing. The consumeristic technologies such as App Stores are here to stay. We’re kidding ourselves if we think that we won’t be able to buy certain apps via Volume Licenses and have pkg installers for too much longer. Apple has made no indication that they’re dropping the results that can be obtained with a simple installer command, but with forcing signing on certain objects, gatekeeper and other technologies it’s hard to say what the future will really have in store for us. Getting to a point where we can report on elements of the App Store and hopefully eventually deploy objects through the App Store should continue to help bridge these factors, but I still see the need for additional binaries from Apple to be introduced to get the rest of the way there (or at least expose a method to me so I can go in there and buy an app through the method).
I love college football. Anyone who knows me, probably knows what I’m doing about this time on a Saturday. And while I hail from the SEC, went to Georgia and have always loved “old man style” football, I’ve also lived in Southern California and now in Minneapolis where I’ve gotten to enjoy Pac 12 and Big 10 football. Doing work at Big 12 and Big East schools has also led to me attending many a game in many a stadium. I’ve also always loved watching teams that just plain suck or teams that no one has ever heard of. They have more heart than an entire division of NFL teams combined. In short, I’ll watch pretty much any football, any time.
In my travels, I’ve come across many a team who have names that just make me wonder what in tarnation they were thinkin’. So I’ve compiled a list on this beautiful college football Saturday. Here goes:
Runner ups, dropping out of the top 25 for one reason or another: Black Flies, Pomona Sagehens (The Huns was an awesome name), Gorlocks (named from Gore and Lockwood, two streets that intersect, their mascot is actually a cheetah/buffalo/St Bernard mix that would make Napoleon Dynamite totally jealous), the NYU Violets, the University of New England Nor’easters, Chaparrals, Chanticleers, Lemmings, Poets, Squirrels, Thundering Herd (I’m guessing the only Buffalo in Huntington West Virginia is the Buffalo Wild Wings on 4th), Ladies and Gents, University of Delaware Blue Hens, Student Princes, the Hustlin’ Quakers of Earlham College, Sooners (I picked on the Big 12 too much already), Tulsa’s Golden Hurricane, the Zips, the Lutes (no really, another Christian school, too), Shockers (whoever thought up WuShock was certainly struck by lightning), Terrapins (ya, nothing says we average 8 days for a 40 yard dash like the Terps), the Boilermakers (I picked on the Big 10 too much already), the Green Terror, the Keelhaulers, the Gamecocks (the baseball caps they sell at the campus store just say COCKS), the Bridges (I guess it is Brooklyn after all), the Fighting Koalas, the South Dakota School of Mines HardRockers (didn’t they beat Minnesota a couple of years ago along with everyone else in the Dakotas?!?!), the Lord Jeffs (srsly?), the Okras (okra scares the crap out of me) and of course, any team with a Swallow for a mascot (college, pro, etc).
Note: I’ve tried to leave out any teams named after Native American tribes.
Now that I’ve probably managed to offend pretty much every sports fan, I’ll tell you that I love these names. I didn’t call this article the “25 Dumbest Names for College Teams” or the “25 Stupidest Names in College Sports.” There’s a reason for that. I love all these teams. And honestly, it would seem somewhat trite for most of these teams to be called the Bulldogs, the Falcons, the Braves, the Hawks, the Thrashers, the Georgia Southern Eagles, the Valdosta State Blazers or the Mercer Bears. But if you’ve had a name for decades then you kinda’ stick with it, trite, silly or awesome. Now, let’s go get some Fighting Pickles tats!
There are four ways to create groups in Mountain Lion Server. The first is using the Server app, the second is using Workgroup Manager, the third is using the Users & Groups System Preference pane and the fourth is using the command line. In this article we will look at creating groups in the Server app.
Once a server has been an Open Directory Master all user and group accounts created will be in the Local Network Group when created in Server app. Before that, all user and group objects are stored locally when created in Server app. Once promoted to an Open Directory server, local groups must be created in Workgroup Manager, the Users & Groups System Preference pane or using a command line tool appropriate for group management.
Once changes have been made, click Done to commit the changes.
Mountain Lion comes with a number of changes. One of these is the fact that the checkbox to configure Versions histories in Time Machine is now gone. Honestly, I don’t think that many people used this kind of thing anyway, but it’s worth noting that in
Archive