Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionSergio Ocón-Cárdenas
2015-05-20 08:24:29 UTC
Description of problem:
If you install using the answers file, the first time the admin password can't be set.
Once you run katello-installer, a random one is created.
If you then update the asnwers file to include a password, the installer does not update it, but the final information given by the installer is the new password and not the old one (the real one)
Version-Release number of selected component (if applicable):
6.1.0 beta
How reproducible:
Always
Steps to Reproduce:
1. katello-installer
2. update answers file with new admin password
3. katello-installer
Actual results:
Admin password is the random one generated in step 1 (that you updated and thus lost)
Expected results:
Admin password is updated to the new password. An options to not update the passwrod is included in the passwrod file. original answers file inclused admin passwrod field.
Additional info:
Comment 1RHEL Program Management
2015-05-20 08:32:24 UTC
Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.
Since we have the `foreman-rake permissions:reset`, is it really necessary to spend time on this one?
To me it makes more sense for it to be more difficult to blow away the admin password on the Satellite. (i.e. not in the open)
Since its simply updating the answers file and reading from it, I understand the incorrect listing of the password after the second installer run.
I already think its silly honestly to allow a user to specify a starting admin password on the command line for the installer. (Why would we want to let the user pass a password to the shell history?)
It make a lot more security sense to force someone to login with the hash provided and change the password after that.
There are several other applications that use methods like this.
Thank you for your interest in Satellite 6. We have evaluated this request, and we do not expect this to be implemented in product in the foreseeable future. We are therefore closing this out as WONTFIX. If you have any concerns about this, please feel free to contact Rich Jerrido or Bryan Kearney. Thank you.