[Gluster-infra] Root password reset on slave21.cloud.gluster.org

[Justin Clift]

On 20 Mar 2015, at 18:56, Michael Scherer <mscherer at redhat.com> wrote:
> 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:
>> 
>>    http://build.gluster.org/job/reboot-vm/
>>    https://github.com/justinclift/glusterfs_patch_acceptance_tests/blob/master/rax-reboot/reboot-slave.py
>> 
>> Resetting the root password seems pretty simple:
>> 
>>    http://docs.rackspace.com/servers/api/v2/cs-devguide/content/Change_Password-d1e3234.html
>> 
>> 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
> slave :
> 
> # 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
> backdoor )
> 
> So I think we can and should do better.

Yep. :)


> But first, let's finish the automation.

Yep. :)

+ Justin

--
GlusterFS - http://www.gluster.org

An open source, distributed file system scaling to several
petabytes, and handling thousands of clients.

My personal twitter: twitter.com/realjustinclift