[1911] in Moira
Associating Container/Cluster Objects with Groups in Moira
daemon@ATHENA.MIT.EDU (Joseph Calzaretta)
Tue Dec 18 19:58:44 2001
Message-Id: <200112190058.TAA12872@melbourne-city-street.mit.edu>
Date: Tue, 18 Dec 2001 19:58:27 -0500
To: moiradev@mit.edu
From: Joseph Calzaretta <saltine@MIT.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Dear folks on moiradev:
Since machines can now (well, in the near-ish future) be members of lists in Moira, it would be useful if clusters and containers had group objects associated with them. In the WIN domain, machines can easily be added to ACLs (which is important because there exists non-public software which needs to be accessed automatically, only by certain sets of machines.)
But: there is no way to add containers of machines to ACLs in Active Directory, even though this is a *prerequisite* for scalability. [ranting about Microsoft deleted] Fortunately, we really want the information in Active Directory to propagate directly from Moira anyway, so we don't need to accept this bizarre restriction. It makes sense anyway to have structures which act like groups of machines actually BE groups of machines.
I assume the following would have to be implemented via a process much like the current incremental updates. And I'm just going to talk about containers now, but I imagine similar things or a subset thereof can be said for clusters:
---
When a container is created in moira, an associated group should be created with a similar and meaningful-looking name, (avoiding name-collision issues with an appropriate invertible conversion function. I'm using one where the word "container" is prepended to the name, underscore is an escape character, _- is slash, __ is underscore... the actual convention could be something else, of course, presumably something more compact.) For instance:
container Machines/pismere-dev created
==>
group container_-machines_-pismere-dev created
Whenever a machine is added to the container, that machine should become a member of the associated group.
machine PHUBAR.MIT.EDU added to container Machines/pismere-dev
==>
machine PHUBAR.MIT.EDU added to group container_-machines_-pismere-dev.
Similarly, whenever a container is added to a container, the subcontainer's group should become a memeber of the associated group.
container Machines/pismere-dev/dingaling added as a subcontainer of container Machines/pismere-dev
==>
group container_-machines_-pismere-dev_-dingaling added to group container_-machines_-pismere-dev.
Of course, when containers or machines are renamed or moved or deleted, the appropriate thing should happen to the groups. And the while the groups should be as visible as their container counterparts, no manual changes should be made to the groups. Everything should propagate from the container side to the group side.
Now, when the group container_-machines_-pismere-dev is used for an ACL somewhere, all the machines in the container and machines in subcontainers recursively will be ACLed accordingly.
---
Another variant is that we may want there to be two groups for each container: a nonrecursive group whose members are only machines, and a recursive group whose members are the associated nonrecursive group and the recursive groups for subcontainers. For instance:
Machines/pismere-dev contains PHUBAR1.MIT.EDU, PHUBAR2.MIT.EDU, and Machines/pismere-dev/dingaling.
There would be a group called nonrecursive_-container_-machines_-pismere-dev which has PHUBAR1 and PHUBAR2 as members,
and a group called recursive_-container_-machines_-pismere-dev which has nonrecursive_-container_-machines_-pismere-dev and recursive_-container_-machines_-pismere-dev_-dingaling as members.
This (admittedly complicated-looking) structure would allow you to use the nonrecursive-* group to represent just the machines in the current container, and the recursive-* group to represent the machine in the current and all subcontainers recursively.
We probably don't need this variant because we tend to have machines at the leaves of the tree anyway. I'm mostly mentioning this in case someone else thinks it's important to support the distinction between recursive and nonrecursive container membership.
---
In any case, though, we need something like one of these two systems in place before we can really allow the WIN domain to support a significant number of different departments each with a significant number of machines. Any thoughts?
Joe Calzaretta
