Friday, 8 December 2017

When certificates don't certify

I’ve spent the last few days trying to fix a pretty weird munki problem on a computer i manage. Turns out it wasn’t a munki problem at all. It all boiled down to certificates.

The munki server runs over https. This environment has a home-baked PKI with a root certificate and an intermediate cert, which has signed the munki server’s cert. The root and intermediate certificates are nicely tucked in to the computers System keychain and the Mac is set to Always Trust the Root CA. All should be fine.

But while i could surf to my munki server with a browser or with curl, i could not get managedsoftwareupdate to work.

Instead of steaming off with what i tried and what didn’t work, i’ll just tell that a clue to why it didn’t. I was not able to sudo curl https://munki.server.

Turns out that the Root CA, even though it was in the System keychain, was only trusted by the currently logged in user. So i removed the Root CA from the System keychain, added it again from the command line:

% sudo security add-trusted-certificate -d -r trustRoot \ 
-l /Library/Keychains/System.keychain path/to/ca.cert.pem

(Adding it from the GUI didn’t, somehow, help).

Et voilà, managedsoftwareupdate works again.

And i now think i know why. I believe i might have imported the root and intermediate certificates by dragging them into my login keychain using the Keychain Access app, then realising they were in the wrong spot, and drag-and-dropping them into the System keychain. That would explain how a cert in the System keychain, which should be available for the whole system, was only available for $me.

Silly $me.

Thursday, 19 January 2017

Validating your Munki manifests and pkgsinfos

Sometimes, bad things happen to your .plist files. Thus, it is prudent to run the following check on your Munki repo before deploying into production:

find {manifests,pkgsinfo} -type f -exec xmllint --output /dev/null {} \;

This will find all the files under the manifests and pkgsifo directories, check them for well-formedness (but not content; you might still have a typo in what you actually want to say!), and report only on the errors.

The output is sent to /dev/null, as xmllint would otherwise spew out all valid plist files to the terminal, effectively hiding any problems you might have had. A --quiet|-q option would have been cleaner...

Wednesday, 23 November 2016

Things i'd like to learn as a sysadmin

These are (some of) the technologies i'd like to be proficient in, as a Mac sysadmin:

  • imagr
  • autodmg and other ways to create images
  • ...and packages
  • munki + git + autopkg + some kind of CI for linting and deployment
  • puppet + gitlab-ci + linting + deployment
  • ansible + gitlab-ci + linting + deployment
  • esxi + ansible (+ ci for linting)
  • santa
  • crypt2
  • lokgging, monitoring and alerting with TICK, ELK + topbeat, osquery and/or sensu
  • mdm (micromdm)
  • profiles
  • mcollective
  • sensu + puppet
  • docker
  • clever and useful dashboards
  • reposado

I use many of these technologies at work, but i still feel like i'm an inproficient hack with most of them. And as a sysadmin, i really like to know what i'm doing.

Tuesday, 21 June 2016

Changing your network password on OS X Server

Macs often a local account to log on to their computers, even in a business environment (which may come as a chock to Windows admins). Changing the local password is just System Preferences → Users & Groups → Change password. This also works nicely if the Macs authenticate to a network server (or tends to). But to change the password of one's network account when the computer is not tied to a domain or an LDAP server, things get a little different.

As a user, go to the web page of your server (more specifically, the Mac server, running Open Directory -- hereafter just called The Server). If the sysadmin has done the job well, there should be fairly generic page coming up with links to a My Documents, All Activity, Wikis and People ... and at the bottom of the page, a link to Change Password. Click it. Authenticate, if needed, and change your password. Easy, if not altogether obvious.

Now if you are the sysadmin, things are yet more complicated. First, your server should have an SSL certificate. You should probably enable the Wikis service from the Server.app, if for no other reason that It Works On My Computer (we did that for the sole purpose of having a shared team calendar!). Now enable the Websites service. Double-click the bit that says Server Website (SSL) and check ☑ Allow users to change their password. Yeah, i admit it is well hidden. And now, users can change their network password! Woo-hoo!

Thursday, 19 May 2016

Removing unnecessary Puppet reports

A Puppet server i'm managing was running out of disk space and the culprit turned out to be Puppet's rather verbose report files. I had a whole bunch of reports which simply informed that the following umpteen files were not changed at all. This is both useless and wasteful, at 38 megs a report, per server, twice an hour. Even though the environment is small, i ended up with 22 gigs of reports...

After much googling and stackoverflowing, i came up with the following script:

#!/bin/bash grep -Pzl "status: unchanged(\n)metrics" /opt/puppetlabs/server/data/puppetserver/reports/*/*.yaml > $(dirname $0)/unchanged-reports # this is one long line, not four while read p; do sed '/metrics:/,$d' $p > ${p}.0 rm $p mv ${p}.0 $p done < $(dirname 0)/unchanged-reports

Run as root. Comment out the rm and mv bits if you're nervous or you just want to experiment.

The command line switches for grep (only work on GNU Grep, ie on Linux):

P turns on experimental Perl regexp mode and can potentially break things
z will effectively allow for multiline regexp patterns
l will return the file name where the pattern was found rather than the pattern itself

And then you can automate this, say, with cron.

In addition to this script, i use logrotate to compress and eventually remove old report files.

Sunday, 15 May 2016

Mac tip: what's eating your net

Mac command line tip of the day:

nettop

...and then press c and d.

This will show you which programs (or more to the point, processes) use your network connection and how much. c collapsed the rows so you don't get one line per connection (you can get back to the expanded view by pressing e). “Delta mode” d would show you how much network capacity each program (or connection, if you're in expanded view) is using right now and pressing d again will take you to showing the total amount of traffic transported.

If you want to get geeky, you can toggle p to see the number of bytes transported rather than the more human readable so and so many megs or gigs.

Use the arrow keys to scroll to the sides for more statistics (use j to select which stats to display) and up-and-down if you have a really large number of programs on the list, or are watching the expanded view.

Finally, h will bring you the help screen so you don't have to remember all the keys i just wrote about :D

Tuesday, 21 July 2015

How to get the IP address of a Mac

Every time you connect a new network adapter to a Mac, you get a new Ethernet device configured to your computer. This is of both logical and expected, but it means that you can't really tell what the name of your currently active network interface is. This makes things like checking your IP address a bit cumbersome.

And here's a shell script to remedy:


#!/bin/bash
interface=$(route get default| awk '/interface: / {print $2}')
ipconfig getifaddr $interface

This will only return the IP address of your default NIC. If you have more than one active network interface, you'll have to take the long route :)