Bug 752963 - RHUI Install Guide corrections/suggestions - Chap 2
Summary: RHUI Install Guide corrections/suggestions - Chap 2
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Update Infrastructure for Cloud Providers
Classification: Red Hat
Component: Documentation
Version: 2.0.2
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ---
: ---
Assignee: Lana Brindley
QA Contact: wes hayutin
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-11-10 21:51 UTC by Karthik Prabhakar
Modified: 2016-10-30 22:52 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-01-29 21:10:56 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Karthik Prabhakar 2011-11-10 21:51:57 UTC
(2.1) Table should include port 443 between CDS and RHUA
   certificate

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

(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

Comment 1 Lana Brindley 2012-01-03 23:32:44 UTC
(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

Comment 2 Jay Dobies 2012-01-06 14:27:08 UTC
>>(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.

Comment 3 Lana Brindley 2012-01-08 21:24:20 UTC
(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

Comment 5 James Slagle 2012-03-12 19:39:26 UTC
Released in RHUI 2.0.2


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