fnichol/chef-user — pull request #33 by davidc-donorschoose (2012-12-08 02:59:01+00:00)
Title: Management of groups is integrated and consistent with management of users

Define "groups" in your data_bags and listed by groupname as your node attribute. Those define which groups will be managed if you include_recipe "user::data_bag". This is the same algorithm used to manage "users".

The ordering of the "create" and "remove" operations for users and groups is carefully controlled to avoid failures. If your data_bags change the supplimentary "groups" attributes for a user account, these will be modified in the system by the next chef run.

One design issue: Regardless of what "users" or "groups" are listed in node attributes to be managed, any user or group defined in the data_bags specified with the "remove" action will be removed from the system by the recipe[user::data_bags]. I reasoned that this is probably expected behavior and it didn't seem worthwhile to add to the complexity of node attributes with specific lists. Someone may want to modify the interface with "remove_users" and "remove_groups" lists in the node attributes, which would be symmetric with the "users" and "groups" lists for management. I felt the most likely use case was to remove user accounts across the entire infrastructure. One simple change to mark the item in the data_bags with "action" : "remove" will propagate that change across all systems as chef is run. The need to hunt down all node attributes seems burdensome. Still, the "remove_*" lists might be convenient for changes like migrating applications between systems so that an application account could be retired on the old system.

Slight problems (I believe these were already issues before my changes):
* Changes to a login "gid" attribute in the "users" data_bags will not be changed in the system if chef has already created the user account.
* The login group must be explicitly created; that is, the "create_group" attribute in the "users" data_bags doesn't seem to have any effect. I must specify a "gid" in each of the the "users" and I must create the group -- which can now be managed in the "groups" data_bags. However, I *can* specify any gid for the login group.