I acknowledge that I'm new, so certainly take these with a grain of salt.

First, I'm very excited about Ansible. I've wanted to set up a
configuration automation solution like this for some time, though all
other solutions seem rather heavyweight. I've written several playbooks
for setting up SCM repositories for various projects, installing Java
WARs at specific domains and configuring the servlet/web server, etc.
and am amazed at how easy everything is. I do have a few nits to pick,
though.

First, why are hosts configured in a system-wide file with no per-user
fallback? If I switch VPS providers, someone gives me another server to
administer, etc. that's something personal to me, not a system-wide
value. Why should I configure a host I am personally administering the
same way I'd configure something true for my entire system? I have my
local ~/.ansible.cfg configured to look for hosts in ~/.ansible.hosts,
but it's odd that there is a fallback for configuration but not one for
hosts.

Next, there should really be a way to default -K to true. Sure, I can
specify it, but it's a command line option I'll *always* have to
include, and I've never administered a system where I wasn't using sudo
and not connecting as root. I'm not sure why this isn't a default, actually.

I'm a little confused about modules and module installation. Is there a
user fallback for modules so I don't have to install all modules
system-wide? I'd like to install the rsync module locally, but it looks
like I can only configure a single module path. Am I mistaken? I guess I
could copy all modules into a directory under $HOME, but I'd really
rather have a separate user-specific module location so I don't have to
keep multiple locations in sync.

Despite these thoughts, I really am enjoying using Ansible. Thanks for
creating such an awesome tool.

export ANSIBLE_HOSTS=...../hosts

I think most of us use sudo-less setups, so we don't really want the
sudo password...

Regards,

        -JP

or use "-i", or alias ansible to always pass "-i".

I'm also open to patches to default this to ~/.ansible/hosts IF it exists.

setting a bash alias is a good way to do that.

You can include modules in a "./library" module relative to your
playbooks, which is a good way to do it.

You can also install the module path anywhere and path it with --module-path.

--module-path works more less exactly like $PATH and takes paths
seperated by colons.

The way I deal with this is I have an ansible-management directory.
That has an ansible.cfg file in it - which defines where the hosts file
is.  Everything else goes in subdirectories of this.

You cd into this directory, and then run your ansible commands...

        Nigel.

--
[ Nigel Metheringham ------------------------------ ni...@dotdot.it ]
[                 Ellipsis Intangible Technologies                  ]

On 10/25/2012 02:50 PM, Jan-Piet Mens wrote:

As in, just connecting to the remote system as root? Or via some other
mechanism? I thought it was always best practice to disable direct login
to the root account and go through sudo, but perhaps disabling
passwordless SSH and using keys makes things safe enough to enable the
root account?

If the playbook specifies "sudo: true", would it be safe to assume -K?
Or is there a scenario where someone may specifically request sudo but
not want to prompt for a password? How many people use sudo without a
password vs. using it with one, and if the ratio is low, maybe prompting
for the password in these circumstances might be a better default?

Thanks.

No, passwordless sudo.

http://linux-tips.org/article/18/passwordless-sudo-setup

But yes, there's really no difference between the two.

I am not sure what you mean by "disabling passwordless SSH and using
keys".   You've either got
passwords or keys :)

No, "-K" means prompt me for a sudo password.

Again, sudo does not require a password.

Choosing interactivity by default is something Ansible will never do,
nor is the ratio low.   It defeats the purposes of an automation
solution.

As in connecting to the remote system as a user with a public key, and
running passwordless sudo for that user. From a Playbook:

        ---
        - hosts: any
          connection: paramiko
          user: jane
          sudo: True

with the following /etc/sudoers for user 'jane' on the target systems:

        jane     ALL=(ALL) NOPASSWD: ALL

Hope that helps,

        -JP

what about making it a config option? sudo_ask_pass = true (default false).
possibly adding  ANSIBLE_SUDO_ASK_PASS as env variable.

In my case I use a bash alias, but I can see how people might want this in
ansible.

--
Brian Coca
Stultorum infinitus est numerus
011000010111001001100101011011100010011101110100001000000111100101101111011 1010100100000011100110110110101100001011100100111010000100001

In my opinion that's a stupid assumption.
A lot of us are actually using sudo setups, so we do really want it.
/Patric

Just looked at code, var names are almost as I guessed preparing patch and
pull request.

Brian Coca
On Oct 26, 2012 12:38 PM, "Patric Buskas" <patric.bus...@gmail.com> wrote:

okay - maybe try to be a bit less harsh in your assessment. People can
have a different set of experiences and expectations without anyone being
"stupid".

thanks,
-sv

I meant to write 'password-less sudo/ssh'.