Bug 752963

(In reply to comment #0)
> (2.1) Table should include port 443 between CDS and RHUA
>    certificate

Is this an extra entry, or an amendment to the existing 443 entry?

> 
> (2.3 step 1) wget needs --no-check-certificate option

I have a sneaking suspicion we've discussed this already somewhere, but I can't recall the definitive answer. Jay, can you please provide guidance?

> 
> (2.3 step 2) Suggested that a separate node be used to create
>    certs outside of RHUA. Keeping the CA cert & private key on
>    the same node as the rhua is a potential security risk
> 
> (2.3 sec 3) Mention change location of certs in Messaging section if
>     non-default location is used
> 
> (2.3 sec 2) RHUA and CDS need to be connected to RHN in order to
>     download/install dependencies. Prefer that complete set of prerequisite
>     packages be made available via installer iso & scripts (or documented
>     so that customer can do base install with these packages)
> 
> (2.3 sec 2) ./install_tools command output mentions the running of
>     rhui_tools from command line - which is no longer required in RHUI 2.0

I'm struggling to make these changes within the existing procedure. Jay, do we need to completely overhaul this procedure?

LKB

>>(In reply to comment #0)
>> (2.1) Table should include port 443 between CDS and RHUA
>>    certificate
>
> Is this an extra entry, or an amendment to the existing 443 entry?

Yes, extra entry. Good pickup. For clarity, here's the row entry:

Port: 443
Protocol: HTTPS
Source: CDS
Destination: RHUA

It's how the CDS downloads content from the RHUA.

>> 
>> (2.3 step 1) wget needs --no-check-certificate option
>
> I have a sneaking suspicion we've discussed this already somewhere, but I can't
> recall the definitive answer. Jay, can you please provide guidance?

This is always going to be a headache for us. I think he's right though. I think the expected way to get the certificate itself is moving to RHSM web (or whatever it's called), but I don't think that provides Red Hat's CA yet. Without Red Hat's CA, wget will say it's not sure it can trust the connection and will abort. The --no-check-certificate option basically says "I appreciate what you're trying to do wget, but I trust these guys so make the connection anyway."

>> 
>> (2.3 step 2) Suggested that a separate node be used to create
>>    certs outside of RHUA. Keeping the CA cert & private key on
>>    the same node as the rhua is a potential security risk

I'm not sure what you mean by a separate node. I'm willing to leave it as is under the rationale that we're not in the business of teaching them basic security; they should know better than to leave those lying around when they are done with them.

> (2.3 sec 3) Mention change location of certs in Messaging section if
>     non-default location is used

I think this is unnecessary. It will be covered by the RHUA config RPM.

> (2.3 sec 2) RHUA and CDS need to be connected to RHN in order to
>     download/install dependencies. Prefer that complete set of prerequisite
>     packages be made available via installer iso & scripts (or documented
>     so that customer can do base install with these packages)

Most of the dependencies are included on the ISO. We can't feasibly include all of them otherwise the ISO will basically turn into a RHEL base channel. The problem is that cloud providers do wacky things with their images and may not include base packages.

I _think_ elsewhere in the docs we mention that the instances must have access to the RHEL base channel. If not, we should add that and it will be a happy medium between not being able to install and including half a billion potential dependencies on the ISO.

> (2.3 sec 2) ./install_tools command output mentions the running of
>     rhui_tools from command line - which is no longer required in RHUI 2.0

Ah bugger, that's a developer bug fix, not docs. Please refile this specific issue as a RHUI bug.

(In reply to comment #2)
> >>(In reply to comment #0)
> >> (2.1) Table should include port 443 between CDS and RHUA
> >>    certificate
> >
> > Is this an extra entry, or an amendment to the existing 443 entry?
> 
> Yes, extra entry. Good pickup. For clarity, here's the row entry:
> 
> Port: 443
> Protocol: HTTPS
> Source: CDS
> Destination: RHUA
> 
> It's how the CDS downloads content from the RHUA.

<row>
	<entry>
		443
	</entry>
	<entry>
		HTTPS
	</entry>
	<entry>
		CDS
	</entry>
	<entry>
		RHUA
	</entry>
	<entry>
		Allows the CDS to download content from the RHUA
	</entry>
</row>

> 
> >> 
> >> (2.3 step 1) wget needs --no-check-certificate option
> >
> > I have a sneaking suspicion we've discussed this already somewhere, but I can't
> > recall the definitive answer. Jay, can you please provide guidance?
> 
> This is always going to be a headache for us. I think he's right though. I
> think the expected way to get the certificate itself is moving to RHSM web (or
> whatever it's called), but I don't think that provides Red Hat's CA yet.
> Without Red Hat's CA, wget will say it's not sure it can trust the connection
> and will abort. The --no-check-certificate option basically says "I appreciate
> what you're trying to do wget, but I trust these guys so make the connection
> anyway."

<screen>
$ wget  --no-check-certificate --certificate=&lt;Content Certificate&gt;\
https://cdn.redhat.com/content/dist/rhel/rhui/server/6/6Server/x86_64/rhui/2.0/iso/RHEL-6.1-RHUI-2.0-LATEST-Server-x86_64-DVD.iso
</screen>

> 
> > (2.3 sec 2) RHUA and CDS need to be connected to RHN in order to
> >     download/install dependencies. Prefer that complete set of prerequisite
> >     packages be made available via installer iso & scripts (or documented
> >     so that customer can do base install with these packages)
> 
> Most of the dependencies are included on the ISO. We can't feasibly include all
> of them otherwise the ISO will basically turn into a RHEL base channel. The
> problem is that cloud providers do wacky things with their images and may not
> include base packages.
> 
> I _think_ elsewhere in the docs we mention that the instances must have access
> to the RHEL base channel. If not, we should add that and it will be a happy
> medium between not being able to install and including half a billion potential
> dependencies on the ISO.

Added: 

<para>
	Ensure all instances have access to the relevant &RHEL; base channel, in order to be able to download the full list of package dependencies.
</para>

Revision 2-16

Karthik, please raise bugs for engineering as requested in Comment 2.

LKB

Released in RHUI 2.0.2