In OS X, installers are known as packages. The trend in OS X is to sign anything going onto a computer so that it can then be installed without concern that the product is not authentic. The productsign command provides the ability to sign packages in much the same way that the codesign command can be used on apps. For example, let’s say that we wanted to sign a package called Alpha.pkg in /tmp with Apple DeveloperID 31415926535897932384626 and have it result in a new package, Omega.pkg in the same directory. The command would be as follows:
productsign --sign 'Developer ID Installer: 31415926535897932384626'
You can also timestamp the signing by adding a –timestamp option or disable trusted timestamps with the –timestamp=none. You can also indicate a keychain using the –keychain option or –cert to indicate a certificate to embed in the archive. Once signed, you can then test the signing using the spctl command along with the –assess option. The –type option would also indicate a type of install, resulting in the following for Omega.pkg:
spctl --assess --type install /temp/Omega.pkg
krypted August 31st, 2012
Posted In: Mac OS X
10.8, codesign, Lion, Mac OS X, mountain lion, os x, productsign, sign packages
One of those annoying little things is when you ARD into a system and the Dock is nowhere to be seen. Why do we (or should I say they) autohide Docks on servers? Either way, when I ARD into a box and I don’t see a Dock I have this line saved as a Template:
defaults write com.apple.dock autohide -bool false; killall Dock
By writing an autohide key that is false into com.apple.dock for the currently logged in user, I don’t have to deal with the Dock disappearing any more. You need to kill the Dock and let it respawn, thus the killall as well.
Once I’m done working with the box, I can show the dock again:
defaults write com.apple.dock autohide -bool true; killall Dock
Or, instead of all this, as diskutant once pointed out, just use Command-Option-d when you ARD in and then again when you log out!
krypted August 30th, 2012
Posted In: Mac OS X
ARD, com.apple.Dock, defaults write, killall, killall dock, Mac OS X, Remote Desktop, template
For those that have had the pleasure of working with certain Windows-based laptops, there may be one particularly crazy-making design choice: the radio-disable switch. To paraphrase Seinfeld, what’s up with that? It’s a ‘feature’ (ahem) not utilized often enough to remind folks they have it, nor explained properly to the customer by the manufacturer. And it can drive IT support personnel nuts, as almost nobody in their right mind turns off wireless access voluntarily… yet it still happens from time to time, causing both sides to be confused for quite some time until they employ Occam’s Razor
. And there are various locations
it might be on the laptops, too, depending on the vendor and model.
Even on the shinier side of the aisle, sometimes the ‘service order’ as its called on Macs isn’t as we’d like it, especially in the age of USB or Thunderbolt ethernet adapters. Therefore an Apple laptop might look over a wireless network even when a live ethernet cable is plugged in. For myself, in the past I had relied on the order of icons in the top right of the menu bar, using keyboard shortcuts to navigate to the (formerly Airport) Wi-Fi icon to turn wireless off when I got to my desk, and on when leaving.
An item appeared on the Hacker News
recently which led me to revisiting my process, sourcing the same illustrious individual who compiled a list of ‘defaults write’ commands which was then dubbed “OSX for Hackers” on news.ycombinator.com (Hacker News). Feeding off the work of another gentleman from back before Lion, they purported to have found a dead-simple way to run scripts that look like application bundles. The comments on that announcement post are littered with folks looking for help, leading one MagerValp
to chime in on the Hacker News with “please use Platypus instead, it’ll save you a lot of trouble
Not one to ignore the word of Per, I looked into Platypus, which did exactly what I needed: I wrapped up two shell scripts that used networksetup, one to turn the power off and one to turn it on.
Now I can launch the ‘apps’ from Spotlight and control airport power, even without my laptop being fitted with an insanity-causing, havoc-wrecking hardware switch.
krypted August 29th, 2012
Posted In: Mac OS X
apps, GUI, Platypus, run shell script
I’ve been doing a number of postings on how to use various features of the latest version of OS X Server. Given that WordPress is pretty much a reverse chronological listing of articles I’ve written, I thought I’d put together a listing of the pages that I’ve done for OS X Server 10.8 (Mountain Lion Server) in order to offer a more pedagogically aligned way of reading these posts. As such, here is the Table of Contents for these posts:
Managing the Server
krypted August 28th, 2012
Posted In: Mac OS X Server, Mac Security
10.8, Lion, Mac OS X Server, mountain lion, mountain lion server, Notification Center, OS X Server, profile manager, Push Notification, snmp, Snow Leopard, time, upgrading, web modules
Yes, it’s about a month or two into the OS cycle and there’s now a 10.8.1. So it’s time to announce the name and image that will be used with the next OS. We’re down to Ocelot, Serval and Bobcat. Therefore, I would think that 10.9 will be… Drumroll…
Mac OS X 10.9 – Bobcat
BOBCAT! And from some Chinese factories I’ve been smuggled pictures of what the box that contains the disks will look like. It’s a little retro (disks are now retro btw). And I mean, Police Academy 2 era retro. But think of the startup sounds the OS could make. Think of how much people would want that face beaming back at them during the startup process. Just think of all the endless possibilities just in Police Academy 2 through 4! This is going to be an amazing year.
As proof, see the previous versions of OS X and their cats:
- Public Beta: Kodiak – September 2000 (still crawling Google Images looking for a picture of one of these)
- 10.0: Cheetah (March 2001)
- 10.1: Puma (September 2001)
- 10.2: Jaguar (August 2002)
- 10.3: Panther (October 2003)
- 10.4: Tiger (April 2005)
- 10.5: Leopard (October 2007)
- 10.6: Snow Leopard (August 2009)
- 10.7: Lion (July 2011)
- 10.8: Mountain Lion (July 2012)
- 10.9: Bobcat
Note: Since Puma and Cheetah were internal codenames, perhaps they’ll be recycled)
krypted August 27th, 2012
Posted In: Mac OS X
10.9, bobcat, Lion, Mac OS X, mountain lion, next os, Snow Leopard
I’ve mentioned the codesign tool in previous articles, but today let’s look at a specific use. I recently needed to generate a report of the executable for around 2000 app bundles. Luckily, codesign displays the executable for an app when run with the –display option:
codesign --display /Applications/Utilities/Terminal.app
The output looks as follows:
Another tool that I haven’t written much about is productsign (also in /usr/sbin of Mac OS X 10.8). I’ll look at that one next, as a means of signing packages.
krypted August 27th, 2012
Posted In: Mac OS X
app, codesign, executable, Mac OS X, package, productsign, programmatically determine, script
OS X Mountain Lion Server comes with the /usr/sbin/serverinfo command. The serverinfo command can be pretty useful when you’re looking to programmatically obtain information about the very basic state of an OS X Server.
The first option indicates whether the Server app has been downloaded from the app store, which is the –software option:
When used, this option reports the following if the Server.app can be found:
This system has server software installed.
Or if the software cannot be found, the following is indicated:
This system does NOT have server software installed.
The –productname option can be used to determine the name of the software app:
If you change the name of the app from Server then the serverinfo won’t work any longer, so the output should always be the following:
The –shortversion command returns the version of the Server app being used:
The output will not indicate a build number, but instead the version of the app on the computer the command is run on:
To see the build, use the –buildversion option:
The output shows the build of server, which doesn’t necessarily match the OS X build number:
Just because the Server app has been downloaded doesn’t mean the Server setup assistant has been run. To see if it has, use the –configured option:
The output indicates whether the system is running as a server or just has the app installed (e.g. if you’re using it to connect to another server:
This system has server software configured.
You can also output all of the information into a single, easy to script against property list using the –plist option:
The output is a list of each of the other options used:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
The Server Root can reside in a number of places. To see the path (useful when scripting commands that are relative to the ServerRoot:
By default, the output is as follows:
You can also see whether the system is running on actual hardware desgnated by Apple for servers using the –hardware option:
The output simply indicates if the hardware shipped with OS X Server on it from Apple:
This system is NOT running on server hardware.
The –perfmode option indicates whether or not the performance mode has been enabled, dedicating resources to binaries within the Server app:
If the performance mode has not been enabled then the output will be as such:
Server performance mode is NOT enabled.
To enable performance mode, you can also use serverinfo. This is the only task that the command does that can make any changes to the system and as such is the only time you need to elevate privileges:
sudo serverinfo --setperfmode 1
Finally, set the boolean value to 0 to disable.
sudo serverinfo --setperfmode 0
krypted August 25th, 2012
Posted In: Mac OS X Server, Mac Security, Mass Deployment, Xsan
10.8 Server, CLI, Command line, mac mini server, Mac OS X Server, macs, mountain lion, mountain lion server, programatic, programming, serverinfo
Next Page »
Apple’s not going to slow down innovation just to make me happy. I get that. But what have I noticed most about the differences between Mountain Lion and Mountain Lion Server and their predecessors, and maybe what to do to get some of them back?
- Podcast Producer: I am going to just put it out there. I liked Podcast Producer. I hope it shows back up in the future, even though I’m controlling my expectations. As someone who deals with a lot of video, there are a number of features that were really helpful to me, with or without Xgrid. I’ve replaced the command line aspects with tools such as ffmpeg, which we used in addition to at times, but some of the ways that pcastaction did things were really elegant comparably. On the graphical side, much of the functionality is available in the various sites that produce video streams and of course, there’s always YouTube. Either way, in regards to Mountain Lion Server, this represents one of the most substantial changes for those of us that deal with video.
- DHCP: I know, I know… I wrote an article on how to keep using DHCP. That doesn’t mean that the lack of GUI options is any less irritating. Every time I manually edit a config file that should have a GUI front-end it makes me ornery. Not that I’m not always ornery, but that’s not the point here…
- RSS: This is more of a client thing. But Mail.app and Safari used to give me the ability to quickly and easily look at RSS feeds and handled them in a way that was very streamlined with my experience across the rest of the operating system. I am now using more and more Google Reader along with tools like Reeder, but I liked the fact that everything I needed for RSS madness was installed on even the test systems I used
- X11: I know, I know… Use XQuartz. It was nice having it built in though…
- Web Sharing: I guess the answer here is to just buy OS X Server. You can still fire up the LaunchDaemon and use Apache, but it’s a bit of a challenge. And the version in Server isn’t identical to Apache in Mountain Lion. There are two ways I’ve handled this. The first is to install Mountain Lion Server and then use the command `webpromotion demote` to switch the Apache configuration back to that of a client computer. The second is to fire up the LaunchDaemon directly using launchctl. If you’d like, there are also a number of free and/or 3rd party web servers, such as MAMP.
- Negative Mode: Well, I covered this already, and while the keystroke was gone, the feature never was – but here’s how to fix. Also, @sacrilicious turned me on to nocturne, which is pretty cool as well!
- iCal, Address Book and NetBoot: Actually, they’re now called Calendar, Contacts and NetInstall respectively. But still there. I actually like the renaming a lot, so I guess I don’t really miss any of them.
- Radius: OK, it’s there. Just command line only (unless you’re using an Apple AirPort). Maybe I should write an article about radius…
- The Server command line options: Actually, they just moved to a relative path to /Applications/Server.app/Contents/ServerRoot, as I mentioned here.
- Server Admin: I was going to say FTP, then I remembered it’s back. And then I remembered I never missed it in the first place. But dropping the remainder of the GUI tools for servers represents a bit of a challenge, mostly in figuring out how to do a few of the minor things, like enabling Server Side File Tracking, etc.
krypted August 23rd, 2012
Posted In: Mac OS X, Mac OS X Server
10.8, Address Book, calendar, contacts, FTP, iCal, Mac OS X Server, mountain lion, mountain lion server, NetBoot, NetInstal, os x, Radius, what changed