Running service with systemd as default user via ansible in ec2 (requests password)

Question

I'm trying to employ the following Ansible script (part of a playbook) to run unicorn via systemd for a rails app on EC2 (micro) instance:

---

- name: restart unicorn
  command: psql -h {{ db_host }} -U {{ db_user }} -d {{ db }} -c "SELECT true FROM pg_tables WHERE tablename = 'order_cycles';"
  register: table_exists
  ignore_errors: yes
  sudo: yes
  sudo_user: "{{ unicorn_user }}"
  notify: restart unicorn step 2

#TODO make sure both of these things run as one handler.
- name: restart unicorn step 2
  service:
    name: unicorn_{{ app }}
    state: restarted
  when: table_exists.stderr.find('does not exist') == -1
  # If unicorn isn't actually started yet we probably need this:
  notify: start unicorn

- name: start unicorn
  service:
    name: unicorn_{{ app }}
    state: started

The user configured in the playbook is ubuntu, the default (EC2) user and I'm hitting an Interactive authentication required error there, so I'm just trying to troubleshoot directly in the command line of the deploy-to server and have come upon this roadblock.

I can run it as sudo:

$ sudo systemctl start unicorn_myapp.service

Either directly via the server's command line, or by using Ansible's raw method, which succeeds.

But then the rails server, being run by user ubuntu can't access it (at least that's an avenue I'm exploring for cause of .sock failed (111: Connection refused error).

If I run it without sudo, a password is requested, but as far as I can tell, EC2 ubuntu user runs without a password.

I know that a workaround might be to create a new user with password and run rails and systemctl/unicorn as that user, but I don't think that's the actual answer to this problem, even more so since the playbook's developer recently removed the user_password from the playbook altogether for security reasons.

If I can figure out how to run systemd as a non-root user at all, maybe I can figure out how to make Ansible succeed at it.

Of course it's also not unlikely that I'm approaching it from the wrong angle in the first place, as I'm fairly new to pretty much everything this scenario involves.

Answer 1

If you have global sudo, add become: no to the two tasks that do not require sudo privs.