Profile Manager is neat (as long as it’s not messed up). It’s a Mobile Device Management (MDM) server that also manages profiles for computers and users.
Behind the scenes, it’s a Rails app using the Sproutcore javascript framework to make it pretty and PostgreSQL as the database backend. It generates mobileconfig profiles that are basically special xml docs that are applied to devices.
Clients can either login to the web portal via http://server.example.com/profilemanager to manually download profiles that apply to either users or devices, or updated profiles can be pushed to clients via push notification services (that also have to be enabled, server side) for devices that already have profiles.
Here’s a possibly helpful walk-through. The afp548 folks had a video up but have since removed it. Not sure why, though.
I’d like to test the possibility of using profiles for managing machines not connected to a directory server, like for clients who have maybe just AD or nothing at all for central management. In brief testing today, it didn’t seem to work as expected, but I’m probably doing something wrong.
Can you apply profiles on the command line? Yes.
In troubleshooting a broken upgrade from one of the previous seed builds, I had to ensure ownership was okay on /usr/share/devicemgr, especially under /usr/share/devicemgr/backend. These directories contain the db and rails app, basically. There are a number of web apps under /usr/share, including the collaboration apps (wiki, etc.) and podcast producer. If ownership is wrong down there, services won’t start.
Also useful for troubleshooting (especially as you’re starting to get things configured), there’s a db wipe script here that will bring the postgres db back to defaults: /usr/share/devicemgr/backend/wipeDB.sh. That (and the service) requires that postgres is running. A few times, I’ve had to force it to restart with a “serveradmin stop postgres; serveradmin start postgres” to get devicemgr/profile manager working again. You’d think the db would be cool by itself, but maybe not.
From within the /use/share/devicemgr/backend directory, you may need to blast the whole db and reconfigure. I really hope you don’t need to do this as I did, but to do so, you’d want to use something like this (as root):
rake db:drop RAILS_ENV=“production”; rake db:create RAILS_ENV=“production”; rake db:migrate RAILS_ENV=“production”
The Rakefile in that directory contains all these routines. Check it out if you’re curious about rake, ruby, and rails deployment config.