Ansible thoughts

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.

First, why are hosts configured in a system-wide file with no
per-user fallback?

export ANSIBLE_HOSTS=...../hosts

Next, there should really be a way to default -K to true.

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

Regards,

        -JP

First, why are hosts configured in a system-wide file with no
per-user fallback?

export ANSIBLE_HOSTS=...../hosts

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.

Next, there should really be a way to default -K to true.

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

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.

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.

Nolan Darilek wrote:

First, why are hosts configured in a system-wide file with no per-user
fallback?

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.

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.

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

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?

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 :slight_smile:

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?

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, just connecting to the remote system as root? Or via some
other mechanism?

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

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.

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

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

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

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

Brian Coca

In my opinion that's a stupid assumption.

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