The discussion happens all over the list. This is part of that discussion.
On Wed, May 21, 2014 at 10:42 PM, Jeff Geerling <[email protected]>wrote: > That would be perfect—and I understand why it's not good for facts to be > overriding globals. Plus, my use case here is probably not ideal in any way > (though I know of more than few people who don't have the luxury of working > exclusively with providers that allow kickstart configs or any kind of > prebuilt images). > > Is there an issue or some other discussion I could track for set_global. > Someday (I promise!) I'll get some time to start contributing actual > *code* to the project, rather than little docs fixes :P > > -Jeff > > > On Wednesday, May 21, 2014 5:02:10 PM UTC-5, Michael DeHaan wrote: > >> 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/a3b074d0-5f6d-4b57-b841-fc9d13109146%40googlegroups.com<https://groups.google.com/d/msgid/ansible-project/a3b074d0-5f6d-4b57-b841-fc9d13109146%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%2BnsWgym%3Dg2CoHm9eA6GW6G4o8vvqfN%3DQm-DD0zB0k%3Dn6ERVjQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
