Bug 1275128

This is done for async and will be ready for QA after I merge bz1209202

This was partly done and reviewed as part of 1209202, but there's more to do so I'm going to leave it open. Unlikely to get more done for async; I'll see how time goes.

modified:   en-US/Example_Curl_Upload.xml

s/50.000/50,000/ when referring to byte size in "Complete Example of Uploading Content"

Etherpad updated with start of revised ToC.

Assigning Russell as the QA contact.

Note that Chapt 4 is actually chapter 3 now, due to work on some other bugs.

Red Hat Satellite uses HTTPS ⁠[1] over SSL, which provides a degree of encryption and identity verification when communicating with a Red Hat Satellite Server.

Isn't this an option, rather than a blanket statement? You can turn off SSL whenever you like.

Procedure 2.1. Obtaining a Certificate
Step 2: # grep -r "SSLCertificateFile" /etc/httpd/conf.d but then there is a note that says "The default location of self-signed certificates is usually /var/www/html/pub/katello-server-ca.crt." Why include this seemingly conflicting info?


Also, at the end of the section: "This imports the certificate into the Network Security Services (NSS) database, which means you can omit the --cacert option for each request."

Example request using and not using --cacert option?

Section 2.1 Using SSL Authentication
Use   the following command to permanently include the certificate in the curl CA store: 

# certutil -d sql:$HOME/.pki/nssdb -A -t TC -n "Red Hat   Satellite" -i /path/to/ca-cert-file 

Shouldn't that read something like "to include the certificate in the CA store that curl can access"? Does curl have a CA store?

(In reply to David O'Brien from comment #17)
> Red Hat Satellite uses HTTPS ⁠[1] over SSL, which provides a degree of
> encryption and identity verification when communicating with a Red Hat
> Satellite Server.
> 
> Isn't this an option, rather than a blanket statement? You can turn off SSL
> whenever you like.

Non-SSL communications are not supported by Satellite 6.

(In reply to Adam Price from comment #20)
> (In reply to David O'Brien from comment #17)
> > Red Hat Satellite uses HTTPS ⁠[1] over SSL, which provides a degree of
> > encryption and identity verification when communicating with a Red Hat
> > Satellite Server.
> > 
> > Isn't this an option, rather than a blanket statement? You can turn off SSL
> > whenever you like.
> 
> Non-SSL communications are not supported by Satellite 6.

Hi Adam

I know I'm being pedantic now, but is that "not supported (by RH)" or "doesn't work"?

I ask because ⁠section "3.2.1. Creating Objects Using Ruby" is followed by a warning:
"This script does not use SSL communication for interacting with the REST API and is provided here only as a demonstration."

thanks

Comment 18 and Comment 19 are still need-info.

(In reply to David O'Brien from comment #21)
> (In reply to Adam Price from comment #20)
> > (In reply to David O'Brien from comment #17)
> > > Red Hat Satellite uses HTTPS ⁠[1] over SSL, which provides a degree of
> > > encryption and identity verification when communicating with a Red Hat
> > > Satellite Server.
> > > 
> > > Isn't this an option, rather than a blanket statement? You can turn off SSL
> > > whenever you like.
> > 
> > Non-SSL communications are not supported by Satellite 6.
> 
> Hi Adam
> 
> I know I'm being pedantic now, but is that "not supported (by RH)" or
> "doesn't work"?
> 
> I ask because ⁠section "3.2.1. Creating Objects Using Ruby" is followed by a
> warning:
> "This script does not use SSL communication for interacting with the REST
> API and is provided here only as a demonstration."
> 
> thanks

It looks like in your draft the text reads 'This script does not use SSL verification...' for both the python and ruby scripts. So SSL is still being used for communication, it's just that the scripts aren't verifying the server. It isn't possible to write a script against Satellite's API that does not use SSL.

(In reply to David O'Brien from comment #18)
> Procedure 2.1. Obtaining a Certificate
> Step 2: # grep -r "SSLCertificateFile" /etc/httpd/conf.d but then there is a
> note that says "The default location of self-signed certificates is usually
> /var/www/html/pub/katello-server-ca.crt." Why include this seemingly
> conflicting info?
> 
> 
> Also, at the end of the section: "This imports the certificate into the
> Network Security Services (NSS) database, which means you can omit the
> --cacert option for each request."
> 
> Example request using and not using --cacert option?

I think it would make more sense to instruct the user to curl/wget a cert for the Satellite they're trying to communicate with from http://satellite.server.com/pub/katello-server-ca.crt rather than mentioning odd ways to get at the cert from multiple locations.

(In reply to David O'Brien from comment #19)
> Section 2.1 Using SSL Authentication
> Use   the following command to permanently include the certificate in the
> curl CA store: 
> 
> # certutil -d sql:$HOME/.pki/nssdb -A -t TC -n "Red Hat   Satellite" -i
> /path/to/ca-cert-file 
> 
> Shouldn't that read something like "to include the certificate in the CA
> store that curl can access"? Does curl have a CA store?

Yes, you're correct. That is not a CA-store owned by curl, but rather it is one that curl can access to verify hosts that lives in your $HOME. I tried this myself just to double-check that I could then curl without needing the -k option afterwards.

# create a new DB if you don't already have one
$ certutil -N -d sql:$HOME/.pki/nssdb

$ certutil -d sql:$HOME/.pki/nssdb -A -t TC -n "Red Hat Satellite" -i /path/to/ca-cert

$ curl -X GET -u admin:changeme https://satellite6.example.com/api/v2/hosts
{
  "total": 2,
  ...,
  "results": [
    ...
  ]
}

success!

*** Bug 1280172 has been marked as a duplicate of this bug. ***

Russell,
I'm going to take Comment #25 out of here and raise it separately to avoid making this branch any more complex than it is.

Comment #28 fixed and added to MR.

Thanks Russell.

This content is now live on the Customer Portal.

Closing.