AutoPkg is a tool to help automating the download of new software packages - whether they be updates or full new installations. A large part of the Mac System Admin’s job is making sure that installed software is kept up to date - especially things like Flash.

So, AutoPkg is here to ensure you don’t have to go check a bunch of webpages for updates every time there might be an update available.

Here’s what you do:

1. Make sure you have git installed. This can be done with the Xcode CLI Tools, or else you can use the official git installer.

2. Install AutoPkg. It is distributed through .pkg installers for easy of use. It also installs a LaunchDaemon that allows you to use AutoPkg’s packaging capabilities without needing have root privileges.

3. Add some repos! If you go to https://github.com/autopkg you will see a good selection of autopkg recipe repositories ready for you to use. Install these...

There seems to be a lot of confusion with people who are just starting out with it. There are manifests and catalogs, and optional installs, and included manifests, etc… The documentation does a pretty good job of explaining it, so let me point you there first. But after you go through that, you may still have some questions about practical usage. Well, the best thing you could do would be to set up munki in a development environment and mess around with it. When I first started trying to use munki, I read a lot about it and I talked to Greg Neagle (the creator), but nothing helped quite as much as setting it up and just trying things. Sure, I broke some stuff at first, but when I was done with that, I was fairly confident in my abilities.

• Catalogs
  Every package or piece of software you import into munki will end up in a Catalog. These are just listings of different types of software...

This is an excellent article written by Rich Trouton with some resources and information about the end of Java 6 support for OS X.

Atlassian allows you to use your existing LDAP directory service to authenticate to their products. If you are using more than one (like jira and confluence), I definitely recommend getting crowd.

Crowd is simply a ‘single sign-on’ tool. Essentially it allows you to use a single user database to log in to all your Atlassian services. If you already use an LDAP service, you may not need this, but it certainly makes things easier. Unsecured LDAP is a breeze to configure, but the Java based Atlassian services are a bit cryptic when it comes to LDAPS. Crowd makes this easier to manage, as you only have to worry about ssl certificates and java in one place. It also makes it easy to drill down access groups and such, so you can limit what users have access.

If you want to configure SSL, be prepared to go to the CLI and configure a certificate store. I’ll provide some more information on that...

This worked fairly well out of the box (somewhat surprisingly).

Atlassian tries to make things easy by having a ‘Standalone’ edition of each of their products. Essentially this is the product bundled with tomcat so that you don’t have to configure your system’s tomcat. This is very useful if you want to run multiple instances on the same machine. We have Jira, Confluence, and Crowd all running on the same box.

Tomcat can be a standalone web server, but the problem is, it doesn’t want to listen at port 80 or 443. You can configure it to listen over ssl, but that still means your end-users have to type in the port at the end. So, what you do is you have apache2 act as a proxy. Here’s an example vhost that has apache2 listening on a specific interface, redirecting to https, and acting as a proxy with tomcat.

Listen 10.12.10.102:80
<VirtualHost 10.12.10.102:80>
ServerAdmin

During the course of migrating directory services from OpenLDAP to Open Directory, I was tasked with finding alternate configurations for connecting a lot of different services to OD. Among these were gitlab, freeradius, a slew of Atlassian products, and also apache2.

Now, authenticating to an apache vhost with ldap requires the apache mod authnz_ldap. Using that within a vhost looks like this:

<Location />
  AuthType Basic
  AuthName “Network Credentials Required”
  AuthBasicProvider ldap
  AuthLDAPURL “ldap://ldap.example.com/ou=users,dc=example,dc=com?uid”
  AuthzLDAPAuthoritative on
  AuthLDAPGroupAttribute memberUid
  AuthLDAPGroupAttributeIsDN off
  Require ldap-group cn=apacheauthexample,ou=groups,dc=example,dc=com
  Require ldap-attribute gidNumber=10065
</Location>

That would give access to anyone within the ‘apacheauthexample’ group, provided that the gid matched 10065...

So along the same lines as my previous post, I was tasked with migrating authentication for our GitLab service from OpenLDAP to Open Directory, and again… not much to be found online! Most of what I found was very hacky and involved inserting another auth provider into the gitlab code (something which seems like a bad idea in a production environment, as it would almost certainly fail in future updates).

But, having just come off my victory with apache2, I decided to see if I could make GitLab query OD and have OD do all the work.

So, here are the old, OpenLDAP settings:

 LDAP settings
ldap:
enabled: true
host: ‘ipaddress’
base: ‘dc=example,dc=com’
port: 389
uid: ‘uid’
method: ‘plain’  “ssl” or “plain”
bind_dn: ‘cn=admin,dc=example,dc=com’
password: ‘password’

And here is what I fashioned out of OD:

 LDAP settings
ldap:
enabled: true
host: ’ipaddress’
base:

During the course of migrating directory services from OpenLDAP to Open Directory, I was tasked with finding alternate configurations for connecting a lot of different services to OD. Among these were gitlab, freeradius, a slew of Atlassian products, and also apache2.

Now, authenticating to an apache vhost with ldap requires the apache mod authnz_ldap. Using that within a vhost looks like this:

<Location />
  AuthType Basic
  AuthName “Network Credentials Required”
  AuthBasicProvider ldap
  AuthLDAPURL “ldap://ldap.example.com/ou=users,dc=example,dc=com?uid”
  AuthzLDAPAuthoritative on
  AuthLDAPGroupAttribute memberUid
  AuthLDAPGroupAttributeIsDN off
  Require ldap-group cn=apacheauthexample,ou=groups,dc=example,dc=com
  Require ldap-attribute gidNumber=10065
</Location>

That would give access to anyone within the ‘apacheauthexample’ group, provided that the gid matched 10065...

Let me start off with a helpful guide: http://guides.rubygems.org/make-your-own-gem/

Having said that, I personally had some problems developing a gem of my own.

I started out with a single .rb file that was supposed to replace a lengthy (over 400 lines) shell script. Once that ruby file was complete (in less than half the number of lines in the shell script I might add) I thought to myself, hey instead of having to use ./ or ruby to call the script, what if they could just run it from anywhere with a single command? Hence, the shelter gem was born.

So here’s the breakdown -

These things are required for a gem (say, with the name shelter).

.
├── shelter.gemspec
└── lib
          └── shelter.rb

You’ve gotta have the *.gemspec, which contains information about the gem, including description, author, what files to include, etc.

Here is a sample gemspec.

Gem::Specification.new do

Forget about instaDMG! It was a helpful tool, but it was lacking in documentation, and it was getting a bit long in the tooth (for the past 3 or 4 OS X releases). Thankfully, MagerValp is a hero and wrote AutoDMG, which replaces instaDMG.

AutoDMG is written in python, and unlike instaDMG, it has a nice GUI to go with it. It supports the same features that instaDMG did, including OS updates and third-party installs, but perhaps the best things about it are completely new!

1. It has built in manifests for Apple Software updates, so you don’t have to spend your time finding URLs and checksums for them (in fact, you don’t have to worry about checksums at all).

2. It outputs images that are suitable for deployment with DeployStudio (or ASR, Absolute Manage, etc).

It has a host of other improvements as well, including drag and drop for adding the Install OSX.app (rather than having to extract...