+++ This bug was initially created as a clone of Bug #1466688 +++

Description of problem:
This used to work with a relative path and I see no reason why it no longer should.
Also, the text color is leaking for some values.

# capsule-certs-generate --foreman-proxy-fqdn="intel-wildcatpass-02.khw.lab.eng.bos.redhat.com" --certs-tar intel-server-02.khw.aaa.bbb.ccc.whatever.com
Parameter certs-tar invalid: intel-server-02.khw.aaa.bbb.ccc.whatever.com is not one of regexes matching /^(([a-zA-Z]:[\\\/])|([\\\/][\\\/Error during configuration, exiting

Version-Release number of selected component (if applicable):


How reproducible:
# rpm -qa satellite
satellite-6.3.0-16.0.beta.el7sat.noarch

Steps to Reproduce:
1. capsule-certs-generate --foreman-proxy-fqdn="intel-wildcatpass-02.khw.lab.eng.bos.redhat.com" --certs-tar intel-server-02.khw.aaa.bbb.ccc.whatever.com

Actual results:
Parameter certs-tar invalid: intel-server-02.khw.aaa.bbb.ccc.whatever.com is not one of regexes matching /^(([a-zA-Z]:[\\\/])|([\\\/][\\\/Error during configuration, exiting

Expected results:
relative path should be supported and the error handling should be way better

--- Additional comment from RHEL Product and Program Management on 2017-06-30 09:15:56 EDT ---

Since this issue was entered in Red Hat Bugzilla, the pm_ack has been
set to + automatically for the next planned release

--- Additional comment from Bryan Kearney on 2017-06-30 11:23:58 EDT ---

Jake to investigate.

--- Additional comment from  on 2017-06-30 14:58:18 EDT ---

New installer documentation recommends using the absolute path.

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

--- Additional comment from Renzo Nuccitelli on 2017-09-13 15:37:08 EDT ---

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

--- Additional comment from Ivan Necas on 2017-09-27 07:27:30 EDT ---

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

--- Additional comment from Ivan Necas on 2017-09-27 09:21:52 EDT ---

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

--- Additional comment from Ivan Necas on 2017-09-27 09:34:50 EDT ---

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

--- Additional comment from pm-sat on 2017-09-27 10:04:45 EDT ---

Upstream bug assigned to inecas

--- Additional comment from pm-sat on 2017-09-27 10:04:50 EDT ---

Upstream bug assigned to inecas

--- Additional comment from Ivan Necas on 2017-09-27 10:24:31 EDT ---

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.

--- Additional comment from Brad Buckingham on 2017-09-27 10:29:28 EDT ---

Since there is work going on in the upstream on this, I am going to devel triage it.  Thanks Ivan!

--- Additional comment from pm-sat on 2017-10-03 14:05:03 EDT ---

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

--- Additional comment from Lukáš Hellebrandt on 2017-10-11 07:59:24 EDT ---



--- Additional comment from Peter Ondrejka on 2017-10-31 05:40:18 EDT ---

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?

--- Additional comment from Stephen Wadeley on 2017-11-15 04:11:32 EST ---

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

--- Additional comment from Peter Ondrejka on 2017-11-20 10:14:19 EST ---

Hi Stephen, 

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

--- Additional comment from Peter Ondrejka on 2017-11-20 10:47:04 EST ---

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.

--- Additional comment from Peter Ondrejka on 2017-12-12 09:14:59 EST ---

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