There has been a discussion about a possible set_global. Facts are less secure (machines may be less trustworthy) and need to stay in a particular lesser scope, so that's why they don't override globals -- a fact could control what software gets installed, etc.
On Tue, May 20, 2014 at 11:36 AM, Jeff Geerling <[email protected]>wrote: > 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<https://groups.google.com/d/msgid/ansible-project/da689eb9-4a16-43bd-b60f-966ebde281b7%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/CA%2BnsWgx_%3D%3DyUoErAACRVOG_sz57SMgJAnj5nxv%2BvHw3%3DEoejiQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
