-
Notifications
You must be signed in to change notification settings - Fork 987
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixes #8498 - Add root_pass accessibility to finish scripts #1983
Conversation
[test] |
@TJM Tests are failing, check out the results in jenkins or run |
@elobato : The tests are failing directly in the "develop" branch too. I thought that was a "known issue" ? results from "develop" branch:
|
There aren't any known failures.. those messages don't really show the problem, can you gist the whole lot perhaps? Do check you have organisations+locations enabled in settings.yml, as these are required when running the tests at least (not necessary normally). Else, click the Details link next to "Job result: FAILURE", click the red "foreman", click the # number next to test_develop_pr_core and it shows a list of failed tests. |
Here's the link to the failures in this PR test_develop_pr_core |
Hi @elobato, Sorry about that. I got some help from @ohadlevy Thursday (morning for me), it turns out that the failures I was seeing were related to me running |
[test] |
1 similar comment
[test] |
So, I am guessing that SQL failure was not related to my code :) |
@TJM would you mind rebasing this PR ? thanks |
Hi guys, I think that someone potentially did a git push --force to the "develop" branch, which is what caused this to get all out of whack. It was somewhere around the "rails 3.2.21" stuff. I did have a conflict with the host_managed.rb, which was expected and I fixed that, but I just took the "HEAD" version of the Gemfile because I had not previously changed that. |
[test] |
@@ -19,6 +20,11 @@ oses: | |||
puppet_enabled = pm_set || @host.params['force-puppet'] && @host.params['force-puppet'] == 'true' | |||
%> | |||
|
|||
<% if @host.provision_method == 'image' && ! root_pass.blank? -%> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if @host.provision_method == 'image' && root_pass.present?
is more readable IMHO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agreed! I am still learning what methods are available, I hated "not blank" :)
@ohadlevy - I think this can be merged. |
@@ -19,6 +20,11 @@ oses: | |||
puppet_enabled = pm_set || @host.params['force-puppet'] && @host.params['force-puppet'] == 'true' | |||
%> | |||
|
|||
<% if @host.provision_method == 'image' && ! root_pass.blank? -%> | |||
# Install the root password | |||
echo 'root:<%= root_pass -%>' | /usr/sbin/chpasswd -e |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since chpasswd is in shadow-utils I assume that's going to work, just wondering if there is a version of the os that this wont work, an alternative solution would be:
echo -e "<%=root_pass %>\n<%= root_pass %>" | passwd --stdin root
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am fairly sure that using passwd --stdin
is going to expect the actual password, while chpasswd
actually is expecting the hashed password, which is why I chose that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TJM yep, you are right, scratch that then :)
[test] |
@@ -116,9 +116,9 @@ def crypt_root_pass | |||
end | |||
|
|||
if unencrypted_pass.present? | |||
self.root_pass = unencrypted_pass.starts_with?('$') ? unencrypted_pass : | |||
self.root_pass = !!(unencrypted_pass.match('^\$\d+\$.+\$.+')) ? unencrypted_pass : |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NOTE: this fixes another issue I had with a root password that started with "$" not being hashed. I don't know if there should be a separate bug report for that? (probably)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WIll pull this change out, it needs to be its own issue
@TJM 👍 from my side. Please add a few unit tests and we're all set 😄 ! |
@@ -1,3 +1,4 @@ | |||
#!/bin/bash |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe shebangs are not necessary in this kind of template
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this one will go away with rebase
This fixes the ability to access the root_pass attribute, and ensures that its loaded. It also includes an updated default kickstart template that actually sets the root password on a "image" based install. (with the assumption that the root password will be set by the provision script otherwise so setting it again would be unnecessary). It also fixes the check to see if the password pasted was already hashed. (probably could use some documentation there)
Since the "finish" script will not get loaded automatically, in order to test this, add the following to a finish script for a centos/rhel/fedora based install.. I am not sure if it works on debian or gentoo based images.
This is a resubmit of my previous PR #1982 due to bad commit messages.