On Sat, 07 Jun 2014 16:26:45 +0100
Michael Scherer <misc(a)zarb.org> wrote:
Le mercredi 04 juin 2014 à 19:45 -0600, Tim Flink a écrit :
> I've been working to rewrite and extend the script that we've been
> using to control playbook execution for folks who are not in
> I've been testing the script but before we actually start using it
> on lockbox01, I'd appreciate a review of the code to make sure I
> didn't miss any security holes.
> Injection attacks shouldn't be an issue due to usage of os.execv -
> all injection attempts are grouped as a single argument and will
> not be broken up.
So, I just have one question. how does the option -P of the script is
supposed to behave ?
Can i assume that I would be able to say "use this playbook, but
instead of using the port 22, use port 1234" without changing the
I think that most of your concerns have been addressed or are being
discussed in other parts of this thread but I wanted to speak towards
the reason that -P is there at all.
You are correct in reading that it has ansible-playbook use an ssh port
other than 22. That is set using -e 'ansible_ssh_port=<some port>' and
giving direct access to the -e parameter would be problematic at best,
so I added the -P parameter which is restricted to just that option
even though it's rendered as -e
The QA devel folks use phabricator and phabricator supports git repo
hosting (through http(s) and ssh). In order to support git over ssh
while keeping user information in phabricator (username, ssh key for
git, repo permissions etc.), it uses a short-circuited ssh daemon that
uses phabricator for auth instead of system accounts (restricted to git
commands, though). Git repos on alternate ports is a bit of a pain, so
to support git+ssh on port 22 I change the real ssh daemon (that can do
more than git) to an alternate port.