#3752 [RFE] Use automember for hosts after the host is added
Closed: Fixed None Opened 10 years ago by dpal.

It became apparent that there are some cases when the purpose thus and proper system placing into the host groups is not known in advance. Consider the following scenario:
1. There is an existing system not integrated with IPA, Spacewalk or other management software but running some application.
2. The system should be inspected, classified and the right configuration and policy should be applied.
3. The first step is to enrol it into IPA so that management software can SSH into the system and collect facts and stats. At this point the host needs to be created in IPA but the type of the host is yet to be determined.
4. Once the system is enrolled the management software would connect, collect facts and determine the class or type of the system.
5. The management software then should be able to issue command that would trigger autoplacement plugin for already existing host.


If this inspection system can modify the host object why can't it simply directly add the host to whatever group it needs to ?

It can but it is more complex than leveraging the automember functionality. The management software would also need to know the actual groups and what they mean. This is not necessarily the case. The management system can detect that this is a "web server", or "file server", or "mail server" and tell IPA this is "file server, go do your magic and place it into the right groups only you know about" because they are part of IPA and used for HBAC and SUDO and nothing else.

AFAIK the DS plugin was built with this use case in mind, we are just not using it yet.

I agree, it is best to leverage automember and not split the logic.

DS 9 added the following features to the automember plugin:

  • rebuild membership, which re-runs the Auto Membership Plug-in on existing entries to update the group membership; this is essentially a fix-up task
  • automember export updates, which does a test-run of what the membership changes would be and writes them to a specified LDIF file
  • map updates, which inputs the entries from an LDIF file, performs a test-run, and then writes what the results of the fix-up task would be to a given LDIF file

Now I am just thinking - would it be useful to have a DS task to rebuild just one entry? I.e. a task that would ask DS rebuild membership just for the specified DN. This way other, unrelated hosts' memberships would stay intact making the change more robust IMO.

Adding rmeggins to CC for evaluation if this is feasible or not.

Frankly I thought that that there is already an option to do that.

Nathan says:
"I think you should be able to just use a filter to identify the single entry. Mark put details in the ticket here:

https://fedorahosted.org/389/ticket/20#comment:10

"

Thanks, this is exactly what I was looking for. Looking at this ticket, I think it could translate to following changes:

  • ipa automember-rebuild-membership --type={hostgroup,group} - this would run automember rebuild membership task for all objects of this type.
  • ipa host-rebuild-membership HOST - run automember rebuild membership task for given host
  • ipa user-rebuild-membership USER - run automember rebuild membership task for given user

We should also hook these commands to Web UI then - to automember, user and host pages.

All in all, I think feature is very useful and would add much more value to automember ability - I would propose to add it to next release.

3.4 development was shifted for one month, moving tickets to reflect reality better.

I think that this work actually implements ticket #2004, I plan to move it to 3.4 as well.

Replying to [comment:12 mkosek]:

I think that this work actually implements ticket #2004, I plan to move it to 3.4 as well.

Yes, #2004 looks like a duplicate of this ticket.

Adjusting time plan - 3.4 development was postponed as we focused on 3.3.x testing and stabilization.

Adjusting time plan - 3.4 development was postponed as we focused on 3.3.x testing and stabilization.

master:[[BR]]
6c9b3b0 Fix error message when adding duplicate automember rule[[BR]]
0ac6397 Add unit tests for automember rebuild command[[BR]]
dfea598 Add a privilege and a permission needed for automember rebuild c
d97386d Add automember rebuild command[[BR]]

Metadata Update from @dpal:
- Issue assigned to akrivoka
- Issue set to the milestone: FreeIPA 4.0 - 2013/12

7 years ago

Login to comment on this ticket.

Metadata