google.com/d/msgid/ansible-project/aaf25e0e-0210-4ab7-bb45-16835e26f824%40googlegroups.com
> <https://groups.google.com/d/msgid/ansible-project/aaf25e0e-0210-4ab7-bb45-16835e26f824%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://
PEBKAC! Accidentally erased a sudo: yes line on that role in my play book. #fail
--
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+unsubscr...@g
Simple code below has been working for about a week, randomly at work (and
now at home) I've been getting the following error. Originally the
commented line was present and produced the following error, but the below
error may be the bigger culprit:
Code being executed:
# Detect apr
- s
If it helps at all I've updated the Gist to include an example of a
non-root user via sudo with the raw module that works for comparison as
well:
https://gist.github.com/stevenhaddox/d497727deffa65b1a5e1
So... logging in and running modules directly as myself works, and via sudo
to a non-root
Alright, here goes nothing. I had to retype this by hand so forgive any
typos...
https://gist.github.com/stevenhaddox/d497727deffa65b1a5e1
Thanks for any ideas,
Steven
--
You received this message because you are subscribed to the Google Groups
"Ansible Project" group.
To unsubscribe from th
RC. Unfortunately making it
>> executable worked as far as the permissions change didn't make any
>> difference in the module returning any results (which I was able to see
>> it's being called via system python directly so it really shouldn't have).
>>
it's being called via system python directly so it really shouldn't have).
Now I have no clue why it's just hanging after being invoked...
On Thursday, December 12, 2013 12:06:32 PM UTC-5, Steven Haddox wrote:
>
> It also appears to run properly when I run:
>
> $ pytho
/usr/bin/python
-Steven
On Thursday, December 12, 2013 11:57:01 AM UTC-5, Steven Haddox wrote:
>
> This is ansible 1.4.1
>
> My user authenticates via key-based SSH connection without a password.
>
> On Thursday, December 12, 2013 11:55:15 AM UTC-5, Brian Coca wrote:
>>
&g
Due to the joys of Enterprise security, it appears that ansible is hanging
(literally just sits until I Ctl+C like 10 minutes later) when trying to
run any modules besides raw.
So for an example of a working command:
$ ansible all -i -m raw -a "whoami; hostname" -u
myself -s -U sudo_user -v
This is ansible 1.4.1
My user authenticates via key-based SSH connection without a password.
On Thursday, December 12, 2013 11:55:15 AM UTC-5, Brian Coca wrote:
>
> A fix was added to explicitly chmod the file when using sudo to a non root
> user, check version, this should be fix in current sta
permissions changed after each upload
or if there's even a way I can upload the modules myself and change the
permissions on them and have ansible use the pre-uploaded modules somehow?
Thanks again,
Steven
On Thursday, December 12, 2013 11:47:46 AM UTC-5, Steven Haddox wrote:
>
> Due to
I'm getting a really weird / hard to interpret error from the unarchive
module with Ansible 1.4.1. The following code:
#provisioning/roles/common/tasks/upload_src.yml
# Set src filename
- name: Set source file & directory name
command: echo
"{{package.prefix}}{{package.name}}-{{package.ver}}
script or securing it more soundly?
I appreciate your help as always. Ansible has already made learning it an
extremely wise choice if only to help me improve some of my basic sysadmin
habits.
Thanks!
--
Steven Haddox
http://stevenhaddox.com
> On Nov 30, 2013, at 8:01 AM, Michael DeHaan wr
Lars,
Thanks. I actually tried wrapping it in quotes before posting with no change.
Sorry I forgot to mention that.
-Steven
--
Steven Haddox
http://stevenhaddox.com
> On Nov 30, 2013, at 2:35 AM, Lars Hansson wrote:
>
> Try:
>
> shell: "bash < <( curl {{rvm_fw_
Michel,
It's definitely not the way old school RVM instructions said it had to be
done, but it seems to work on this particular instance just fine!
Thanks!
On Friday, November 29, 2013 6:53:56 PM UTC-5, Michel Blanc wrote:
>
> On 30/11/2013 00:29, Steven Haddox wrote:
> >
cket: Connection reset by peer
>
>
> real 0m1.107s
> user 0m0.060s
> sys 0m0.076s
>
>
>
>
> On Tue, Nov 26, 2013 at 7:02 PM, Steven Haddox
> > wrote:
>
>> Sorry, both the control machine (my MacBook Air) and the Ansible remote
>> node (my vagrant V
Sorry, the shell action line should read:
shell: bash < <( curl {{rvm_fw_url}}/releases/rvm-install-latest )
I tried to escape it as a debug measure with no success.
Thanks!
On Friday, November 29, 2013 6:27:46 PM UTC-5, Steven Haddox wrote:
>
> I'm trying to run a task tha
I'm trying to run a task that invokes bash as part of the task. The command
works directly from the user's command line on the box but fails when run
via Ansible:
Here's the task that's running:
- name: Install User RVM via RVM::FW
when: rvm_fw == True and rvm_version.rc != 0
shell: \bash <
Sorry, both the control machine (my MacBook Air) and the Ansible remote node
(my vagrant VM) are running perfectly fine (I can ssh into the Vagrant VM
without a problem, and Ansible eventually does run through the play book after
the 3-5 minutes pause on gathering facts completes. The only diffe
When I'm trying to develop my play books while offline on my laptop (using
vagrant for my Ansible provisioned server) I'm seeing really long hangs on the
GATHERING FACTS task (as in the order of 3-5 minutes). After it eventually
times out (best guess) it proceeds as normal and everything works p
Melissa,
I have this same situation and ansible's default setup of not using a
user's login shell caught me off-guard at first to. It makes sense though
for Ansible **not** to want to load the user's environment in order to
ensure a consistent shell experience for all modules (especially if a u
.
Thanks!
On Saturday, November 23, 2013 11:41:14 AM UTC-5, Michael DeHaan wrote:
>
> Sorry, I don't have time to debug playbooks.
>
> Happy to answer specific questions.
>
>
>
>
> On Wed, Nov 20, 2013 at 10:23 AM, Steven Haddox
> > wrote:
>
>> Michael,
>
o what may have changed to prevent the
group_vars/all.yml from loading when hosts: all is set, but for now this
works at least with minimal impact.
On Thursday, November 21, 2013 11:22:52 PM UTC-5, Steven Haddox wrote:
>
> I should probably clarify that my sysadmin variable is defined
I should probably clarify that my sysadmin variable is defined in the:
group_vars/all.yml file... unless somehow that's not getting picked up
now...
/me goes to investigate further
On Thursday, November 21, 2013 11:05:09 PM UTC-5, Steven Haddox wrote:
>
> Is there a change I missed
Is there a change I missed in ansible 1.4 that would break the following:
---
- name: Initialize all SUPPORT servers
hosts: all
sudo: yes
sudo_user: "{{sysadmin}}"
roles:
- common
That worked this afternoon in 1.3.4 but upon upgrading to 1.4.0 I'm now
getting:
GATHERING FACTS
*
Ordered. This is awesome. Thanks for giving us a chance to share the love <3
On Monday, November 18, 2013 2:01:33 PM UTC-5, Michael DeHaan wrote:
>
> Hi everyone,
>
> Several people approached us about wanting to get a copy of the flying
> computer shirt we were giving away at AWS re:Invent.
>
>
s helps,
Steven
On Tuesday, November 19, 2013 11:56:23 PM UTC-5, Michael DeHaan wrote:
>
> Environment works for sure, show us what you have now and what ansible
> version you are using?
>
> -- Michael
>
> On Nov 19, 2013, at 11:14 PM, Steven Haddox >
> wrote:
>
> Rodg
ment and deployment system, it's designed to
> not trust the user's configuration on purpose.
>
>
>
>
> On Tue, Nov 19, 2013 at 9:36 AM, Steven Haddox
> > wrote:
>
>> PS - Is it possible that I could somehow get Ansible to load / source the
>> {{HOME.
hrc as the first step for
anytime a task uses that environment, but I'm not sure if that's possible...
On Tuesday, November 19, 2013 9:28:18 AM UTC-5, Steven Haddox wrote:
>
> Nick,
>
> Thanks very much for your reply and thoughts. This has helped tremendously
> (and will hel
Nick,
Thanks very much for your reply and thoughts. This has helped tremendously
(and will help as I write the rest of these playbooks). Alright... here
goes:
> Source is normally a shell-builtin, not an actual executable. As
> you're calling the command module rather than the shell module, it
ame syntax, file,
and proper user is there any chance the source command has any tweaks to it
within ansible itself or that I'm just unlucky enough to catch some context
restriction when running source as another user that I'm not aware of? This
one definitely has me perplexed...
Also, I've t
31 matches
Mail list logo