The current Zen agent on OS X, like its Linux predecessor, is machine-oriented. Jason Blackett has mentioned in the past that he believes Zen will eventually have a provision for user-oriented control of OS X. However, OS X implements traditional Unix flat user files ("shadow" etc.) only as a legacy function, and discounts PAM modules. Instead, it uses its Directory Services framework (represented by the DirectoryServices process pre-Lion and opendirectoryd in Lion and afterwards). The nice thing about DirectoryService from an engineering perspective is that it abstracts all directory store calls -- local users (implemented as XML records), Kanaka, Active Directory, and LDAP (used for Apple's native Open Directory as well as pre-Kanaka eDirectory stores) are all part of the standard Search path for Directory Services. Any process that can interrogate or otherwise interface with DS can treat all of these sources as a single source. Since the Windows agent supports eDirectory, ActiveDirectory, and local (for volatile DLU only) users anyway, the use of DS would be a nice way to provide feature parity between OS X and Windows for ZEN.
There are some obvious directions for ZEN to leverage DS, provided that a ZEN-internal framework is written for the zac agent to interface with it. Beyond simply understanding the user, it would provide the avenue by which the Kanaka client and ZEN could combine, comparable to integration with the traditional Windows NCP client. A greater advantage would be if ZENworks went beyond interrogating DS and either provided a plugin for it (like Kanaka does), or created a new local directory node (such as in these instructions: http://managingosx.wordpress.com/2008/02/07/mcx-dslocal-and-leopard/ ). Either of these solutions would allow for ZEN to provide additional functionality by either using augmented records (records which combine with existing read-only records to add attributes - known as the "Cylinder of Destiny" but starting to be deprecated), adding users to ZEN-specific groups (the more-widely deployed "Magic Triangle"), or using Profile Manager. Moreover, if there were a ZEN DS plugin, the agent could generate attributes dynamically from multiple parts of the ZEN data model and present them as a single uniform record to DS.
An understanding of OS X DS would also be the easiest way to route around the current agent dependence on the root user, which ideally should not need to be enabled on and OS X machine. The agent could attach to an existing user, or create one in the ZEN-specific store at installation.
I have mentioned only users and groups here, but DS also includes machine objects, machine groups, configuration objects, mount points, and a number of other useful structures.
There is good documentation for OS X DS, both for administrators and developers. The good folks at MacEnterprise.org and AFP548.com specialize in dealing with it in large-scale environments. More importantly from an engineering perspective, virtually all of the DS code is open-source (including the daemons and the dscl tool) and available from Apple ( most recently, http://www.opensource.apple.com/release/mac-os-x-1073/ -- look for DirectoryService and DSTools).
My specific request is for
1) A ZENworks agent process that can intelligently interrogate OS X Directory Services
2) Some sort of ZEN plugin for the DS framework (or new node in /private/var/db/dslocal/nodes ) to provide ZEN information to DS.
by: Johnnie O. | over a year ago | Other
Comments