Hide Forgot
Menu Screenshot ------------------------------------------------------------------------------ -= Red Hat Update Infrastructure Management Tool =- -= Client Entitlement Management =- e generate an entitlement certificate c create a client configuration RPM from an entitlement certificate Connected: guardian ------------------------------------------------------------------------------ rhui (client) => ----- Intro "When you create client entitlement certificates, you will need to make a separate certificate for each repository." It's not necessarily per repository. It's however they want to sub-divide their clients. For instance, it's possible they'd want some clients that only have access to RHEL 5, but other clients have access to RHEL 5 and JBoss-related channels. ----- Note "Once you have been granted a certificate, ensure that clients are only able to access one certificate at a time. Only allow client instances to download the certificate they require for their version of the image, and no other certificates." I think we can remove this. It's feasible that a cloud provider would want to do a more fine-grained approach and do a certificate per product, in which case clients with access to multiple products would be granted multiple entitlement certificates. ----- Generate an Entitlement Certificate You might want to clarify what "available repositories" means. They can select form all custom repositories and all products granted entitlements in the Red Hat issues content certificate. For the latter, those repositories do not have to be deployed in the RHUI at the time of certificate creation (that's what the * indicates). ----- Generate an Entitlement Certificate "Is 10 the default value? How does that work?" Let me get back to you on this one. I might be removing this input entirely. ----- Generate an Entitlement Certificate "Unprotected repositories that are added to the RPM will be included in the generated .repo file, along with the entitlements included in the certificate. " Might want to be a bit more specific: "along with repository definitions for all entitlements included in the certificate." ----- 7.1 "The Entitlements Manager screen is used to list entitled products in the current content certificate, and upload new certificates. " No comma. ----- 7.4 Upload Content Certificate Might want to make a quick note that the certificate is uploaded to the RHUA as well and will be used in future syncs for Red Hat repositories. It's your call if you want to go into the explanation of "so make sure you don't upload a certificate before it is valid, otherwise your syncs will break until the valid date is reached."
(In reply to comment #0) > Menu Screenshot > > ------------------------------------------------------------------------------ > -= Red Hat Update Infrastructure Management Tool =- > > > -= Client Entitlement Management =- > > e generate an entitlement certificate > c create a client configuration RPM from an entitlement certificate > > Connected: guardian > ------------------------------------------------------------------------------ > rhui (client) => > Added, thanks. > > ----- > > Intro > > "When you create client entitlement certificates, you will need to make a > separate certificate for each repository." > > It's not necessarily per repository. It's however they want to sub-divide their > clients. For instance, it's possible they'd want some clients that only have > access to RHEL 5, but other clients have access to RHEL 5 and JBoss-related > channels. <para> When &RH; issues the original entitlement certificate, it will grant access to the repositories you requested. When you create client entitlement certificates, you will need to decide how to sub-divide your clients, and create a separate certificate for each one. Each certificate can then be used to create individual RPMs for installation on the appropriate guest images. For example, you might create seperate certificates for clients that require access to &RHEL; 5, and those that require access to &RHEL; 5 and Jboss channels. </para> Not sure if that's described very well. Got any better suggestions? > > ----- > > Note > > "Once you have been granted a certificate, ensure that clients are only able to > access one certificate at a time. Only allow client instances to download the > certificate they require for their version of the image, and no other > certificates." > > I think we can remove this. It's feasible that a cloud provider would want to > do a more fine-grained approach and do a certificate per product, in which case > clients with access to multiple products would be granted multiple entitlement > certificates. It's gone. > > ----- > > Generate an Entitlement Certificate > > You might want to clarify what "available repositories" means. They can select > form all custom repositories and all products granted entitlements in the Red > Hat issues content certificate. For the latter, those repositories do not have > to be deployed in the RHUI at the time of certificate creation (that's what the > * indicates). <para> A list of all available repositories will be displayed. This includes all custom repositories, and all products that have been granted entitlements in the content certificate that &RH; granted. Select which repositories to include in the entitlement certificate by typing the number of the repository at the prompt. Typing the number of a repository will place a checkmark next to the name of that repository. Continue until all repositories you wish to add have been checked, and then type <userinput>c</userinput> at the prompt to confirm. </para> <para> Repositories that are shown with an asterisk (<parameter>*</parameter>) indicates that they are deployed in the RHUI. </para> > > ----- > > Generate an Entitlement Certificate > > "Is 10 the default value? How does that work?" > > Let me get back to you on this one. I might be removing this input entirely. /me holds > > ----- > > Generate an Entitlement Certificate > > "Unprotected repositories that are added to the RPM will be included in the > generated .repo file, along with the entitlements included in the certificate. > " > > Might want to be a bit more specific: "along with repository definitions for > all entitlements included in the certificate." <para> Unprotected repositories that are added to the RPM will be included in the generated <filename>.repo</filename> file, along with the repository definitions for all entitlements included in the certificate. </para> > > ----- > > 7.1 > > "The Entitlements Manager screen is used to list entitled products in the > current content certificate, and upload new certificates. " > > No comma. > <para> The Entitlements Manager screen is used to list entitled products in the current content certificate and upload new certificates. </para> > ----- > > 7.4 Upload Content Certificate > > Might want to make a quick note that the certificate is uploaded to the RHUA as > well and will be used in future syncs for Red Hat repositories. It's your call > if you want to go into the explanation of "so make sure you don't upload a > certificate before it is valid, otherwise your syncs will break until the valid > date is reached." Added note: <note> <title>Note</title> <para> When you upload a new content certificate, it will also be updated in the RHUA, and will be used for synchronizing &RH; repositories. For this reason, do not upload a new content certificate before it becomes valid, as it will cause your synchronizations to fail until the valid date is reached. </para> </note> Revision 1-9 LKB
http://documentation-stage.bne.redhat.com/docs/en-US/Red_Hat_Update_Infrastructure/2.0/html/Installation_Guide/chap-Installation_Guide-Client_Entitlements.html#sect-Installation_Guide-Client_Entitlements-Managing_Entitlement_Certificates
All the points are updated.
This book is now available at http://docs.redhat.com/docs/en-US/Red_Hat_Update_Infrastructure/2.0/html/Installation_Guide/index.html Please raise a new bug for any further changes. LKB