New installer documentation recommends using the absolute path.

foreman-proxy-certs-generate --foreman-proxy-fqdn "$FOREMAN_PROXY" --certs-tar "/root/$FOREMAN_PROXY-certs.tar"

Just to add some more info, even absolute path on the form ~/foobar is not working on 6.3 snap 15. While docs have been updated as jcalla mentioned, the above path was present on official docs for 6.2 and bellow: https://access.redhat.com/documentation/en-us/red_hat_satellite/6.2/html/installation_guide/installing_capsule_server

The absolute path with ~ is a known issue in docs: when the path is wrapped in "~", the expansion doesn't happen, the docs BZ is filed here https://bugzilla.redhat.com/show_bug.cgi?id=1470653

Created redmine issue http://projects.theforeman.org/issues/21128 from this bug

The proposed fix is here https://github.com/Katello/katello-installer/pull/542

Upstream bug assigned to inecas

Upstream bug assigned to inecas

Also, ehelms pointed out the upstream already loosened the check on absolute path in the tar https://github.com/Katello/puppet-certs/commit/970a188e0b78f53e724ab0cfd602b50411d1128e#diff-6f053bc2767af0a9bee2ae428e2d64d9 

I think there were reasons why we had there a check on absolute path in the first place, therefore expanding in the pre_validations might be a better approach, but I would be probable ok with both of them.

Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/21128 has been resolved.

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

Also happens on satellite-installer --scenario capsule, which in turn affects satellite-change-hostname on capsule, so there is probably more tweaking to be done in docs. Wouldn't it be just better to make those tools accept relative paths, as everyone is used to this behavior from 6.2?

Hello Ivan and Peter

Re: the tilde

We have been removing all quotation marks from paths and commands when not strictly required.

I think we can *just drop* the `~/` and *not* replace it with `/root` in the guides.

We say the commands should be run as root and when you log in your are in the root user's home directory.

If the reader follows the instructions as we write them then it will just work.

What do you think?


Thank you

Hi Stephen, 

yes, now that we have the fix applied, it is ok to have just the file name supplied to --certs-tar

When running on Sat 6.3 snap 25, --certs-tar accepts relative path as expected:

# capsule-certs-generate --foreman-proxy-fqdn ibm.example.com --certs-tar ibm.example.com-certs.tar
Installing             Done                                               [100%] [............]
  Success!
ATTENTION. For Capsule upgrades:
  Please see official documentation for steps and parameters to use when upgrading a 6.2 Capsule to 6.3.

  To finish the installation, follow these steps:

  If you do not have the Capsule registered to the Satellite instance, then please do the following:

  1. yum -y localinstall http://lenovo.example.com/pub/katello-ca-consumer-latest.noarch.rpm
  2. subscription-manager register --org "Default_Organization"

  Once this is completed run the steps below to start the Capsule installation:

  1. Ensure that the satellite-capsule package is installed on the system.
  2. Copy the following file /root/ibm.example.com-certs.tar to the system ibm.example.com at the following location /root/ibm.example.com-certs.tar
  scp /root/ibm.example.com-certs.tar root.com:/root/ibm.example.com-certs.tar
  3. Run the following commands on the Capsule (possibly with the customized
     parameters, see satellite-installer --scenario capsule --help and
     documentation for more info on setting up additional services):

  satellite-installer --scenario capsule\
                      --foreman-proxy-content-parent-fqdn           "lenovo.example.com"\
                      --foreman-proxy-register-in-foreman           "true"\
                      --foreman-proxy-foreman-base-url              "https://lenovo.example.com"\
                      --foreman-proxy-trusted-hosts                 "lenovo.example.com"\
                      --foreman-proxy-trusted-hosts                 "ibm.example.com"\
                      --foreman-proxy-oauth-consumer-key            "zDFne2NBV8PMqPFSir73wxVQt9akYFko"\
                      --foreman-proxy-oauth-consumer-secret         "uQAJ54yxpLCS7sUgV26oumgAJLKJ9kho"\
                      --foreman-proxy-content-pulp-oauth-secret     "pkR7t9eERtcDTQYUeVA6HWBwtRqWrZG7"\
                      --foreman-proxy-content-certs-tar             "/root/ibm.example.com-certs.tar"\
                      --puppet-server-foreman-url                   "https://lenovo.example.com"
  The full log is at /var/log/foreman-proxy-certs-generate.log


imho the scp target in the instruction step 2. is bit too verbose, just "root.com:" would have the same effect, but that's a nitpick. I'm not able to install capsule using the generated command, but that is probably due to https://bugzilla.redhat.com/show_bug.cgi?id=1243566, therefore keeping this one on_qa until 1243566 resolves.

Verified again on 6.3 snap 28, changing status as the blocking bug has been also verified

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

Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA.
> > 
> > For information on the advisory, and where to find the updated files, follow the link below.
> > 
> > If the solution does not work for you, open a new bug report.
> > 
> > https://access.redhat.com/errata/RHSA-2018:0336