FAQ
Do you actually need to detect at all?
your first play, which sets up the admin user, could run every time. If set
up to be properly idempotent then would you need to test for anything?

I am facing a similar issue. I would like a play to set up a user and a
second play (in the same book) to start doing things as the created user.
So far I have tried the following:

---
- name: create user with an ssh key in authorized_keys
   hosts: testMachine
   sudo: True
   vars:
     userName: 'auser'
   roles:
      - { role: creatUser, userName: "{{ userName }}" }

- name: use the new user to install required stuff
   hosts: testMachine
   remote_user: auser
   roles:
      - moreConfigWithAUser

I invoke this playbook using -kK so that it is able to connect and create
the new user. But what appears to happen is that the second play fails to
use the public key and re-uses the ssh password I previously provided,
which obviously is not correct for this user as no password is set. Am I
going about this wrong or am I just missing a crucial config item somewhere?
On Tue, May 20, 2014 at 11:36 AM, Jeff Geerling 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 ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
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 ansible-proje...@googlegroups.com <javascript:>.
To post to this group, send email to ansible...@googlegroups.com
<javascript:>.
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 ansible-project+unsubscribe@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/e92eb820-9c10-431b-ad39-7727e795a9eb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Mark Casey at Jul 10, 2014 at 11:07 pm
    Do you actually need to detect at all?

    If you want to be able to remove the original access (ssh as root, or
    perhaps a default user like 'ubuntu') then yes, I'd think you have to know
    whether the change has already been made or not. If you just want to add
    access, and not revoke the initial method, then perhaps no detection is
    necessary.

    Anyway I think I may have just gotten this sorted for my own setup using a
    lot of the ideas here. Just did it today so I'd call it pre-alpha. Any
    suggestions for improvement welcome:

    (We have a role for each IAAS provider we use, so these tasks come after
    the local_action call to the ec2 module, in our 'ec2add' role. This seems
    to be working with multi-instance calls (exact count>1) to the ec2
    module...)


    - name: Attempt SSH as initialUser - succeeds only if user customization
    not yet done (also adds private IP(s) to known_hosts, when succeeds)
    shell: "ssh -o StrictHostKeyChecking=no -i ../ssh/{{ key_name }} {{
    initialUser }}@{{ item.private_ip }} 'exit'"
    with_items: ec2.tagged_instances
    when: wait == "yes"
    ignore_errors: yes
    register: ssh_attempt

    - name: Add instance(s) still requiring user customization to
    'host_users_customized_False' group
    local_action: add_host hostname={{ item.item.private_ip }}
    groupname="host_users_customized_False"
    with_items: ssh_attempt.results
    when: wait == "yes" and item.rc == 0

    - name: Re-SSH as initialUser using private DNS name(s) instead of IP(s),
    to also add them to known_hosts (skips if first attempt failed)
    shell: "ssh -o StrictHostKeyChecking=no -i ../ssh/{{ key_name }} {{
    initialUser }}@{{ item.item.private_dns_name }} 'exit'"
    with_items: ssh_attempt.results
    when: wait == "yes" and item.rc == 0
    ignore_errors: yes
    Then in a later playbook I just target the group of hosts whose users
    aren't yet customized (union'ed to a serverGroup sort of ec2 tag group, to
    prevent friendly fire).

    -Mark

    On Friday, July 4, 2014 10:04:43 AM UTC-5, Adam Downer wrote:

    Do you actually need to detect at all?
    your first play, which sets up the admin user, could run every time. If
    set up to be properly idempotent then would you need to test for anything?

    I am facing a similar issue. I would like a play to set up a user and a
    second play (in the same book) to start doing things as the created user.
    So far I have tried the following:

    ---
    - name: create user with an ssh key in authorized_keys
    hosts: testMachine
    sudo: True
    vars:
    userName: 'auser'
    roles:
    - { role: creatUser, userName: "{{ userName }}" }

    - name: use the new user to install required stuff
    hosts: testMachine
    remote_user: auser
    roles:
    - moreConfigWithAUser

    I invoke this playbook using -kK so that it is able to connect and create
    the new user. But what appears to happen is that the second play fails to
    use the public key and re-uses the ssh password I previously provided,
    which obviously is not correct for this user as no password is set. Am I
    going about this wrong or am I just missing a crucial config item somewhere?
    On Tue, May 20, 2014 at 11:36 AM, Jeff Geerling 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 ansible-proje...@googlegroups.com.
    To post to this group, send email to ansible...@googlegroups.com.
    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 ansible-proje...@googlegroups.com.
    To post to this group, send email to ansible...@googlegroups.com.
    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 ansible-project+unsubscribe@googlegroups.com.
    To post to this group, send email to ansible-project@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/138681dd-b6dc-4f47-ba15-82b4313f80ba%40googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupansible-project @
postedJul 7, '14 at 1:55a
activeJul 10, '14 at 11:07p
posts2
users2

2 users in discussion

Mark Casey: 1 post Adam Downer: 1 post

People

Translate

site design / logo © 2022 Grokbase