So I got quite a bit further, but was ultimately stymied by the fact that I
can't override a playbook/role variable or global variable using the
set_fact module (at least, after 1.5/1.6). Here's the code I had almost
working:
---
- name: Check if we can connect using the normal user.
command: "ssh -oBatchMode=yes {{ admin_user }}@{{ ansible_ssh_host }}
exit"
failed_when: false
changed_when: false
register: ssh_result
connection: local
sudo: no
- debug: var=user_creation_account
- name: Switch user account if necessary.
set_fact: user_creation_account="root"
when: ssh_result.rc != 0
connection: local
sudo: no
- debug: var=user_creation_account
When I run the playbook, it checks if the local host can connect to the
server via the normal admin_user, and if not, it tries to override the
'user_creation_account' variable, which would then be used (defaults to
admin_user elsewhere) for the initial user creation 'remote_user'
configuration.
Unfortunately, 'user_creation_account' remains set to the value in the
included playbook variables file, so it seems my set_fact can't override
that variable :(
For now, I think I'll just stick to one playbook to do initial user setup,
then the normal one for once the accounts/SSH are configured correctly. And
for most other projects, just using DO's droplet API/integration, or AWS
integration, is perfectly adequate and much simpler!
-Jeff
On Tuesday, May 20, 2014 9:15:00 AM UTC-5, Jeff Geerling wrote:
>
> So, I have a playbook set up with remote_user: admin, and the remote
> server only allows 'root' until the admin user is set up. If I add a ping
> task as the first task in the playbook (with failed_when: false
> and gather_facts: no), then I get the following:
>
> PLAY [playbook]
> *****************************************************************
>
>
> TASK: [Check if we can connect using ping module.]
> ****************************
> fatal: [drupal] => SSH encountered an unknown error during the connection.
> We recommend you re-run the command using -vvvv, which will enable SSH
> debugging output to help diagnose the issue
>
> Is there some way, in a playbook, to have a 'pre-pre-task' or a way to
> catch an SSH connection error and set a flag based on that? Basically, I
> don't want to fail after SSH connection error, but attempt to run a
> separate play as root... something along those lines.
>
> Worst case, I'll just keep doing what I'm doing (separate small playbook
> to configure admin user and SSH security that runs as root, and kick that
> playbook off by hand for each server provision). But it would be great if
> it were possible to provision and re-run a playbook on any hosting provider
> (besides the ones with nice APIs or kickstart abilities) with one playbook
> :)
>
> -Jeff
>
>
> On Monday, May 19, 2014 8:50:53 AM UTC-5, Jeff Geerling 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].
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/da689eb9-4a16-43bd-b60f-966ebde281b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
