Bug 704583

The more I look, the more the rest of the guide says "you", so my comments on those notes above may not be a big deal.

(In reply to comment #0)
> Figure 1.1 is incorrect. I'd suggest the following changes:
> 
> - Change the direction of the arrows between RHUA and CDS and the protocol to
> be https. The CDS instances now pull content from the RHUA as compared to
> previously where it was pushed over rsync.
> 
> - The RHUA triggers things on the CDS by using a qpid message broker. That
> arrow would go from RHUA to CDS. However, I'm not really sure how to put this
> into the picture without being confusing, and other than the firewall
> implications it's not really all that necessary to show.

https://engineering.redhat.com/rt3/Ticket/Display.html?id=111050

> 
> -----
> 
> 1.1.1 Communications
> 
> " The load balancer synchronizes content to the CDS instances, and evenly
> distributes requests. "
> 
> Make this "The RHUA synchronizes content to the CDS instances..."

<para>
	The RHUA synchronizes content to the CDS instances, and evenly distributes requests.
</para>

> 
> -----
> 
> 1.1.2 Certificates
> 
> "This is the only certificate in the PKI..."
> 
> I'd change this to:
> 
> "This is the only certificate in the Red Hat Update Infrastructure PKI..."

<para>
	Content certificates are signed by the Red Hat Certificate Authority (CA). This is the only certificate in the &RHUI; PKI that is not signed by the cloud provider.
</para>

> 
> -----
> 
> 1.1.2 Certificates
> 
> "The entitlement certificate contains entitlements for the products initially
> granted to the cloud provider in the content certificate."
> 
> It's not necessarily _all_ products initially granted. You might want to
> somehow squeeze in there that it's all or a subset of products.

<para>
	Clients use an entitlement certificate when connecting to the load balancer and CDS instances. The entitlement certificate contains entitlements for some or all of the products initially granted to the cloud provider in the content certificate. A client using an entitlement certificate can only get access to channels for which the certificate provides an entitlement.
</para>

> 
> -----
> 
> 1.1.2 Certificates
> 
> "The entitlement certificate is signed by a CA that has been provided by the
> cloud provider. This allows you to generate entitlement certificates for use in
> your environment without having to request them from Red Hat."
> 
> The tone jumps from "the cloud provider" to "you" in these two sentences. In
> (almost) all of this page, it's "the cloud provider", so the "you" sentence
> might need to be restructured.

<para>
	Clients use an entitlement certificate when connecting to the load balancer and CDS instances. The entitlement certificate contains entitlements for some or all of the products initially granted to the cloud provider in the content certificate. A client using an entitlement certificate can only get access to channels for which the certificate provides an entitlement.
</para>

"You" in this book is "the Cloud Provider", so I've changed it to reflect that. Good spot!

> 
> -----
> 
> 1.1.2 Certificates
> 
> "A new SSL certificate must be generated for each instance."
> 
> Might want to rephrase it to indicate that this is an SSL requirement, not a
> RHUI one. Something like "SSL mandates the CN of the certificate match the
> hostname of the server on which it is installed. Therefore, a different
> certificate is required for each CDS and the RHUA itself."
> 
> Remove references to a separate load balancer. Current plans are for it to
> reside on one of the CDS instances and not be its own entity.

<para>
	SSL is used for communicating with the load balancer and CDS instances. SSL requires that a new SSL certificate is generated for each instance. For example, in an environment with three CDS instances, three seperate certificates will need to be generated. The common name (CN) of the certificate must match the hostname of the instance.
</para>



Revision 1-9.

LKB

In 1.1.2 Certificates

The entitlement certificate must be signed by a Certificate Authority (CA). This allows < you >to generate entitlement certificates for use in your environment without having to request them from Red Hat. All requests to the Red Hat Update Infrastructure that test the entitlement certificate will check that it was signed by the CA. This prevents users from spoofing the Red Hat Update Infrastructure with self-signed certificates. 

===  Most of the places its changed to 'the cloud provider' , except the above one.
 
All the changes mentioned for the certificates section are done.

Moving it to verified state, due to comment 1

or may be we can mention initially in the doc something like 

"you" here refers to 'the cloud provider"

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