RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1108226 - [RFE] Use automember for hosts after the host is added
Summary: [RFE] Use automember for hosts after the host is added
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa
Version: 7.1
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: ---
Assignee: Martin Kosek
QA Contact: Lenka Doudova
URL:
Whiteboard:
Depends On:
Blocks: 1370127
TreeView+ depends on / blocked
 
Reported: 2014-06-11 14:58 UTC by Martin Kosek
Modified: 2016-08-25 11:36 UTC (History)
2 users (show)

Fixed In Version: ipa-4.0.3-1.el7
Doc Type: Enhancement
Doc Text:
Clone Of:
: 1370127 (view as bug list)
Environment:
Last Closed: 2015-03-05 10:11:55 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0442 0 normal SHIPPED_LIVE Moderate: ipa security, bug fix, and enhancement update 2015-03-05 14:50:39 UTC

Description Martin Kosek 2014-06-11 14:58:01 UTC 
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/freeipa/ticket/3752

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.
Comment 1 Martin Kosek 2014-06-11 15:23:31 UTC 
This request is already fixed in upstream FreeIPA project. Please refer to the linked ticket for additional details and related commits.
Comment 3 Lenka Doudova 2015-01-28 14:07:52 UTC 
In UI, tests were performed:

1. Automember for separate entries:
     - added two hostgroups
     - added an automember rule to both hostgroups - class=<str>
     - added two hosts without specifying a class
     - checked that hosts are not included in any hostgroup
     - specified a class for both hosts (one corresponding to one host group, the other one to the second host group)
     - checked that hosts were not yet added to the corresponding hostgroups
     - open one host, click Action > Rebuild auto membership > Confirm
     - checked that host is now assigned to the corresponding hostgroup, other hosts are not effected (the change is visible only after refreshing the UI)

2. Automember for all entries:
     - created two new hosts without specifying class
     - specified a class for both hosts (corresponding to hostgroups from 1)
     - in Hosts dialog: Actions > Rebuild auto membership
     - checked that both new hosts were assigned to corresponding hostgroup

3. Automember for selected entries:
     - repeated test No. 2, only this time only one of the new entries was selected, thus automember was performed only for the selected entry

Note:
In case a host was already included in a hostgroup and later the class attribute of that entry was deleted/changed and automember was rebuilt, the entry still belonged to original hostgroup after performing the rebuilt. I'm not sure if that's correct behavior.
Comment 5 errata-xmlrpc 2015-03-05 10:11:55 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-0442.html
Note You need to log in before you can comment on or make changes to this bug.