I simply have solved one small inconvenient difficulty I were traumatic approximately for a while. after I create a new instance, there may be a unique ‘cloud’ user. On maximum distribution username is about to distro call: ‘ubuntu’ for Ubuntu, ‘debian’ for Debian, ‘centos’ for Centos, ‘Administrator’ for home windows (as usual, home windows has very own quicks in the whole lot). Such user configured to simply accept precise ssh key, that is provided for the time being of an instance introduction.
To make all disto identical, we (servers.com) set default username to be ‘cloud-user’, however it’s no longer crucial for this subject matter. while Ansible <https://tekslate.com/ansible-training/> run it playbook in opposition to stock, it want to recognize which person to use for every server. There are approaches to offer it: Magic in ~/.ssh/config. Very bad idea for production — this file is stored outside of git and if you lost your laptop, you couldn’t run your configuration even if you replace your ssh key on all servers (never ‘recover’ ssh key after loosing a laptop!) ansible_ssh_user Ansible variable We opt out for second option, but there is another problem. *A problem* we've a couple of character jogging Ansible towards manufacturing servers. simply, we've both people and robots. each has own ssh key and own user in each server (those customers are controlled with the aid of Ansible). whilst we specify ansible_ssh_user in the inventory, it lets in get admission to handiest to user whom key became supplied at the instance advent time. In other phrases: if I created a server it permits access best to me. moreover, in servers.com ssh keys for servers (actual baremetal servers) are treated in a equal manner. If inventory document appear to be this: ... then handiest author of those servers may want to run Ansible against them. There are clumsy solutions: First: upload anyone’s keys into .ssh/authorized_keys of that first consumer. safety/stupid-typo-in-sudo audit cries with bloody tears as though some thing occurs you have no idea whom to blame. 2d solution: run Ansible once, then eliminate ansible_ssh_user from stock. but this is clumsy, as you want to exchange things in a document which is shared between users and which at sure moment prevents the ones users to have get entry to to servers. (I remember that I may also avoid commiting adjustments, and so on, but where should I shop the ones modifications when I pass domestic at the stop of a piece day and i didn’t end paintings on new servers? common sense says ‘keep you modifications in a git, in a separate department’. however this is too much work to do with many branches, and devote history looks ugly. And if one decide to apply squash for commits, then matters may additionally turn out to be even extra complicated. *Answer* irrespective of been trivial, following line allows a lot. All new servers are declared in an stock with out specifying person. whilst ‘provision user’ run Ansible in opposition to them first time, it specifies ansible_ssh_user from command line: ansible-playbook -i hosts website online.yml -e 'ansible_ssh_user=cloud-consumer' That’s it. Git log clean, anybody have access. *Complications* There are complications: If there are one of a kind users for extraordinary servers (root, cloud-person, distro call), the ones need to be run with --limit parameter. I nonetheless hesitated if I need to take away ‘cloud-user’ from provisioned machine or now not. On one hand ‘cloud-user’ is honestly stated in credentials as an example in portal.servers.com, alternatively I locate it complex within the case if ‘provisioned person’ leaves organisation or simply unfastened get admission to to the project. inner safety voice informed me that I want to lock preliminary provision account, however inner disaster recovery voice says me that account outdoor of Ansible control <https://tekslate.com/> is a good component to have if someone screw with playbooks and we free everyday get admission to to servers. For now it’s only a documented motion: replace ssh key for provision consumer if there's trade in stuffing. I seriously hesitate to place it into everyday Ansible playbooks <http://docs.ansible.com/ansible/playbooks.html> as I assume that mission availability is as vital as its security. can be a separate ansible playbook just for this purposes might be first-rate, however again, automation on restoration bills seems kinda dangerous. -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/07fb3d67-3202-4bcc-a035-e8571d96de21%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
