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 791077 - Clarify some things in ipa documentation in section 9.3.1
Summary: Clarify some things in ipa documentation in section 9.3.1
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: doc-Identity_Management_Guide
Version: 6.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 6.3
Assignee: Deon Ballard
QA Contact: ecs-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-16 04:38 UTC by Rob Crittenden
Modified: 2012-06-21 23:15 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-21 23:15:13 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Rob Crittenden 2012-02-16 04:38:53 UTC
Description of problem:

Some suggestions from freeipa-users mailing list (and my response).

> Sort of minor but I find the following a bit inconsistent,
> 
> I am looking at section 9.3.1, item no 3
> 
> I think it should say,
> 
> 3. Generate the nfs service keytab, there are two methods,
> 
> i) On the NFS server, with this command "etc etc"
> 
> ii) On a different machine do a)....b)...c)...d)

The distinction is really "whether the machine has ipa-getkeytab or not." The NFS server could be a Solaris machine in which case you'd have to do all this elsewhere.

I think this is trying to say "if your NFS server is a Linux machine you can directly update /etc/krb5.keytab with these keys and be done with it."

Perhaps a little more language about this distinction would help.

> 
> for your b) You say "Copy over to the NFS host machine" where earlier you said NFS server, you repeat this in d)   for consistency it should be "server" it certainly slows my understanding down when I see such things being mixed up....

Yup, I agree.

> 
> I also see under 6.5.1 point 6 that there is a ipa-getkeytab command but as per NFS is that run on the server that is providing the service? or on the IPA server, I find it unclear.......thinking about it its on the target server offering the service I think you are saying, but by then Ive lost my train of thought....

ipa-getkeytab can be run anywhere for any service. It is just more convenient to run it on the target machine because then you don't have to move around keytabs (and do the nasty work in 9.3.1.3 d).

We also should probably mention that you need a Kerberos ticket to run ipa-getkeytab. It may get a bit cumbersome to mention it EVERY single time though, not sure what the best route is.

Comment 4 Deon Ballard 2012-04-17 16:49:50 UTC
Link:
http://documentation-stage.bne.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/kerb-nfs.html#krb-nfs-server

As for kinit'ing before running every command -- I've been trying to update CLI procedures as I touch them. I haven't made it a super high priority, but I'm trying to do it incrementally, at least by adding kinit admin or whatever to the example. And I added this section to the tools usage chapter:
http://documentation-stage.bne.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/basic-usage.html#cmd-usage-kinit

Comment 6 Deon Ballard 2012-06-21 23:15:13 UTC
Closing.


Note You need to log in before you can comment on or make changes to this bug.