Bug 1313441 - hammer ping prompts for admin password
Summary: hammer ping prompts for admin password
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Hammer
Version: 6.2.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium vote
Target Milestone: Unspecified
Assignee: Andrew Kofink
QA Contact: Katello QA List
URL: http://projects.theforeman.org/issues...
Whiteboard:
Keywords: Regression, Triaged
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-03-01 15:33 UTC by Roman Plevka
Modified: 2019-04-01 20:27 UTC (History)
5 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2016-07-27 11:11:54 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Foreman Issue Tracker 14397 None None None 2016-04-22 14:58 UTC

Description Roman Plevka 2016-03-01 15:33:38 UTC
Description of problem:
issuing `hammer ping` command results in prompting user for admin password and anything submitted for a password is being accepted.
The command then prints the proper ping output

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

How reproducible:
always

Steps to Reproduce:
1. `hammer ping`

Actual results:
# hammer ping
Ignoring ruby-libvirt-0.5.2 because its extensions are not built.  Try: gem pristine ruby-libvirt --version 0.5.2
[Foreman] Password for admin: <someTotallyInvalidPassword>
candlepin:      
    Status:          ok
    Server Response: Duration: 74ms
candlepin_auth: 
    Status:          ok
    Server Response: Duration: 72ms
pulp:           
    Status:          ok
    Server Response: Duration: 155ms
foreman_tasks:  
    Status:          ok
    Server Response: Duration: 29ms



Expected results:
`hammer ping` should not prompt for credentials.

Additional info:

Comment 3 Andrew Kofink 2016-03-07 19:13:06 UTC
Additionally, if you type a valid password, you see ping output for pulp_auth but not for an invalid password.

```
[vagrant@sat-test-rhel7 ~]$ hammer ping
[Foreman] Password for admin: <correct password>
candlepin:      
    Status:          ok
    Server Response: Duration: 42ms
candlepin_auth: 
    Status:          ok
    Server Response: Duration: 37ms
pulp:           
    Status:          ok
    Server Response: Duration: 146ms
pulp_auth:      
    Status:          ok
    Server Response: Duration: 39ms
foreman_tasks:  
    Status:          ok
    Server Response: Duration: 77ms

[vagrant@sat-test-rhel7 ~]$ hammer ping
[Foreman] Password for admin: <incorrect password>
candlepin:      
    Status:          ok
    Server Response: Duration: 58ms
candlepin_auth: 
    Status:          ok
    Server Response: Duration: 32ms
pulp:           
    Status:          ok
    Server Response: Duration: 66ms
foreman_tasks:  
    Status:          ok
    Server Response: Duration: 29ms
```

Comment 4 Andrew Kofink 2016-03-08 18:07:15 UTC
Also, this appears to be reproducible only in upstream but not in downstream (satellite-6.2.0-4.beta.el7sat.noarch).

Comment 5 Brad Buckingham 2016-03-09 11:54:22 UTC
I see the behavior described in comment 3 on the downstream (tfm-rubygem-katello-3.0.0.5-1.el7sat.noarch).

Comment 6 Andrew Kofink 2016-03-09 13:01:48 UTC
(In reply to Brad Buckingham from comment #5)
> I see the behavior described in comment 3 on the downstream
> (tfm-rubygem-katello-3.0.0.5-1.el7sat.noarch).

Yes, you're right. Comment 4 is incorrect; I can reproduce in downstream but not upstream. Here's the upstream behavior:

[vagrant@centos7-devel hammer-cli-katello]$ hammer ping
candlepin:      
    Status:          ok
    Server Response: Duration: 14ms
candlepin_auth: 
    Status:          ok
    Server Response: Duration: 33ms
pulp:           
    Status:          ok
    Server Response: Duration: 39ms
pulp_auth:      
    Status:          ok
    Server Response: Duration: 49ms
foreman_tasks:  
    Status:          ok
    Server Response: Duration: 467ms

Comment 7 Andrew Kofink 2016-03-16 13:44:03 UTC
I'm not sure how to find where this was fixed. I've tried using `git bisect` to go back in time until other things start breaking too much, and I still cannot reproduce this in upstream. Any help would be greatly appreciated.

Comment 8 Brad Buckingham 2016-03-16 15:03:12 UTC
Hi Andrew,  I am able to reproduce this issue on both the upstream and downstream  I suspect the reason we were not seeing it before upstream is that the developer configuration probably has something like the following:

~/.hammer/cli.modules.d/foreman.yaml containing the following:

:foreman:
  :enable_module: true
  :host: 'http://localhost:3000/'
  :username: 'admin'
  :password: 'adminpassword'


With the above, the user will never be prompted for the password.

Do you happen to have a similar configuration on the environment where you are not seeing the password prompted?

Comment 9 Andrew Kofink 2016-03-16 15:12:40 UTC
Yes. I can now reproduce it upstream. Thank you!

Comment 10 Andrew Kofink 2016-03-18 19:53:10 UTC
After some research, it seems that any hammer command which requires authentication by the API will prompt the user. Isn't this desired behavior? If it is desired behavior, then wouldn't this be a new feature rather than a bug? And if we do want to circumvent the prompt for a given command, should we make it an explicit flag? Additionally, I need to know how the system should respond if invalid credentials are provided; in this case, it seems that a partial response may be appropriate, whereas some commands would be completely impossible without authentication.

Comment 11 Andrew Kofink 2016-03-28 15:15:25 UTC
As an example for comment 10, try "hammer organization list" without a password configured. Should this bug affect similar commands?

[vagrant@centos7-devel hammer-cli-katello]$ hammer organization list
[Foreman] Password for admin: 
Invalid username or password

This code resides in hammer-cli-foreman: https://github.com/theforeman/hammer-cli-foreman/blob/master/lib/hammer_cli_foreman/commands.rb#L15

Comment 12 Andrew Kofink 2016-03-30 14:25:45 UTC
Created redmine issue http://projects.theforeman.org/issues/14397 from this bug

Comment 13 Brad Buckingham 2016-03-31 15:27:01 UTC
Andrew, for this one, I would address only the ping command.  I would recommend opening an upstream redmine in the foreman project for the behavior that you found for 'organization list'.  I am not sure it was intended to behave that way.

Comment 14 Brad Buckingham 2016-04-21 15:46:29 UTC
WORKAROUND: Enter the Satellite 6 user's password.

Comment 15 Tomas Strachota 2016-05-18 14:02:13 UTC
Verified with 6.2 snap 11

tfm-rubygem-hammer_cli-0.5.1.6-1.el7sat.noarch
tfm-rubygem-hammer_cli_katello-0.0.22.10-1.el7sat.noarch

Comment 16 Bryan Kearney 2016-07-27 11:11:54 UTC
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/RHBA-2016:1501


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