krypted.com

Tiny Deathstars of Foulness

When Lion was new, I put up a post about clearing out information on saved applications states. Saved application states are a new feature in Lion that remembers the screens that were open and where each was when you quit applications. The reason for that post was that those states were causing a few minor issues with applications. There are a few applications that the saving of application states is really awesome for. I think it will mostly be different for each persons workflow. Personally I like saving the state of Terminal, Safari and a few others. However, the state of some others can be a bit annoying for me. For example, Word. Luckily, you can control which applications have saved states and which do not. To do so, first find the application in ~/Library/Saved Application State. These usually are the bundleid of the application followed by .savedState. Using the bundleid (or whatever is listed if not the bundleid), you’ll then send a NSQuitAlwaysKeepWindows key to the defaults domain for that id with a boolean setting of true or false. For example, to disable the saved state for Microsoft Word: defaults write com.microsoft.word NSQuitAlwaysKeepsWindows -bool false To re-enable it, just send a true value into the same key: defaults write com.microsoft.word NSQuitAlwaysKeepsWindows -bool true

September 16th, 2011

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , , , , ,

If you run networksetup and do a -listallhardwareports in OS X Snow Leopard, you’ll see that the Hardware Port: for en0 (on an MBA at least, but you should get the point even if it’s a MacPro) is AirPort. If you run the same command in Lion, you’ll notice the the hardware port is now Wi-Fi. This change cascades to any commands like -listpreferredwirelessnetworks where the hardware port might get called on. For most of my scripts for assigning AirPort networks, etc I was able to mostly just find-and-replace AirPort for Wi-Fi, provided I didn’t use AirPort anywhere else (e.g.$AirPort, etc).

July 20th, 2011

Posted In: Mac OS X, Mass Deployment

Tags: , , , ,

In a previous article I showed how to get and install an SMIME certificate. Now let’s look at installing it into Mail. It’s really, really hard. First, open Mail. Then, click on the Mail menu and select Preferences. Then click on Accounts. Then click on the account you got an SMIME cert for. Then, in the TLS box, select the certificate you want to use. Next, go to compose a new message. You will see the little disclosure triangle to the left of the From dialog. Click on it and then check the box for the lock and the icon to the right of that, meant to look like a Beholder from Dungeons and Dragons. Beholders see well, so they can see if you’re the person who really is the person allowed to send the email. The lock encrypts email (provided you have a certificate for all recipients) and the eye of the beholder icon signs messages. Once you’re happy with your checkboxes, click on OK. Now, in your new email message, use the icons. Sign or encrypt. If you don’t have a certificate for a user, have them sign an email and send it to you. When you read their email you should then have their public key in your Keychain. Now, take your 100 sided dice and take the rest of the day off (after all, you just figured out how to make email more secure for your company). Also, you may notice that in these screens I’m using MobileMe certs. If you use the System Preferences pane to install MobileMe into your account then you’ll be greeted by the cert automatically being installed into your keychain for you. So for MobileMe users, you don’t even need to go get a 3rd party cert. I also use this on my work email, but didn’t want to put those screens in here (after all, I did misplace my tin hat and would hate to get hax0r’d by government goblins before I can track it down).

July 20th, 2011

Posted In: Mac OS X, Mac Security, MobileMe

Tags: , , , , , , , , ,

In OS X Lion, user libraries (~/Library) are hidden. If you want to make it visible, use chflags. To use chflags to hide a file, simply type chflags followed by hidden and then the folder. For example, let’s say you wanted to hide your ~/Library folder before you compiled a new copy of an operating system. Just run the following to hide it (or re-hide it once you provde you can unhide it): chflags hidden ~/Library And then let’s say you wanted to unhide it ’cause you realized that it’s one of those folders best left visible: chflags nohidden ~/Library You can also use the SetFile command (both are located in /usr/bin, although chflags is included by default whereas SetFile is installed with the OS X Developer Tools). SetFile has a -a option and can set the v or V attribute to make a file shown or hidden respectively. Run the following command to make this same folder invisible: SetFile -a V ~/Library Or the following to make it visible: SetFile -a v ~/Library Having said all this, if you’ve ever had a user trash their Library because “I didn’t put it there so I thought it should go away” then you might consider just leaving ~/Library as it was…

July 20th, 2011

Posted In: Mac OS X, Mass Deployment

Tags: , , ,

OK, by now I’m sure everyone has heard that OS X Server is a download off the App Store. For a whoppin’ $50 you get the OS that was once called “Open Source Made Easy” until someone at Apple realized that GPLv3 might mean that Open Source doesn’t always mean “free as in beer”. Wait, did I say that out loud? Point is, there are bigger changes here than just moving the server to the App Store. There are also some pretty big changes to the GUI of OS X Server. The first and most obvious is the LoginWindow, which is different in OS X in general. It obviously looks different. The ability to click on the items above the username and password is gone. You can still see indicators of green and orange in the username field to indicate directory service availability though, which was one of the bigger things we’ve used that for over the past few years. Once downloaded, the Server app will be in the /Applications directory, in Launchpad and useable. But the Server Admin tools are a separate (free) download from the Apple downloads page. This is a nice nickel and dime way of keeping the Server app small. Once installed, note that if you open About this Mac, the OS does reflect that you are running Mac OS X Server Lion (not OS X Server Lion btw for all you marketing nerds), so it is actually a registered different version of the operating system. Now open up Workgroup Manager. The Inspector option in Workgroup Manager is gone. Actually, this is kinda’ true. The option is greyed out in the Workgroup Manager prefs (com.apple.WorkgroupManager.plist) but easily enabled using defaults to add the -dict for “Application Preferences” with a key of “Show \”All Records\” Tab” set to a value of 1. But more importantly, there’s now a tool called the Directory Editor that is part of Directory Utility (still located at /System/Library/CoreServices). It looks a lot like the Inspector, but it’s a bit more appropriate for local stuff. Now open up Server Admin. Most of the services are gone. We’re left with nat (does anyone really still use OS X Server as a border device?!?!) and a few other services that were either too boring to get moved to the Server app or too unwanted. Expect these to disappear one by one if there are future releases of OS X Server. In fact, if OS X Server is $50 I’d say building a better DHCP (that maybe has a GUI for DHCP options and other cool stuff) or a better DNS is a worthy of a $10 or $20 app on the app store. After all, given the Mini platform it seems a decent platform as a network appliance in that fashion… But back to it. Now go into Server. Wow. Super easy. The only challenging thing in here is Profile Manager. And the only challenging thing about it is that it a) most people aren’t going to let it build Open Directory for them (but should) and b) some people are going to get stumped when asked for a username and password for a developer account. Get yourself an Apple ID with a developer cert and Profile Manager will be really easy to use, especially if you’re used to working with Workgroup Manager to build Managed Preference manifests. Once in, if you will even note that you can assign specific defaults domains and push keys to clients. Of course, the big thing here is the wipe. The most important thing to note about that is that the clients need to run FileVault and there’s not a great mass deploy strategy for that yet (IMHO). While I said Profile Manager could be challenging, there are some really cool things waiting for people to start hacking away at. The fist is scripting profile creation and management. Profiles are stored in /var/db/ConfigurationProfiles/Store. Much to the chagrin of 3rd party MDM developers, this solution works great for OS X and iOS. Much to the delight of MDM developers, the whole App Store look and feel that someone like JAMF has is still something that really sets them apart and the ability to have Casper assist you with managing those VPP keys is what will be the crazy huge value add that it will continue to bring to the table. Having said that, a lot of smaller organizations can now use Profile Manager where they might have just used iPhone Config Utility before. Profiles can be pushed out in a number of ways. The user can download it out of the goodness of their heart. In iOS you’re kinda’ stuck with that deployment methodology. But not in OS X. Help comes in the form of the profiles command, located in /usr/sbin. Profiles is explained further in this other post of mine here. The serveradmin app (serveradmin list shows a few less results than it used to), slap* commands and other tools server admins are used to are all still there. There’s a better webmail (much, much better), Wiki’s are a little different (not much), NFS (kinda’) and FTP are gone, Podcast Producer keeps getting easier, the twisted stuff (iCal and Address Book Server) is the same as it was in Snow Leopard and Server app gets more functional whereas Server Admin gets less functional. Server got a little easier. Or at least on the outside. But presumably it can, given that it’s likely to be asked to do less than it once was moving forward. But as with previous versions of OS X Server, there are a lot of settings under the hood that aren’t exposed in any app. Let’s look at the devicemgr service, which is Profile Manager in the GUI: sudo serveradmin settings devicemgr One thing I do find interesting is the inclusion of postgres in serveradmin but not in Server app or Server Admin. MySQL is gone, but postgres is there. You’ll also see settings like mdm_acl and user_timeout that can be pretty helpful (which is why they’re in there in the first place) but aren’t in the GUI. I’m all for keeping GUI’s clean, not giving admins the ability to easily enable something they shouldn’t and keeping away from having screens and screens of rolling settings. So for the most part I’m OK with this. My point with this paragraph (and every paragraph should have a point even though I forget that sometimes) is that if there’s a setting you need that you think got taken out or if there’s a setting that would be cool to have, check serveradmin settings and see if it’s there before just taking the Server app’s word for it…

July 20th, 2011

Posted In: Mac OS X Server

Tags: , , , , , , , , , , , , ,