Lately I’ve been thinking about the line between electronic management controls and company policy - should you have to go through the effort of locking down things like dropbox.com on a fleet of laptops? How will you control that when people are remote? How can you prevent people from using countless other services that are similar, but different enough that they aren’t explicitly blocked?

Or is the solution something else entirely? I submit that its a matter of company policy. As part of the employee handbook, there is generally a section regarding usage of electronic assets. In most cases, there is also a (possibly separate) IT policy. So instead of working really hard to prevent the usage of file syncing software/webapps (which is a losing battle), policy can simply outlaw it. In other words, nothing physically stops you from robbing a store, but if you do, you are definitely going...

I recently decided to upgrade my open source chef-server from 11.x to 12.x… Here’s what happened.

The Painful Journey

So, behind the scenes, running chef-server-ctl upgrade essentially does a knife backup from your old server, and then runs knife restore into your new server. That transfers all your nodes, clients, environments, users, etc over to the new DB. I personally experienced a few problems with this - the first time it transferred over all the objects, but left them empty. My attributes, run_lists, etc were all empty. So that wasn’t very useful. Looking back over the output of the upgrade, it looked like there were a bunch of errors during the migration.

Turns out there is some additional information besides what is on the upgrade page.

Instead of dealing with that, I decided to do a backup and restore it to the new chef server myself. I used knife cleanup to remove all my...

First of all, PLEASE use a tool like bender to do regular backups of your OS X Server services. It will backup your Open Directory configuration daily, and that can be a huge godsend if something goes wrong.

Open Directory is actually three different services wielded together. They are

1. OpenLDAP - for directory services, OD (Open Directory) actually uses a fairly standard OpenLDAP service. It has a few schema modifications, but other than that it is pretty vanilla!

2. Password Server - this is where your passwords and password policies live! Think of it like a black box. It gets backed up as well with bender, but there is not much you can try to do if it breaks (the mkpassdb command gives you a little bit of insight, but not much_.

3. Kerberos - for authentication/authorization/SSO type functionality. Again, this is actually a fairly standard install of kerberos. There may be a few...

Links to presentations are up - they can be found here.

My personal favorites are as follows -

• Packet Sniffing for Humans - Yoann Gini
• Performance Automation with Munki - Matt Hansen, Joshua D. Miller
• SUStenance via Resposado (and Friends) - Allister Banks
• Unix: Working the Command Line in OS X - Russell Poucher
• You Oughta Check Out AutoPkg (Video coming soon) - Greg Neagle
• Managing Mavericks’ FileVault 2 with fdesetup - Rich Trouton
• Automate Yourself Out of a Job - Graham Gilbert
• Extending OS X Management Systems with Scripting - Jeremy Reichman, Rich Trouton
• Beyond Thunderdome: Managing OS X without OS X - Pepijn Bruienne

Have you ever wanted to enforce password policies on local OS X users? Things like complexity, expiration, rotation, etc? Well you are in luck! On OS X, users are managed in a local Directory Service, and so you have the same tools on each client that you would use in OS X server if you were setting requirements for Open Directory Users - that is, dscl and pwpolicy.

While both are interesting, I’m going to talk about pwpolicy specifically!

man pwpolicy

Set user policy with

pwpolicy setpolicy

Read it back with

pwpolicy getpolicy
Warning: applying command to user <tprice>
Getting policy for tprice
usingHistory=4 requiresAlpha=1 maxFailedLoginAttempts=5 requiresNumeric=1 minChars=8

Similarly, if you want it to be global:

pwpolicy setglobalpolicy

Reads back with

pwpolicy getglobalpolicy
usingHistory=4

• Note that these are examples from my environment - if you go read policy...

There was recently a question on the MacEnterprise mailing list about embedding a clickable smb link into a Microsoft Word document, and it got me thinking - Word only sees fit to support 3 different types of URIs. Hyperlinks to other documents, links to web pages, and email addresses. But what If we want to include a link to a path in a fileshare? Whether that’s smb, afp, nfs, etc, Word does not support it. When I choose to link to a ‘web page’, Word mangles my URI to look like this:

file://localhost/smb/::fileshare.example.com

instead of the proper syntax as I typed it in (smb://fileshare.example.com)…
It assumes I meant to link to a document.

So, how to fix this? Well, it involves a bit more work than it should. First, create a html file that contains just a link to your URI:

<html>
<body>
<a href="smb://fileshare.example.com">example link</a>
</body>
</html>

Then, open up your...

Most developers cringe a bit when they first hear that. How are they going to work? How are they going to test code and experiment with new technologies without admin rights?

On the other hand, organizations like ours have hipaa and other security concerns - so giving any users admin privileges can be a problem! So how can we solve this?
Well, that’s where good software deployment comes in - everything they could need should be installable via some self-service mechanism (for me, that’s Munki!). Aside from that, tools like vagrant and VirtualBox (really any virtualization product) are a godsend. Why clutter up your host machine with random test software and toolkits when you can try them out in a virtual machine?

The journey to no admin is a hard one - it means IT really needs to be on top of things! But in the end, it can make things much more secure, easily repeatable, and even...

So I’ve mentioned in the past that I was struggling to integrate kitchen-cabinet with omnibus tools like chef (or chefdk). My old solution was to do this:

 def self.chef_check
    if File.exist?('/opt/chef')
      ENV['GEM_HOME'] = '/opt/chef/embedded/lib/ruby/gems/1.9.1'
    elsif File.exist?('C:\opscode\chef\\')
      ENV['GEM_HOME'] = 'C:\opscode\chef\embedded\lib\ruby\gems\1.9.1'
    elsif Gem::Specification.find_by_name('chef')
      ENV['GEM_HOME']
    else
      puts 'You don\'t appear to have chef installed.'
      puts 'Please install the gem or omnibus version - `gem install chef` or http://www.getchef.com/chef/install/'
      exit
    end
  end

Now, this allowed me not to step on any toes, but it did leave a little bit to be desired. If the user didn’t have chef installed, it wouldn’t go ahead and take care of it for them. It also did some strange things the the GEM_HOME...

So, for anyone deploying Microsoft Office for Mac (I hit this specifically with the 2011 version) - there is a strange bug that results in the volume license file not getting applied properly. This has happened before in the past, but the issues seem to have resurfaced with 14.4.1. It seems to happen in these two situations -

1. Office is installed and then updated to 14.4.1 while there are no users logged in.
2. Office is installed and then updated to 14.4.1 without any of the Office applications being opened between the initial install and the update.

When the user goes to launch one of the Office applications, they are prompted with a window like this one:

and they are unable to use Office normally. This screen should never appear if you are using a volume license installer! Thankfully the fix is pretty easy. If you have a mac that already has the license on it, you can grab the file...

Hey everyone, I gave a small presentation on Munki recently for the SDDevOps group! Here’s a link to the slideshow if anyone is interested!