2.1 "These must be fulfilled prior to installing and configuring Public Cloud Enablement in a cloud environment" Might want to double check that "Public Cloud Enablement" is an actual concept that needs to be capitalized like it is or if that's just a random term that Chris Morgan made up. ----- 2.1 "Designated RHN Account for Proper Channel Access and Certification Tracking - A Red Hat Network (RHN) account is required to access the appropriate channel entitlements: " This one is a bit tricky. Are you familiar with the new akamai supported replacement for RHN? It's still a bit of a work in progress, which is to say we don't have a name for it yet and have still been calling it "RHN" to customers. The biggest difference relevant to these docs is that they don't need an account. We give them a cert that entitles them to RHEL and RHUI packages. They use that cert to download the RHUI stuff, install it, and then the RHUI uses that cert to download RHEL packages. So this statement is accurate with the exception of the part about needing an RHN account. Instead, they need a valid content certificate for the entitlements listed in the two sub-bullet points. In fact, this is actually mentioned in a statement a few lines down: "Providers must obtain a certificate provided by Red Hat and used by RHUA to synchronize channel content from RHN. " ----- 2.1 "You must have the required certificates in order to enable deployment and updates in the cloud." This should be removed. I actually have no idea what this is supposed to mean. ----- 2.1 "A certificate generated via the rhui-tools for use by starter images to gain access to entitled content on the CDS instances. " Remove this one too. It's not a pre-requisite but rather part of the installation process. ----- 2.2 "The following two files are packaged by the rhui-tools into the configuration RPM." Incorrect. The two files mentioned are provided to the customer... somehow. So far it's been via e-mail, but we probably don't need to go into specifics. More of the case where a customer who wishes to run this will be in contact with us and we'll work out the delivery of these files. ----- 2.2.1 "Specify the SSL certificates the RHUA to distribute to the CDS during instantiation, which the CDS will use to communicate with RHEL client instances." This is no longer the case. The RHUA used to remotely configure each CDS, which involved (among other things) distributing these SSL certificates. Now, a separate CDS configuration RPM is created for each CDS that contains its SSL certificate. I'd suggest just removing this line entirely. ----- 2.2.1 "SSH private key used to connect the RHUA to the CDS instances. The same key must be specified for all CDS instances." Mention that the CDS must be configured to allow password-less root logins using this key. This is needed because the RHUA uses rsync over SSH to upload packages to the CDS instances. Since that process runs automatically, we can't have it pausing to prompt for a password. Arguably, this is a pre-requisite, that the CDS instances be configured for such access. ----- 2.2.1 "If you are configuring monitoring services, you must have the Entilement certificate and entitlement key, as well as the CDS SSL and CA certificate, all of which are used to grant access to the channels on the CDS instances. These entitlement certificates will also be used by the clients." Remove this too. ----- 2.2.1 Here's a more concise list of the things I make sure are in place before I can properly configure the RHUA. I'm largely doing this as my own checklist to make sure everything is present in the docs, but I figured including it might be helpful: - SSH private key to log into the CDS instances. - Content cert and private key provided by Red Hat. - If the embedded load balancer is being used, SSL certificate whose CN is set to the fully qualified hostname of the RHUA instance, along with its associated private key. - CA certificate that will be used in the RHUI environment for all SSL certificates (i.e. those on the load balancer and CDS instances) and all client entitlement certificates. - Make sure the RHUA instance has enough space on it for all the packages. This will vary depending on the cloud provider. For instance, in Amazon, this would likely involve creating a new S3 volume, attaching it to the instance, and mounting it on the RHUA. Since it's so variable depending on the cloud provider, our only requirement is that it's mounted and accessible. How they get to that point is their responsibility. - If a proxy is needed for the RHUA to connect to the external (i.e. outside the cloud) internet, the proxy information (host, username, password) is needed when configuring the RHUA. ----- 2.2.3 "The Hostname of the RHUA instance to which the client should refer to perform updates" It's now the hostname of the load balancer. And hostname shouldn't begin with a capital letter. ----- 2.2.x We need a new section similar to these for the load balancer. Load balancer configuration requirements are as follows: - SSL certificate (again, with its CN set to the fully qualified hostname of the load balancer instance) and its associated private key. - RHUI environment CA certificate.
Added to content spec. Requirements. LKB
That should be "Installation Requirements". LKB
(In reply to comment #0) > 2.1 "These must be fulfilled prior to installing and configuring Public Cloud > Enablement in a cloud environment" > > Might want to double check that "Public Cloud Enablement" is an actual concept > that needs to be capitalized like it is or if that's just a random term that > Chris Morgan made up. > <para> The following are prerequisites to becoming a certified Red Hat Cloud Provider. These must be fulfilled prior to installing and configuring &PRODUCT; in a cloud environment. </para> <!ENTITY PRODUCT "Red Hat Update Infrastructure"> LKB
(In reply to comment #0) > > 2.1 "Designated RHN Account for Proper Channel Access and Certification > Tracking - A Red Hat Network (RHN) account is required to access the > appropriate channel entitlements: " > > This one is a bit tricky. Are you familiar with the new akamai supported > replacement for RHN? It's still a bit of a work in progress, which is to say we > don't have a name for it yet and have still been calling it "RHN" to customers. > > The biggest difference relevant to these docs is that they don't need an > account. We give them a cert that entitles them to RHEL and RHUI packages. They > use that cert to download the RHUI stuff, install it, and then the RHUI uses > that cert to download RHEL packages. So this statement is accurate with the > exception of the part about needing an RHN account. Instead, they need a valid > content certificate for the entitlements listed in the two sub-bullet points. > > In fact, this is actually mentioned in a statement a few lines down: > "Providers must obtain a certificate provided by Red Hat and used by RHUA to > synchronize channel content from RHN. " > I've merged the two statements: <listitem> <para> Cloud providers must have an entitlement to the Red Hat Update Infrastructure entitlement for every RHUA instance in the cloud. This grants access to: </para> <itemizedlist> <listitem> <para> Red Hat Update Infrastructure (RHUA and associated technologies) </para> </listitem> <listitem> <para> 32-bit and 64-bit RHEL image access to perform instantiation of instances </para> </listitem> </itemizedlist> </listitem> LKB
(In reply to comment #0) > > 2.1 "You must have the required certificates in order to enable deployment and > updates in the cloud." > > This should be removed. I actually have no idea what this is supposed to mean. > Done. > ----- > > 2.1 "A certificate generated via the rhui-tools for use by starter images to > gain access to entitled content on the CDS instances. " > > Remove this one too. It's not a pre-requisite but rather part of the > installation process. > Done. LKB
(In reply to comment #0) > > 2.2 "The following two files are packaged by the rhui-tools into the > configuration RPM." > > Incorrect. The two files mentioned are provided to the customer... somehow. So > far it's been via e-mail, but we probably don't need to go into specifics. More > of the case where a customer who wishes to run this will be in contact with us > and we'll work out the delivery of these files. <para> Before deploying the RHUA instance, you will require the following files: </para> <itemizedlist> <listitem> <para> Content Certificate—Entitlement certificate distributed by Red Hat that enables content download and syncing from Red Hat Network. </para> </listitem> <listitem> <para> Content Certificate Private Key—The unique key that enables syncing from Red Hat Network Satellite to your RHUA. </para> </listitem> </itemizedlist> LKB
(In reply to comment #0) > 2.2.1 "Specify the SSL certificates the RHUA to distribute to the CDS during > instantiation, which the CDS will use to communicate with RHEL client > instances." > > This is no longer the case. The RHUA used to remotely configure each CDS, which > involved (among other things) distributing these SSL certificates. Now, a > separate CDS configuration RPM is created for each CDS that contains its SSL > certificate. I'd suggest just removing this line entirely. > Done. LKB
(In reply to comment #0) > > 2.2.1 "SSH private key used to connect the RHUA to the CDS instances. The same > key must be specified for all CDS instances." > > Mention that the CDS must be configured to allow password-less root logins > using this key. This is needed because the RHUA uses rsync over SSH to upload > packages to the CDS instances. Since that process runs automatically, we can't > have it pausing to prompt for a password. > > Arguably, this is a pre-requisite, that the CDS instances be configured for > such access. > <listitem> <para> SSH private key used to connect the RHUA to the CDS instances. The same key must be specified for all CDS instances. </para> <para> The CDS must be configured to allow root login without requesting a password. The RHUA uses an automated upload process that cannot pause to prompt for a password. </para> </listitem> > ----- > > 2.2.1 "If you are configuring monitoring services, you must have the > Entilement certificate and entitlement key, as well as the CDS SSL and CA > certificate, all of which are used to grant access to the channels on the CDS > instances. These entitlement certificates will also be used by the clients." > > Remove this too. Done. LKB
(In reply to comment #0) > > 2.2.3 "The Hostname of the RHUA instance to which the client should refer to > perform updates" > > It's now the hostname of the load balancer. And hostname shouldn't begin with a > capital letter. > <listitem> <para> The hostname of the load balancer to which the client should refer to perform updates </para> </listitem> LKB
(In reply to comment #0) > > 2.2.x We need a new section similar to these for the load balancer. Load > balancer configuration requirements are as follows: > > - SSL certificate (again, with its CN set to the fully qualified hostname of > the load balancer instance) and its associated private key. > - RHUI environment CA certificate. <section> <title>Load balancer Configuration Requirements</title> <indexterm> <primary>requirements</primary> <secondary>load balancer</secondary> </indexterm> <para> The <command>rhui-tools</command> command is used to configure the load balancer. The command initiates a series of interactive prompts allowing you to specify the following implementation details: </para> <itemizedlist> <listitem> <para> The CA certificate used to sign the CDS SSL certificate. </para> </listitem> <listitem> <para> The SSL certificate for each CDS to be configured, as well as the certificate private key associated with each certificate. </para> </listitem> <listitem> <para> (Optional) The CA chain file if a trusted CA chain is used. </para> </listitem> </itemizedlist> </section> LKB
(In reply to comment #0) > > 2.2.1 Here's a more concise list of the things I make sure are in place before > I can properly configure the RHUA. I'm largely doing this as my own checklist > to make sure everything is present in the docs, but I figured including it > might be helpful: > > - SSH private key to log into the CDS instances. > - Content cert and private key provided by Red Hat. > - If the embedded load balancer is being used, SSL certificate whose CN is set > to the fully qualified hostname of the RHUA instance, along with its associated > private key. > - CA certificate that will be used in the RHUI environment for all SSL > certificates (i.e. those on the load balancer and CDS instances) and all client > entitlement certificates. > - Make sure the RHUA instance has enough space on it for all the packages. This > will vary depending on the cloud provider. For instance, in Amazon, this would > likely involve creating a new S3 volume, attaching it to the instance, and > mounting it on the RHUA. Since it's so variable depending on the cloud > provider, our only requirement is that it's mounted and accessible. How they > get to that point is their responsibility. > - If a proxy is needed for the RHUA to connect to the external (i.e. outside > the cloud) internet, the proxy information (host, username, password) is needed > when configuring the RHUA. I would like to use this to re-construct this chapter. Unfortunately, we don't have resources for this degree of change during this review. Cloning this bug so that it can be addressed in a future iteration of the doc. LKB
Further proofing and review undertaken in this chapter. See revision 0-1. LKB
Checking: Red_Hat_Update_Infrastructure-Installation_Guide-1.2-web-en-US-0-8.el5 (In reply to comment #6) > (In reply to comment #0) > > > > > 2.2 "The following two files are packaged by the rhui-tools into the > > configuration RPM." > > > > Incorrect. The two files mentioned are provided to the customer... somehow. So > > far it's been via e-mail, but we probably don't need to go into specifics. More > > of the case where a customer who wishes to run this will be in contact with us > > and we'll work out the delivery of these files. > > <para> > Before deploying the RHUA instance, you will require the following files: > </para> > <itemizedlist> > <listitem> > <para> > Content Certificate—Entitlement certificate distributed by Red Hat > that enables content download and syncing from Red Hat Network. > </para> > </listitem> > <listitem> > <para> > Content Certificate Private Key—The unique key that enables syncing > from Red Hat Network Satellite to your RHUA. > </para> > </listitem> > </itemizedlist> > > LKB mdash is not displayed "Private KeyThe"
While we're on Ch.2. Couple of other missing spaces Table 2.2. Certificate Signing Request (CSR) Fields "Common NameThe" "CountryThe" "StateCode" "LocationSpecific city" "OrganizationYour business" "Organizational UnitYour "
I've removed all the — entities. LKB
Published 14 December 2010: http://docs.redhat.com/docs/en-US/Red_Hat_Update_Infrastructure/1.2/html/Installation_Guide/index.html Please raise any issues as new bugs against this live version. Thanks, LKB