[Gluster-infra] Root password reset on slave21.cloud.gluster.org
mscherer at redhat.com
Fri Mar 20 18:56:54 UTC 2015
Le vendredi 20 mars 2015 à 18:44 +0100, Niels de Vos a écrit :
> On Fri, Mar 20, 2015 at 01:16:10PM -0400, Dan Lambright wrote:
> > Im done with it. Im using slave48 now.
> > It would be good if this was more self service. For example, I can
> > disconnect a slave after logging into jenkins, but cannot login to the
> > slave without knowing its root password. It appears one necessary step
> > in the process is to reset the root password, and find Justin and
> > Nieles for to do that. Could this process be simplified? e.g. a Groovy
> > script, or some such?
> We actually could setup a Jenkins job to reset the root password of
> slaves. A similar thing is done for rebooting stuck VMs:
> Resetting the root password seems pretty simple:
> I might look into doing that over the weekend. But, in case someone
> wants to have a go at it, please let me know :-)
Ideally, we could also start to use ssh keys, and I can distribute the
key with salt
( technically, i can also reset the root password by salt, and I think I
am gonna work on that next week ).
I also managed to have a almost fully automated deployment of a jenkins
# salt-cloud -p jenkins_2 slave83.cloud.gluster.org
# salt slave83.cloud.gluster.org state.highstate
Only things missing are :
- setting various passwords ( root/jenkins ) and the ssh keys
- adding the slave to jenkins automatically ( not sure how to do or if
we want that, to be fair )
- setting the IP address in the DNS ( requires to code a bit, either in
salt directly, or outside of salt ).
Then I guess we could go on deploying freeipa/ldap and then I would
propose to have account for people, so granting the access is just
"create the account in freeipa, place people in the right group" and ssh
keys will be deployed, etc.
I do not like giving the password to everybody since
- that's a pain to change ( since we do not keep track of who have it )
- we have no log of who connected and what they did
- we have to send it in cleartext ( so a 3 letter US agency could just
use it for nefarious purpose, like for example modifying the binary
artefacts like http://build.gluster.org/job/glusterfs-rpms/ to hide a
So I think we can and should do better.
But first, let's finish the automation.
Open Source and Standards, Sysadmin
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: This is a digitally signed message part
More information about the Gluster-infra