<div dir="ltr">Thanks!<div><br></div><div>BTW. I just noticed that every user on vms created with Vagrant is in fact admin... one can always<br>```<br>su - vagrant<br>```</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 6 October 2016 at 20:30, Laurențiu Păncescu <span dir="ltr"><<a href="mailto:lpancescu@gmail.com" target="_blank">lpancescu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Rafal,<br><div><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Thu, Oct 6, 2016 at 5:57 PM, Rafal Skolasinski <span dir="ltr"><<a href="mailto:r.j.skolasinski@gmail.com" target="_blank">r.j.skolasinski@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span style="font-size:12.8px">Thanks for detailed information! I am using playbooks to create vms on a remote host and then I want to run another playbook to configure them.</span></div></blockquote><div><br></div></span><div>For me, the most amazing feature of Vagrant was to be able to use just one Vagrantfile to control both local development VMs, to production servers, and to change from one to the other with just one command. There are Vagrant plugins for pretty much every provider with an API: big "cloud" providers like AWS, Google Cloud or Azure, VPS hosters like Digital Ocean, Vultr or Linode, and also other cloud solutions like OpenShift, OpenStack and CloudStack. You can also use the libvirt plugin with both local and remote servers, it comes with plugins for most virtualization providers and Docker, and there's even a plugin for dedicated servers (when there's no API for controlling their creation and destruction). Being able to do:<br><br></div><div>vagrant up --provider virtualbox<br></div><div>vagrant up --provider aws<br></div><div>vagrant up --provider digitalocean<br><br></div><div>and move seamlessly between providers, provisioning everything with Ansible, is just priceless. I wouldn't go back to plain Ansible and writing dynamic inventory scripts.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span style="font-size:12.8px">I want to enable password authentication only for a moment of initial configuration and then disable it again - I believe this should[n't] cause any security risk.</span></div></div></blockquote><div><br></div><div>The risk is small, but not zero. If someone's script hits your server in a critical moment, your server becomes his.  This is not just theoretical: during Blaster (a Windows worm), a former colleague had installed Windows 2000 more than 12 times, and went directly to download the hotfix from Microsoft, which took less than a minute - and got infected every single time. And I've heard people complaining about getting hacked in the first 5 minutes after imaging a new Linux VPS, before they had the time to disable password logins (they had chosen their own passwords - apparently not that unique). But that's for you to decide - good luck! :)<br><br></div><div>Best regards,<br></div><div>Laurențiu<br></div></div></div></div></div>
<br>______________________________<wbr>_________________<br>
CentOS-devel mailing list<br>
<a href="mailto:CentOS-devel@centos.org">CentOS-devel@centos.org</a><br>
<a href="https://lists.centos.org/mailman/listinfo/centos-devel" rel="noreferrer" target="_blank">https://lists.centos.org/<wbr>mailman/listinfo/centos-devel</a><br>
<br></blockquote></div><br></div>