I have updated
with the comments from the latest round. The changes can be see at
I think most aspects are clear now.

I think only one decision is needed about how to manage the
assignment of a host to a view. In the original draft host groups were
used to connect hosts to views. There is only the drawback that a host
can only have one view but can belong to multiple host groups. So
chances are that when we follow the host-group memberships of a single
host to the views we end with two or even more views.

To get around this Alexander suggested to add a new single-value LDAP
attribute to the host objects which holds the DN of a view. With this
all ambiguity is gone. The drawback here is that now at least in the
WebUI each host which should not see the default view must be added
individually to a view. (On the command line for-loops from the shell
can be used).

I would prefer Alexander's suggestion. Because although on the first
look the host-group approach sounds more comfortable from the management
point of view I think the difference is not that large when looking a
bit more into the details. It was already recommended to not use
host-groups already used for other purposes like HBAC or sudo for views
management to avoid unexpected changes of POSIX IDs when those groups
are modified for other purposes. For the host-groups which are
exclusively used for view management we can add DS plugin which make
sure that a host is always only a member of one of such groups to avoid
ambiguity. Initially adding hosts to a host-groups is a bit easier due
to the host-group add-dialog of the WebUI but later on each new host
which should not have the default view has to be added to the related
host group as well. It might be even a bit more effort than with
Alexander's suggestion because a host cannot be added to a group when it
is created, so a host has to be created first and then can be added to a
group. As a summary I think there are no real benefits using host-groups
for management compared to assigning the view directly to the host.

Other opinions, comments and suggestions are welcome.


Freeipa-devel mailing list

Reply via email to