See special access to buildresources for the detailed policy on access to machines.
If you are not a member of the build working group, open an issue in the build repo for temporary SSH keys. The following instructions are for build working group members.
-
If you have not added your public keys in the secrets repo, follow the instructions there to gain access to the credentials.
-
Copy the SSH keys in the secrets repo to your
~/.sshfolder. What keys are available to you depends on the roles you have. In order to create new vm's and hook them up to CI you have to be part of theinfragroup. See resources for details about the groups. To protect the unencrypted private keys, you can usessh-keygen -p -f ~/.ssh/name_of_private_keyto add a personal passphrase to the local copy of the key. -
Add this section to your
~/.ssh/configfile (if this file does not exist, create one). The configuration for the hosts will be written between the comments:# begin: node.js template # end: node.js template -
Follow the instructions in the ansible guide to install ansible on your local machine.
-
Run
ansible-playbook ansible/playbooks/write-ssh-config.ymlfrom the root of this repo, then the host information will be written into your~/.ssh/config. If you got here from the top-level README.md, you get to this step before getting to the Secrets section, go do that setup. You may get an ERROR, but all the playbook commands were run, check your~/.ssh/configto ensure it was updated with the names of all the machines from inventory.yml. Example "error":
[DEPRECATION WARNING]: DEFAULT_SQUASH_ACTIONS option, Loop squashing is
deprecated and
this configuration will no longer be used , use a list directly with the module
argument instead. This feature will be removed in version 2.11. Deprecation
warnings
can be disabled by setting deprecation_warnings=False in ansible.cfg.
[ERROR]: WARNING: could not find secrets, please define NODE_BUILD_SECRETS
- Try logging into one of the machines that you have access to. In the
~/.ssh/configfile, the first word in theHostindicates the group that the machine is in, and theIdentityFilefor each host can be found in the corresponding folder for the group in the secrets repo. All build working group members can have access to the machines in thetestgroup, so for example, you should be able to log intotest-digitalocean-ubuntu1604-x86-1by runningssh test-digitalocean-ubuntu1604-x86-1directly.
If everything is set up correctly, you should be able to log into
the machine without passwords. By default you will log into the machine
as root (or a sudoer user),
but it is recommended to switch to the iojs user (run su - iojs or
sudo su - iojs for non-root logins) before performing any actions.