I am experimenting whether I can check the version of bundle in localhost using ansible-playbook local.yml as shown in local.yml below.
local.yml
---
- hosts: local
remote_user: someuser
tasks:
- name: Check bundle version
shell: "{{ansible_user_shell}} -l -c 'bundle --version'"
args:
chdir: "/path/to/rails/dir"
Inventory file is as follows:
hosts
[local]
127.0.0.1
[local:vars]
ansible_ssh_user=someuser
However I got the error saying,
stderr: zsh:1: command not found: bundle`
I have no idea why I am getting this error because I confirmed bundle is installed on localhost. Also I found that shell module does not use login shell so environmental variables in .zshrc is not loaded so I ran zsh with -l(use login shell) option. But it's not working. Is there anything I am missing?
I figured out the problem by myself. The problem was the configuration of zsh. I thought .zshrc is executed on every login. This is inaccurate because .zshrc is only loaded on login and interactive shell. In the above case, the command is NOT run on interactive shell so .zshrc was not loaded.
To load .zshrc every time I use login shell, I created .zprofile which is loaded on login shell as follows:
# include .zshrc if it exists
if [ -f "$HOME/.zshrc" ]; then
. "$HOME/.zshrc"
fi
Another solution might be to add -i(interactive shell) option :)
Related
I'm unable to run bash scripts in "runcmd:" that aren't inline.
runcmd:
- [ bash, -c, echo "=========hello world=========" >>foo1.bar ]
- [ bash, -c, echo "=========hello world=========" >>foo2.bar ]
- [ bash, -c, /usr/local/bin/foo.sh ]
The first two lines are successfully run on the deployed Ubuntu instance. However, the foo.sh doesn't seem to run.
Here is /usr/local/bin/foo.sh:
#!/bin/bash
echo "=========hello world=========" >>foosh.bar
foo.sh has executable permissions for root and resides on the MAAS server.
I've looked at the following but they don't seem to sort out my issue:
Cannot make bash script work from cloud-init
run GO111MODULE=on go install . ./cmd/... in cloud init
https://gist.github.com/aw/40623531057636dd858a9bf0f67234e8
Any help or tips would be greatly appreciated.
Anything you run using runcmd must already exist on the filesystem. There is no provision for automatically fetching something from a remote host.
You have several options for getting files there. Two that come to mind immediately are:
You could embed the script in your cloud-init configuration using the write-files directive:
write_files:
- path: /usr/local/bin/foo.sh
permissions: '0755'
content: |
#!/bin/bash
echo "=========hello world=========" >>foosh.bar
runcmd:
- [bash, /usr/local/bin/foo.sh]
You could fetch the script from a remote location using curl (or similar tool):
runcmd:
- [curl, -o, /usr/local/bin/foo.sh, http://somewhere.example.com/foo.sh]
- [bash, /usr/local/bin/foo.sh]
I am trying to execute a bashrc function "enableSsh" using ANSIBLE. I am using below ANSIBLE code to get this done but getting error: enableSsh command not found.
- name: Switch to user root and enable ssh
become: yes
become_user: root
become_method: su
shell: . .bashrc && enableSsh
args:
executable: /bin/bash
Note: I tested it removing enableSsh and reloading bashrc is working fine. enableSsh is a function defined in remote server's bashrc file and works fine if execute directly from command line.
This is not an issue with Ansible, this is a shortcoming of the alias command as explained here.
I'm playing with Ansible (still learning), but I encountered a problem I can't think of a solution.
I'm trying to install and launch Tomcat on a remote server using Ansible.
The installation is working, but the last step which is the activation of the Tomcat server is failing.
If I manually launch the startup.sh script (as su -), using the following command : bash /opt/tomcat/startup.sh, I can see the tomcat homepage.
Using the ansible playbook I wrote, even though Ansible doesn't show up any errors, I can't see the tomcat homepage.
Here is the task I'm running :
- name: Launch Tomcat
command: bash /opt/tomcat/startup.sh
become: true
I tried to add become_user: root and become_method: sudo with no success.
I think it may be related to how become: true is handled by ansible but I'm not sure.
Have you also tried using the shell-module instead of the command-module?
With the Command module the command will be executed without being proceeded through a shell. As a consequence some variables like $HOME are not available. And also stream operations like <, >, | and & will not work.
The Shell module runs a command through a shell, by default /bin/sh. This can be changed with the option executable. Piping and redirection are here therefor available.
(Source: https://blog.confirm.ch/ansible-modules-shell-vs-command/)
There might be a problem with the environment. "sudo su" is different from "su -" where
-, -l, --login Provide an environment similar to what the user would expect had the user logged in directly.
Try shell (because it allows pipes, redirection, logical operations, ...) without become: true
shell: su - && bash /opt/tomcat/startup.sh
Make sure remote_user is the same whom the su - command works fine for.
i had the same problem while working with startup.sh in ansible script.i got to know the tomcat server process got starts but immediately shutdown as well.
so the solution to the problem is running or starting the tomcat server in nohup
thru ansible
Here is the sample script.
cat start.yml
---
- name: Playbook to stop server
#hosts: localhost
hosts: webserver
tasks:
- name: Start the server tomcat from UI
shell:
nohup /home/tomcat/bin/catalina.sh start >> /home/tomcat/somelog
I am writing an Ansible playbook to automate a series of sudo commands on various hosts. When I execute these commands individually in puTTY, I have no permission problems, as I have been granted proper access. However, when I attempt to create a playbook to do the same thing, I am told
user is not allowed to execute ... on host_name
For example, if I do $ sudo ls /root/, I have no problem, and, once I enter my password, can see the contents of /root/
In the case of my Ansible playbook ...
---
- host: servers
tasks:
- name: ls /root/
shell: ls /root/
become: true
become_method: sudo
...I then get the error mentioned above.
Any ideas why this would be the case? It seems to be telling me I don't have permission to run a command that I otherwise could run in an individual puTTY terminal.
[ ] automate a series of sudo commands on various hosts. When I execute these commands individually [ ]
Any ideas why this would be the case?
Sounds like you configured specific commands in the sudoers file (unfortunately you did not provide enough details, fortunately you asked for "ideas" not the real cause).
Ansible shell module does not run the command you specify prepended with sudo - it runs the whole shell session with sudo, so the command doesn't match what you configured in sudoers.
Either allow all commands to be run with elevated privileges for the Ansible user, or use raw module instead of shell.
I'm asking myself why Ansible doesn't source ~/.profile file before execute template module on one host ?
Distant host ~/.profile:
export ENV_VAR=/usr/users/toto
A single Ansible task:
- template: src=file1.template dest={{ ansible_env.ENV_VAR }}/file1
Ansible fail with:
fatal: [distant-host] => One or more undefined variables: 'dict object' has no attribute 'ENV_VAR'
Ansible is not running remote tasks (command, shell, ...) in an interactive nor login shell. It's same like when you execute command remotely via 'ssh user#host "which python"'
To source ~/.bashrc won't work often because ansible shell is not interactive and ~/.bashrc implementation by default ignores non interactive shell (check its beginning).
The best solution for executing commands as user after its ssh interactive login I found is:
- hosts: all
tasks:
- name: source user profile file
#become: yes
#become_user: my_user # in case you want to become different user (make sure acl package is installed)
shell: bash -ilc 'which python' # example command which prints
register: which_python
- debug:
var: which_python
bash: '-i' means interactive shell, so .bashrc won't be ignored
'-l' means login shell which sources full user profile (/etc/profile and ~/.bash_profile, or ~/.profile - see bash manual page for more details)
Explanation of my example: my ~/.bashrc sets specific python from anaconda installed under that user.
Ansible is not running tasks in an interactive shell on the remote host. Michael DeHaan has answered this question on github some time ago:
The uber-basic description is ansible isn't really doing things through the shell, it's transferring modules and executing scripts that it transfers, not using a login shell.
i.e. Why does an SSH remote command get fewer environment variables then when run manually?
It's not a continous shell environment basically, nor is it logging in and typing commands and things.
You should see the same result (undefined variable) by running this:
ssh <host> echo $ENV_VAR
In a lot of places I've used below structure:
- name: Task Name
shell: ". /path/to/profile;command"
when ansible escalates the privilige to sudo it don't invoke the login shell of sudo user
we need to make changes in the way we call sudo like invoking it with -i and -H flags
"sudo_flags=-H" in your ansible.cfg file
If you can run as root, you can use runuser.
- shell: runuser -l '{{ install_user }}' -c "{{ cmd }}"
This effectively runs the command as install_user in a fresh login shell, as if you had used su - *install_user* (which loads the profile, though it might be .bash_profile and not .profile...) and then executed *cmd*.
I'd try not to run everything as root just so you can run it as someone else, though...
If you can modify the configuration of your target host and don't want to change your ansible yaml code. You can try this:
add the variable ENV_VAR=/usr/users/toto into /etc/environment file rather than ~/.profile.
shell: "bash -l scala -version"
by using bash -l will allow ansible to load corresponding bash_profile.
bash: '-i' (interactive shell) won't allow the ansible to run other task.
add the variable ENV_VAR=/usr/users/toto into /etc/environment file rather than ~/.profile.
You really can use /etc/environment, but only if a variable has a static value. If we use variable which gets the value of another variable it doesn't work. For example, if we put this line to /etc/environment
XDG_RUNTIME_DIR=/run/user/$(id -u)
Ansible can see exactly XDG_RUNTIME_DIR=/run/user/$(id -u), not XDG_RUNTIME_DIR=/run/user/1012.
And if we put this line to ~/.bash_profile or ~/.bashrc:
export XDG_RUNTIME_DIR=/run/user/$(id -u)
User can see XDG_RUNTIME_DIR=/run/user/1012 (if user's id is 1012) when he works manually, but Ansible doesn't get variable XDG_RUNTIME_DIR at all.