Feature request: SmartGroups based on group memberships

I "think" I know what your talking about here. Would you mind taking another
crack at explaining it though?

Craig E

Both of these situations sound like a dummy receipt, or Extension Attribute
even, would work.

1) You could drop a dummy package the name of first layer group ('Marko
Group'), markogroup.pkg for example, and then simply use that as your Smart
Group filter: Casper receipt like markogroup.pkg.

2) Same could be done here. Want to stop Firefox updates? stopfirefoxupdates.pkg and then scope the Smart Group to look for that
receipt.

Could even clean it up and make it a little easier with Extension Attributes
somehow.

Just my 2 pennies.

Steve Wood
Director of IT
swood at integer.com

The Integer Group | 1999 Bryan St. | Ste. 1700 | Dallas, TX 75201
T 214.758.6813 | F 214.758.6901 | C 940.312.2475

I'm curious as to what you're trying to accomplish with nesting Groups like
that? Not saying it's bad, just asking about the goal.

As for the 2nd request - could you not also achieve this by making a
No_Updates group, and simply assigning them to a dummy SUS server? Just a
thought...

-- Christopher Kemp
CNN Central Engineering

Hi Chris,

On 15.08.2010, at 13:15, Kemp, Chris wrote: I'm curious as to what you're trying to accomplish with nesting Groups like that? Not saying it's bad, just asking about the goal.

We deliver all software using policies, hence there are always two policies: one to install product (ie. 'Install Firefox') and one to update it (ie 'Update Firefox'). Being able to have at least two layers of groups would enable us to group machines into the first layer (ie 'Marko Group', 'Teaching Room A') and then assign those groups two a per product group (ie 'Firefox Users').

These two layers would ease maintenance of our approach at lot: we could assign the install and update policies just to the according product group (here 'Firefox Users'). If a lab requests Firefox, we would like to add the whole lab (and not the individual machines) to the product group and the software will be installed on the next install trigger.

As for the 2nd request - could you not also achieve this by making a No_Updates group, and simply assigning them to a dummy SUS server? Just a thought...

Sorry for not being precise, but I was more thinking of stopping the policy driven software delivery. Each update policy (like 'Update Firefox') would then have a condition 'not member of Stop Updates group' and all policy driven software deliveries would be stopped.

There are ways to overcome the missing subgrouping feature in the JSS by abusing fields like Department oder Building, which are mass-editable but not designed for this purpose as you end up having hundreds of different Departments and Building combinations. This approach is hard to maintain and impossible to audit properly. Subgrouping (or at least Smartgroups based on memberships (including NOT member of) would support a highly systematic approach and make complex scenarios much easier to handle.

Best,
Marko

--

Marko Jung
NSMS - Oxford University Computing Services
http://www.oucs.ox.ac.uk/nsms

Hi Steve,

On 15.08.2010, at 20:54, Steve Wood wrote:

thank you for sharing your thoughts. I would strongly advise not to push control information to clients. Dummy receipts or other inventory tricks can't be trusted as the client itself should never be trusted. In a managed environment you want to keep all management information at the central database.

I know there are plenty of work arounds for the missing subgrouping feature, in example we abuse other server side inventory fields like the building or the department. I thought it is worth asking for the proper way of arranging objects. In larger environments you need multiple hierarchies to represent your organisational structure.

Regards,
Marko

--

Marko Jung
NSMS - Oxford University Computing Services
http://www.oucs.ox.ac.uk/nsms

The first thing that popped into my mind when I read your initial request
was the dangers posed by using a Group attribute to set another Group
attribute. If not implemented carefully you have the potential for users to
get stuck in a loop that could get messy, such as inadvertently setting a
Group join/exclusion based on that same Group. I hope that Jamf would
consider that carefully if they tried to implement nesting groups like that.

Just my 2 cents worth. :)

-- Christopher Kemp
CNN Central Engineering

Hi,

On 16.08.2010, at 00:27, Kemp, Chris wrote:

Obviously there should be a validation that groups just form a forest without cycles. This could happen when you hit the 'save' button defining a new (group/smartgroup). IIRC cycle detection is solved since the late 60's by Floyd's cycle-finding algorithm.

Best,
Marko

--

Marko Jung
NSMS - Oxford University Computing Services
http://www.oucs.ox.ac.uk/nsms

Hi,

On 16.08.2010, at 00:34, Marko Jung wrote: > On 16.08.2010, at 00:27, Kemp, Chris wrote:

Actually I should have checked first, to find strongly connected components one shoud use Tarjan's algorithm not Floyd's.

Regards,
Marko