| Summary: | RFE: Resource Record type options should be more descriptive. | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Gowrishankar Rajaiyan <grajaiya> |
| Component: | ipa | Assignee: | Rob Crittenden <rcritten> |
| Status: | CLOSED ERRATA | QA Contact: | IDM QE LIST <seceng-idm-qe-list> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.3 | CC: | jgalipea, mkosek, mniranja |
| Target Milestone: | rc | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | ipa-2.2.0-3.el6 | Doc Type: | Enhancement |
| Doc Text: |
No documentation needed.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-06-20 13:32:22 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Gowrishankar Rajaiyan
2012-02-13 13:58:39 UTC
Upstream ticket: https://fedorahosted.org/freeipa/ticket/2382 I was thinking about this issue. It is true, that user may be get confused with all these new options until he gets a bit more familiar with it and understands the concepts behind the scenes. Would it be OK with you if we enhance ipa DNS help (`ipa help dns') and explain the concept of structured DNS options and how they operate in ADD, MOD and DEL commands, with few examples? Any other ideas how to make the new DNS operations more clear are welcome. Yes, I think that would be OK as this is more related to usability and with enhanced ipa DNS help (`ipa help dns`) operations would be more clear. fixed upstream. master: 640dee7caad4a1bf7c05bb539f0e6655fe758a54 ipa-2-2: b6ef6af22c931c92a53be74b406918d9bc748e8e `ipa help dns` is very comprehensive indeed. Thanks Martin. <snip> USING STRUCTURED PER-TYPE OPTIONS There are many structured DNS RR types where DNS data stored in LDAP server is not just a scalar value, for example an IP address or a domain name, but a data structure which may be often complex. A good example is a LOC record [RFC1876] which consists of many mandatory and optional parts (degrees, minutes, seconds of latitude and longitude, altitude or precision). It may be difficult to manipulate such DNS records without making a mistake and entering an invalid value. DNS module provides an abstraction over these raw records and allows to manipulate each RR type with specific options. For each supported RR type, DNS module provides a standard option to manipulate a raw records with format --<rrtype>-rec, e.g. --mx-rec, and special options for every part of the RR structure with format --<rrtype>-<partname>, e.g. --mx-preference and --mx-exchanger. When adding a record, either RR specific options or standard option for a raw value can be used, they just should not be combined in one add operation. When modifying an existing entry, new RR specific options can be used to change one part of a DNS record, where the standard option for raw value is used to specify the modified value. The following example demonstrates a modification of MX record preference form 0 to 1 in a record without modifying the exchanger: ipa dnsrecord-mod --mx-rec="0 mx.example.com." --mx-preference=1 </snip> Verified: ipa-server-2.2.0-3.el6.x86_64
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
No documentation needed.
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. http://rhn.redhat.com/errata/RHBA-2012-0819.html |