The main difficulty I foresee, though, is that I want to use remote_user: "admin" normally—but that user won't exist on the first run (many of the providers I use—LEB-type providers—don't have the ability to use kickstart or anything like that... they just provision a VM with whatever image they have laying around :().
In this case, the first run would fail unless I manually change remote_user for the entire playbook to 'root' and then use 'user' for every included playbook/role/task to set the user for the particular play. Or is there a conditional way, using gathered facts or something, to attempt to log in via the normal remote_user, and if that fails, drop to root? On Monday, May 19, 2014 9:14:11 AM UTC-5, Michael DeHaan wrote: > > > There is of course the "user" keyword on a play to change users. You can > have multiple plays in one playbook (and each can include lists of plays > from other files, or can just be a list of them) so you don't need to > launch ansible-playbook three times. > > (If using a cloud provider, what you really should do is look into the > provisioning modules, and have a play to bring up new resources that also > includes your list of configuration plays) > > If using physical setups, you can do some basic configuration in > kickstart/preseed, so your base systems come up correctly at the end of the > install process. You could even use ansible inside the installation > environment to do this. > > > > On Mon, May 19, 2014 at 9:50 AM, Jeff Geerling > <[email protected]<javascript:> > > wrote: > >> When I order a new server from a hosting provider which doesn't have >> images like AMIs or user-created Images, I generally get a minimal OS >> installation and a root user account. >> >> The first thing I need to do on the server, before I can start securely >> configuring the server from an admin user account, and deploying an app to >> that server, is to *create* the admin user account with which I'll do >> the rest of the work, and then disable password-based login and root SSH >> access. >> > > > >> >> Currently, I have two separate playbooks to accomplish these two separate >> tasks (first setting up the server/security minimally, second configuring >> the server and deploying an app). >> >> Are there any better ways of doing this? Basically, I'd like to have a >> way of saying "if this is a new server/my admin user can't connect, first >> run this set of plays as the root user, then continue on as the normal >> remote_user". >> >> Using Digital Ocean or AWS makes this a bit easier, as I can use Packer >> and create an initial image that already has the minimal base >> configuration... but I manage a lot of hosts from a lot of providers, and >> usually don't have a way to manage fresh images. >> >> -- >> 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] <javascript:>. >> To post to this group, send email to [email protected]<javascript:> >> . >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/ansible-project/ae22b634-63ea-4335-8577-1f75c8f5aaa4%40googlegroups.com<https://groups.google.com/d/msgid/ansible-project/ae22b634-63ea-4335-8577-1f75c8f5aaa4%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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/0be9da3f-dbbc-48a5-ba77-3ef530918eae%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
