Since the release of Google’s Cauliflower Vest, one of the wishlist items that a number of Mac admins have wanted is to use Cauliflower Vest’s capabilities without needing to use Google App Engine as the server backend. Crypt, a new open-source project being developed by Graham Gilbert, looks like a step in the right direction. See below the jump for details.
As part of your Mac’s standard build process for your environment, you may need to install certain packages that are generated for you by another process. A good example may be your workplace’s central antivirus management console, or a systems management tool.
Generally, these applications are installed once and then the centralized management server takes care of managing and updating them on your Macs afterward. For that first install though, they still need to be installed on your Macs and it’s usually a manual process for Mac admins to copy the latest installer from wherever it’s stored and add it to the build process.
However, if you have access to where the installer is stored, you can script the process of installation and fully automate the process of getting the latest installer and installing it on your Mac. See below the jump for an example of how to do this with Sophos Antivirus.
One of the services our IT team occasionally provides is connecting Mac desktops up to our Linux-hosted OpenLDAP server. Our OpenLDAP server doesn’t have any schema support built in for OS X, but historically we’ve gotten around that by using the RFC 2307 template support built into the LDAPv3 directory service plug-in. Then we hit Lion. Then we discovered how many other folks were having problems with Lion and OpenLDAP.
A lot of the problem was centered around the fact that Lion’s LDAP plug-in is now attempting to use the best SASL authentication method advertised by the LDAP server. Even if the server doesn’t require authentication, the Mac’s LDAP plug-in will still try to authenticate. What you’ll wind up with is an LDAP bind that allows lookups, but does not allow LDAP accounts to log in.
Most of the fixes involved going into the GUI and making some changes, then opening the relevant plist and making some more changes. Others recommended setting up the bind on one machine and then copying the relevant files from machine to machine.
Because I’m a lazy admin, I decided to see “How hard is this to script?” As it turned out, harder than you might think. Not all of the GUI buttons and tools have command-line equivalents and dsconfigldap turned out to be completely useless for this purpose.
In the end, I scripted the equivalent of “set up the bind on one machine, then copy the files.” I successfully bound one 10.7.x Mac, then studied the .plist carefully to find just the entries I needed for our OpenLDAP server. Then, I used a trick with /bin/cat that Peter Bukowinski showed me a while ago to feed the complete plist into a new file:
/bin/cat > /path/to/destination << ‘NEW_LDAP_BIND’
Since the technique worked on 10.7.x, I scripted my 10.6.x support in the script using the same model. At this point, the script handles everything about the OpenLDAP binding except for actually adding the LDAP domain to the authentication search path. I kept munging existing Active Directory search path entries in my testing, so it’s still necessary to go into Directory Utility at this point to add and promote the LDAP search path to be above our AD search path. For those folks who don’t have to worry about that, scripting the addition of your LDAP server to the authentication search path should be fairly straightforward.
For those interested, I’ve made the script available here. There are some Active Directory values mentioned that currently don’t do anything, but I’m planning to keep working on this script to see if I can fix the search path entry issue mentioned above.
One difference I found between 10.6.x and 10.7.x plists were that, on 10.6.x all the RFC 2307 LDAP mappings are included in the plist and must be included in the script. On Lion, just referencing that RFC 2307 is being used seems to work fine.
Another thing I found in my 10.7.x testing was that you couldn’t send the plist output directly to /Library/Preferences/OpenDirectory/Configurations/LDAPv3. Weird, but there was so much weird going on that I made a note then worked around it by sending the plist first to /tmp, then moving the complete plist over into /Library/Preferences/OpenDirectory/Configurations/LDAPv3.
Gary Larizza updated his NetSUS appliance write-up earlier today, to include information on how to modify the NetSUS’s /var/www/webadmin/scripts/adminHelper.sh so that it can accommodate DeployStudio’s NetBoot sets.
Gary’s way is elegant and uses vim. Consider this the illustrated version that’s doing the same process the hard way with nano. See below the jump for the details.
I was really excited to see that JAMF released a new Ubuntu-based VM that hosts Reposado and diskless NetBoot today. I was less excited to see that the VM was in VirtualBox’s Open Virtual Appliance format. Nothing against VirtualBox, but I’ve already got VMWare installed and prefer to use that instead.
Fortunately, it is possible to convert from .ova to .vmdk pretty easily using VMWare’s OVF Tool. See below the jump for how you can convert the file and use it in VMWare Fusion.
In my Casper setup, Casper’s JSS depends on a Jamf-installed Tomcat 7 installation on both my Casper production and Casper test servers, both of which are hosted on Red Hat Enterprise Linux 6.x VM servers.
To make sure that Tomcat is restarted automatically in case of a problem, a set of scripts has been installed with an accompanying crontab entry to check Tomcat to make sure it’s running. If not, an email with diagnostic information is sent then Tomcat is restarted. See below the jump for the scripts and the root crontab entry I’m using.