Sunday, 25 February 2018

Monday, 12 February 2018

Licensing a vmWare vCenter Server

I’m not particularly fond of managing vmWare products. First of all, their product names confuse the heck out of me. The hypervisor ESXi Server is called vSphere and the server to manage vSpheres is vCenter. Second, they have five ways of managing them (possibly more, i’ve lost count by now)

  • Hard core: ssh straight into the esxi server
  • Weird core: use PowerShell from my laptop (which i haven’t dared install, since it’s a Mac)
  • The native client, which isn’t available on a Mac
  • The HTML5 UI, which is missing some features (but won’t tell which)
  • The Flash UI – yes, Flash! – which has more features than the HTML5 UI but requires Flash.

To install a license on the vCenter Server, you will need to use the Flash UI. But you don’t need to install Flash, thank you Google, because you can use the Chrome browser.

Open the Chrome browser settings (⌘,) and enter Flash in the filter box. Your UI will probably say Ask first , which you should click on. If it isn’t on Ask first, set it to Ask first. You can disable Flash later and then find this article once you need it again. Now Add the URL to your vCenter server in the Allow section. This may or may not do you any good, if the certificate for your vCenter server is valid or not. But at least do it as a reminder for yourself why you’ve enabled Flash.

Now go to the web UI of your vCenter server. It’s there on (or wherever you installed it). Start the Web Client (Flash) and log in. If your certificate isn’t pki compliant (which is a fancy way of saying you’ve been out-confused by vmWare’s certificate maze), a small warning will flash (ha!) by at the right edge of your address bar, asking whether you want to allow Flash to run on this site. Click (quick!) to allow – even though you allowed it in the settings. Yeah, i know.

Once inside the flashy UI, hover over the button with a house and a hamburger menu (🏠≡) and select Administration. Then click Licensing > Licenses (This is why you need the Flash UI; Licensing is not available on the HTML UI, at least not today).

Click the Licenses tab, then the little green + sign. This will start an assistant where you can enter one or more license keys, give them snappy names (like ESXi vSphere License and vCenter Server License since they come as different license keys).

Once done, click the Assets tab. Your vcenter server should be on the list of assets. Click the line with it but don’t click any blue text if there is any (or click the Back button on the Navigation panel – not the browser Back button – if you did). Click the leftmost icon, which has an incomprehensible picture of an ID card with a white arrow on a blue dot on it. The mouse-over hover help text says Assign license, which is exactly what you want to do. Select the snappily named vCenter Server License (as snappily named in the paragraph above). Click OK.

Exhale. You’re done.

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, 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.