What exactly is the Casper Suite? A review in many parts

I am on several forums and mailing lists for OS X Administrators.  Time and time again I see people trying to accomplish things with in their environment and they hit a barrier.  A lot of the time the barrier is not due to their lack of skills, but due to the lack of what their current technology can do.  I am lucky, as the powers that be that spend our money in my department decided to get this little software suite called Casper.  Casper is developed by JAMF software, and it is an amalgamation of many different tool sets all in one nice package. I have been using their software from day one of the 1:1 deployment I help manage.  So I am starting my third year with the Casper Suite.  I also am officially certified as a Casper Administrator.   So, let us get down to the nitty gritty of what Casper really is. Casper is a framework, which allows you to control, administer and deploy many different things to your clients over the network.  It is also a full blown inventory system, keeping track of your assets.  The suite also includes things like Composer, which makes it so easy to create packages to deploy to your users.  The framework allows you to accomplish many tasks such as:  Local policy enforcement, deploying packages, updates, and applications, local user account management, password changes, firmware settings and passwords, image creation and deployment, remote management, remote desktop, log in hooks, and so much more. The basics of how it works is quite simple.  You have the mother brain server, which they call the Jamf Software Server (or JSS) which you install on one of your servers in your deployment.  This can technically be any Mac running OS X Server, but you are obviously going to get the best performance out of an actual Xserve running as the JSS.  You will want to run this on OS X Server because of the client connection limit the regular client OS has.  The server is set up by the JSS Setup Utility, which is part of the Casper Suite.  This is a one click install that configures your database, your web front end, and some basic maintenance for these services.  You can also control and set up distribution points through this applicaiton.  However, for the most part after you run the setup utility you will probably find yourself using the web front end the most. Once your server is set up you build the client package, and point the client to your JSS, by either IP or FQDN.  You build the client package with the Recon Applicaiton that is part of the Casper Sutie.  Recon will remotely add the jamf binary to your machines and then have them phone home into the JSS and update your inventory.  You can also use it to create what is called a "quickadd.pkg" for your client Macintosh machines.  This installs the client software, and the full set of command line tools.  This is what you will use on the client side to execute what you want from the JAMF framework. Once the piece of client software is installed, depending on how you configured your framework, the client will now phone home to check for any jobs it needs to do.  In my current environment I have over 6,000 Macs phoning home every 30 minutes.  The 30 minute timer is randomized between clients.  This way I don't have 6,000 clients trying to checkin at the same time on the same day every day.  This staggers their check in times.  Now, technically speaking the JSS never actually pushes anything out to the clients.  The client actually checks in and does a forced pull from the server.  So your servers are always sitting idle until the client hits them. When the client checks in to the JSS it checks for whatever jobs it can do.  These jobs are called policies in the JSS.  Policies can be triggered by many different ways.  You can have them trigger by a timer, like every 30 minutes, or you can have them trigger at start up, or at log in, plus a few others.  Depending on what you want to accomplish, depends on which method you would choose.  For example, if I want to run a shell script every time a user logs into a Mac, I would select log in as my policy trigger. When a client executes policies it will pull whatever script or package that awaits it from the distribution point it is configured to pull it from.  This is where network segments come in handy.  If your network manager likes VLANs, then you are in major luck.  You can put any Mac running OS X Server in differnet locations and have them become Casper distribution points.  For example, in my current deployment we have 6 Casper Servers.  1 JSS, 5 Distribution points (1 Xserve at each building) and we also have 6 Mac Minis running OS X server at these buildings as failover distribution points.  So, when a client checks in to the JSS across the WAN to our central office to the server in our datacenter, it isn't going to pul that package across the WAN.  It will check it, get it's job and then grab that package from the building it is located in.  I have all my VLANs chopped up and configured in the JSS web end and then assign clients to those distribution points based on the IP range of that VLAN they are in.  This helps load balance everything a lot. Now, I bet you are thinking, there has to be some sort of security hole in this whole process?  Well, I am a firm believer that nothing in this world is bullet proof when it comes to security, but the basic model for how the client checks in and receives policy is this:

1. Client authenticates via ssh into JSS
2. Once it authenticates it checks for policy
3. All software packages installed and scripts ran is over HTTPS

The client will authenciate via a local account which you set up for ssh access.  Now, you can have the JSS randomize that password between the client and server so every time it changes it will change to a random password that only the client and the server know.  This means no human would know the password.  I, myself, set up three local accounts on all of my client machines.  I set up one account solely for Casper.  That account I give out to no one.  I set up a second account for local admnistration for IT staff, and the third one I set up for anyone outside the IT staff that may need ARD Admin access.  Each local account is hidden from the finder and their home directories live in /private/var.  Since I work in education I have a lot of non IT staff that need access to student computers.  I found it easier and more efficient to just give them their own account, that way they never mess with the accounts that the IT staff use.  You will have to use what works best for your environment, but the beautiful thing about this whole set up is that you can tweak it to how ever you see fit. It is very hard to explain what the Casper Suite does in just one article so I have decided to review it by category.  This is the basic introduction.  Down the road I plan on doing a review for each product, and probably one or two for some specific features.  The Casper Suite includes the following products:  Casper Imaging, Casper Admin, Casper Remote, Recon, and Composer.  Each application serves a different function, but they all tie in together. Thanks for reading. -Tom

Average: Select ratingPoorOkayGoodGreatAwesome

Your rating: None Average: 4.8 (4 votes)