# Make it possible to nest connection plugins **URL:** \ **Category:** Ansible Project\ **Created:** [July 31, 2014, 10:38am UTC](https://forum.ansible.com/t/make-it-possible-to-nest-connection-plugins/15821 "2014-07-31T10:38:07Z")\ **Posts on this page:** 17\ **Page:** 1
**Author:** ![Filias\_Heidt](https://avatars.discourse-cdn.com/v4/letter/f/f05b48/32.png) [@Filias\_Heidt](https://forum.ansible.com/u/Filias_Heidt)\ **Post date:** [July 31, 2014, 10:38am UTC](https://forum.ansible.com/t/make-it-possible-to-nest-connection-plugins/15821/1 "2014-07-31T10:38:07Z")
Hi all, I’m getting my feet wet in ansible and I’m pretty exited so far. But I think I discovered a use case, which might be of interest for others: We have numerous hosts with jails on them and would like to manage the jails with ansible - and not all jails are accessible via SSH, but all hosts are accessible via SSH. I would like to be able to “nest” the jail connection plugin with the ssh connection plugin, so I can connect to a host normally and then connect via the jail plugin to a specific jail and execute commands in there. Of course I would have to specify on which host to look for the jail. What do you think about this? If its not too hard to implement, I would consider writing a patch, but would need some help with that. If thats already possible, please ignore this - I was asking on the IRC-Channel about this and all I found out was, that a jail connection plugin already exists, but is limited to local use. Cheerio, Filias ---
**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\ **Post date:** [July 31, 2014, 10:44pm UTC](https://forum.ansible.com/t/make-it-possible-to-nest-connection-plugins/15821/2 "2014-07-31T22:44:21Z")
It’s not going to be possible to nest them. What I think you are asking for is some way to do “remote jail management” which is going to be, unfortunately, probably a new connection plugin that might not be easy. I hate to say it, but this is why cloud VMs and things like bridged networking are so great, where each VM can get an IP. I’m open to the idea of seeing another connection plugin for this, but I doubt we’d want to maintain it in core. I could be wrong - I can see the idea of having something like this to be a pretty cool thing for some very specific use cases. ---
**Author:** ![Karl\_E\_Jorgensen](https://avatars.discourse-cdn.com/v4/letter/k/c4cdca/32.png) [@Karl\_E\_Jorgensen](https://forum.ansible.com/u/Karl_E_Jorgensen)\ **Post date:** [August 1, 2014, 8:33am UTC](https://forum.ansible.com/t/make-it-possible-to-nest-connection-plugins/15821/3 "2014-08-01T08:33:07Z")
Hi > Hi all, > > I'm getting my feet wet in ansible and I'm pretty exited so far. But I think I > discovered a use case, which might be of interest for others: > > We have numerous hosts with jails on them and would like to manage the jails > with ansible - and not all jails are accessible via SSH, but all hosts are > accessible via SSH. It sounds more like you need to tweak your SSH config for these jailed hosts - e.g. a fragment like this in $HOME/.ssh/config:   Host somejailedhost      ProxyCommand ssh jailkeeperhost nc %h %p This should allow you to use "ssh" (and scp for that matter) to interact directly with the jailed host. And Ansible should be able to take advantage of that. Hope this helps ---
**Author:** ![Filias\_Heidt](https://avatars.discourse-cdn.com/v4/letter/f/f05b48/32.png) [@Filias\_Heidt](https://forum.ansible.com/u/Filias_Heidt)\ **Post date:** [August 4, 2014, 10:14am UTC](https://forum.ansible.com/t/make-it-possible-to-nest-connection-plugins/15821/4 "2014-08-04T10:14:15Z")
I thought the more generic “nesting” would be a good thing, because the next guy might want to control Docker instances or Containers on a remote host without them having a public IP. Maybe I’ll try to write a connection plugin. @Karl: This is not possible, because some of the Jails don’t even run SSH. You SSH into the Host and run commands inside the jails via “jexec”. ---
**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\ **Post date:** [August 4, 2014, 12:07pm UTC](https://forum.ansible.com/t/make-it-possible-to-nest-connection-plugins/15821/5 "2014-08-04T12:07:44Z")
My suspicions are that's going to be technically possible with how connection plugins work (or even in general, very very complicated). SSH jump hosts would probably be a reasonable thing to do. ---
**Author:** ![Tomasz\_Kontusz](https://avatars.discourse-cdn.com/v4/letter/t/bc79bd/32.png) [@Tomasz\_Kontusz](https://forum.ansible.com/u/Tomasz_Kontusz)\ **Post date:** [August 4, 2014, 7:09pm UTC](https://forum.ansible.com/t/make-it-possible-to-nest-connection-plugins/15821/6 "2014-08-04T19:09:58Z")
The way connection plugins work, it’s not going to be possible to nest existing ones. But what you can do is, create a new API for “connection plugin layers” that can be put on top of an existing “base” connection plugin. Something like: class ConnectionLayer(object): def **init** (self, target\_address): “”“target\_address is a part of ansible\_ssh\_host for this plugin, like jail’s path”“” def wrap\_command(self, command): “”“Wraps the command in chroot/jail/etc.”“” def unwrap\_result(self, rc, stdout, stderr): “”“Takes whatever the wrapped command returned after being run by the base connection plugin, and returns a new tuple of (rc, stdout, stderr)”“” def wrap\_path(self, path): “”“Takes a path inside container/chroot/jail and translates it into host path.”“” I’m not really sure if passing continuations or some “lower layers” object wouldn’t make this a better API, but I think it touched the most important point. I would actually like to see something like this, as I’ve written a OpenVZ-over-SSH connection plugin at work (and I can already give you a hint: don’t try to put host address anywhere but ansible\_ssh\_host, this variable gets special treatment. I’ve tried to have separate ansible\_vzenter\_ctid, and in the end had to rewrite that part). ---
**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\ **Post date:** [August 4, 2014, 8:21pm UTC](https://forum.ansible.com/t/make-it-possible-to-nest-connection-plugins/15821/7 "2014-08-04T20:21:30Z")
Yeah I’m suspecting this will be really hard to debug, if it works at all. For instance, theoretically, you should be able to nest anything in anything. So instead of using SSH jumphosts, maybe you SSH into a SSH. Well, to do that, you have to move a file to a temporary location on an interemediate host. (This is a bad example, because jumphosts are way better in this case). I think it only fits for the “remote jail management cloud” case, which, while I’ll say it’s interesting, I fear it’s too far off the beaten path when most people are going to be moving to a world where the virtual nodes have valid IP addresses. In any case where this is possible, those nodes could just be surfaced by an inventory script that understands what’s out there. I guess what I’m saying is I’m rather skeptical about the idea of having a wrap system, I could see an implementation and be convinced, but I’m also not sure this is important enough to maintain an architectural layer for it. Sorry, I don’t mean to be crushing a cool idea - it’s just going to take some selling and I’m not there yet. ---
**Author:** ![Alberto\_Berti](https://avatars.discourse-cdn.com/v4/letter/a/34f0e0/32.png) [@Alberto\_Berti](https://forum.ansible.com/u/Alberto_Berti)\ **Post date:** [August 7, 2014, 3:03pm UTC](https://forum.ansible.com/t/make-it-possible-to-nest-connection-plugins/15821/8 "2014-08-07T15:03:13Z")
oh, i forgot the links to the nsenter stuff... here they are: - [http://blog.docker.com/2014/06/why-you-dont-need-to-run-sshd-in-docker/](http://blog.docker.com/2014/06/why-you-dont-need-to-run-sshd-in-docker/) - someone proposed a local docker connection here    [https://github.com/ansible/ansible/pull/7971](https://github.com/ansible/ansible/pull/7971) cheers, Alberto ---
**Author:** ![Alberto\_Berti](https://avatars.discourse-cdn.com/v4/letter/a/34f0e0/32.png) [@Alberto\_Berti](https://forum.ansible.com/u/Alberto_Berti)\ **Post date:** [August 7, 2014, 3:47pm UTC](https://forum.ansible.com/t/make-it-possible-to-nest-connection-plugins/15821/9 "2014-08-07T15:47:06Z")
Hi, sorry for the confusing precendence of my latter message, but seems that this message had some problems with gmane, so i'm resending it....     \>\> I thought the more generic "nesting" would be a good thing, because     \>\> the next guy might want to control Docker instances or Containers on     \>\> a remote host without them having a public IP. Maybe I'll try to     \>\> write a connection plugin.     \> The way connection plugins work, it's not going to be possible to nest     \> existing ones.     \> But what you can do is, create a new API for "connection plugin     \> layers" that can be put on top of an existing "base" connection     \> plugin.     \> Something like:     \> class ConnectionLayer(object):     \> def \_\_init\_\_(self, target\_address):     \> """target\_address is a part of ansible\_ssh\_host for this     \> plugin, like jail's path"""     \> def wrap\_command(self, command):     \> """Wraps the command in chroot/jail/etc."""     \> def unwrap\_result(self, rc, stdout, stderr):     \> """Takes whatever the wrapped command returned after being run     \> by the base connection plugin,     \> and returns a new tuple of (rc, stdout, stderr)"""     \> def wrap\_path(self, path):     \> """Takes a path inside container/chroot/jail and translates it     \> into host path.""" any update on this? I would like to use nsenter [1]\_ to run commands inside the container (how to transfer files is a detail i have yet to analyze) to work on docker containers either locally or on a remote host, and i would really like to contribute to and use a layer like this. Unfortunately i'm quite new to ansible and not all the details involving connections are clear to me.          \> I would actually like to see something like this, as I've written a     \> OpenVZ-over-SSH connection plugin at work (and I can already give you     \> a hint: don't try to put host address anywhere but ansible\_ssh\_host,     \> this variable gets special treatment. I've tried to have separate     \> ansible\_vzenter\_ctid, and in the end had to rewrite that part). Nice! openvz is the other virtualization system i use 🙂 So, where you store the ctid? in to so other host related variable? Can you say more about having something like a variable ansible\_vzenter\_ctid is not feasible? Cheers, Alberto ---
**Author:** ![Tomasz\_Kontusz](https://avatars.discourse-cdn.com/v4/letter/t/bc79bd/32.png) [@Tomasz\_Kontusz](https://forum.ansible.com/u/Tomasz_Kontusz)\ **Post date:** [August 7, 2014, 7:57pm UTC](https://forum.ansible.com/t/make-it-possible-to-nest-connection-plugins/15821/10 "2014-08-07T19:57:53Z")
> Hi, > > sorry for the confusing precendence of my latter message, but seems that > this message had some problems with gmane, so i'm resending it.... >      \>\> I thought the more generic "nesting" would be a good thing, because >      \>\> the next guy might want to control Docker instances or Containers on >      \>\> a remote host without them having a public IP. Maybe I'll try to >      \>\> write a connection plugin. >      \> The way connection plugins work, it's not going to be possible to nest >      \> existing ones. >      \> But what you can do is, create a new API for "connection plugin >      \> layers" that can be put on top of an existing "base" connection >      \> plugin. >      \> Something like: > >      \> class ConnectionLayer(object): >      \> def \_\_init\_\_(self, target\_address): >      \> """target\_address is a part of ansible\_ssh\_host for this >      \> plugin, like jail's path""" > >      \> def wrap\_command(self, command): >      \> """Wraps the command in chroot/jail/etc.""" > >      \> def unwrap\_result(self, rc, stdout, stderr): >      \> """Takes whatever the wrapped command returned after being run >      \> by the base connection plugin, >      \> and returns a new tuple of (rc, stdout, stderr)""" > >      \> def wrap\_path(self, path): >      \> """Takes a path inside container/chroot/jail and translates it >      \> into host path.""" > > any update on this? I would like to use nsenter [1]\_ to run commands > inside the container (how to transfer files is a detail i have yet to > analyze) to work on docker containers either locally or on a remote > host, and i would really like to contribute to and use a layer like > this. Unfortunately i'm quite new to ansible and not all the details > involving connections are clear to me. I'll see what I can do, but I wouldn't hold my breath about opening the one I wrote at work. And hey, it's always a good time to rewrite something 🙂 >         \> I would actually like to see something like this, as I've written a >      \> OpenVZ-over-SSH connection plugin at work (and I can already give you >      \> a hint: don't try to put host address anywhere but ansible\_ssh\_host, >      \> this variable gets special treatment. I've tried to have separate >      \> ansible\_vzenter\_ctid, and in the end had to rewrite that part). > > Nice! openvz is the other virtualization system i use 🙂 > > So, where you store the ctid? in to so other host related variable? Can > you say more about having something like a variable ansible\_vzenter\_ctid > is not feasible? I'm putting it in ansible\_ssh\_host like this: some\_container ansible\_connection=vzenter ansible\_ssh\_host=\|\ Using variable other than ansible\_ssh\_host is not feasible, as they are not provided to connection plugins. You can extract them from runner (as connection plugins do get access to runner), but you can't support the delegate\_to: '{{ item }}' pattern this way (as you don't get access to loop items). ---
**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\ **Post date:** [August 7, 2014, 9:35pm UTC](https://forum.ansible.com/t/make-it-possible-to-nest-connection-plugins/15821/11 "2014-08-07T21:35:13Z")
“I’m putting it in ansible\_ssh\_host like this: some\_container ansible\_connection=vzenter ansible\_ssh\_host=|” Maybe like this: ansible\_ssh\_host=hostname;container=CTID If that could be implemented natively in Ansible’s SSH.py, without doing too much damage, I would be SUPER interested. I’d like to see something somewhat pluggable, and in order to take it, it would need to support Docker initially. Though I do feel the “no SSH in containers” statement is a little religious. They want to encourage automation, but when the automation uses SSH, that’s totally cool 🙂 ---
**Author:** ![Tomasz\_Kontusz](https://avatars.discourse-cdn.com/v4/letter/t/bc79bd/32.png) [@Tomasz\_Kontusz](https://forum.ansible.com/u/Tomasz_Kontusz)\ **Post date:** [August 7, 2014, 9:52pm UTC](https://forum.ansible.com/t/make-it-possible-to-nest-connection-plugins/15821/12 "2014-08-07T21:52:25Z")
I like that syntax, thanks. I’m thinking about doing something like: ansible\_connection=stack ansible\_ssh\_host==;=\<“hostname” for that layer\> I don’t think ssh.py (or any other specific connection plugin) is a good place for this, I think it should rather be done as separate plugin or in core. That’s because I’d like to see the same layers used with local/ssh/accelerate. Right, as Ansible already has a plugin system I think that should be doable 🙂 And being pluggable is a big part of it for me - I don’t want to have separate plugin for each base plugin/layer combination. For me it was either jump hosts or entering containers, and the latter seemed more robust (I can access containers with broken networking :-)) ---
**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\ **Post date:** [August 8, 2014, 11:23pm UTC](https://forum.ansible.com/t/make-it-possible-to-nest-connection-plugins/15821/13 "2014-08-08T23:23:23Z")
“I don’t think ssh.py (or any other specific connection plugin) is a good place for this, I think it should rather be done as separate plugin or in core. That’s because I’d like to see the same layers used with local/ssh/accelerate.” I’m not sure that’s a good idea. (A) all distros are moving to new enough SSH that paramiko is going to be less important, and with no paramiko there will be no need for accelerate (B) the concept of “nesting” here is probably going to be way more difficult than just doing it for one plugin. (C) yes, the local case would require ssh, but this seems less important in the long run. ---
**Author:** ![Tomasz\_Kontusz](https://avatars.discourse-cdn.com/v4/letter/t/bc79bd/32.png) [@Tomasz\_Kontusz](https://forum.ansible.com/u/Tomasz_Kontusz)\ **Post date:** [August 12, 2014, 6:05pm UTC](https://forum.ansible.com/t/make-it-possible-to-nest-connection-plugins/15821/14 "2014-08-12T18:05:30Z")
Yes, it is. I’ve started hacking on it (see . It only supports chroot, but jail shouldn’t be hard to add), and I’ve stumbled upon some problems: \* to have a sudo layer as robust as sudo functionality in SSH, layers would need some way to get partial output from commands. I’m thinking about using generators or something similar, but considering that “yield from” and mixing yield with return were only added somewhere in py3, it might turn out pretty ugly. \* put/fetch might need some more freedom than just changing the path on managed host, but that shouldn’t be hard to add (except maybe for risking a loop between exec\_command and put/fetch). ---
**Author:** ![Paul\_Koerbitz](https://avatars.discourse-cdn.com/v4/letter/p/df705f/32.png) [@Paul\_Koerbitz](https://forum.ansible.com/u/Paul_Koerbitz)\ **Post date:** [September 16, 2014, 8:54am UTC](https://forum.ansible.com/t/make-it-possible-to-nest-connection-plugins/15821/15 "2014-09-16T08:54:58Z")
Hi all, > Yes, it is. I’ve started hacking on it (see [https://github.com/ktosiek/ansible-nested-connections](https://github.com/ktosiek/ansible-nested-connections). It only supports chroot, but jail shouldn’t be hard to add), and I’ve stumbled upon some problems: I was wondering what the status was on this one? I also need the _configure jails on ssh-accessible jailhost_ functionality. If there is no further development I might try to add support for jails for this. Cheers Paul > > "I don’t think ssh.py (or any other specific connection plugin) is a good place for this, I think it should rather be done as separate plugin or in core. > > > > That’s because I’d like to see the same layers used with local/ssh/accelerate." > > > > I’m not sure that’s a good idea. > > > > (A) all distros are moving to new enough SSH that paramiko is going to be less important, and with no paramiko there will be no need for accelerate > > > > (B) the concept of “nesting” here is probably going to be way more difficult than just doing it for one plugin. > > Yes, it is. I’ve started hacking on it (see [https://github.com/ktosiek/ansible-nested-connections](https://github.com/ktosiek/ansible-nested-connections). It only supports chroot, but jail shouldn’t be hard to add), and I’ve stumbled upon some problems: > > - to have a sudo layer as robust as sudo functionality in SSH, layers would need some way to get partial output from commands. > I’m thinking about using generators or something similar, but considering that “yield from” and mixing yield with return were only added somewhere in py3, it might turn out pretty ugly. > - put/fetch might need some more freedom than just changing the path on managed host, but that shouldn’t be hard to add (except maybe for risking a loop between exec\_command and put/fetch). > > > (C) yes, the local case would require ssh, but this seems less important in the long run. > > > > > > "I’m putting it in ansible\_ssh\_host like > > > > this: > > > > > > > > some\_container ansible\_connection=vzenter > > > > ansible\_ssh\_host=|" > > > > > > > > Maybe like this: > > > > > > > > ansible\_ssh\_host=hostname;container=CTID > > > > > > I like that syntax, thanks. I’m thinking about doing something like: > > > > > > ansible\_connection=stack ansible\_ssh\_host=\ > > > > > > =;\ > > > =\<“hostname” for that layer\> > > > > > > > If that could be implemented natively in Ansible’s SSH.py, > > > > without doing too much damage, I would be SUPER interested. > > > > > > I don’t think ssh.py (or any other specific connection plugin) is a > > > good place for this, I think it should rather be done as separate > > > plugin or in core. > > > > > > That’s because I’d like to see the same layers used with > > > local/ssh/accelerate. > > > > > > > I’d like to see something somewhat pluggable, and in order > > > > to take it, it would need to support Docker initially. > > > > > > Right, as Ansible already has a plugin system I think that should be > > > doable 🙂 > > > > > > And being pluggable is a big part of it for me - I don’t want to > > > have separate plugin for each base plugin/layer combination. > > > > > > > Though I do feel the “no SSH in containers” statement is a > > > > little religious. They want to encourage automation, but when > > > > the automation uses SSH, that’s totally cool 🙂 > > > > > > For me it was either jump hosts or entering containers, and the > > > latter seemed more robust (I can access containers with broken > > > networking :-)) > > > > > > > > > Hi, > > > > > > > > > > > > sorry for the confusing precendence of my latter > > > > > > message, but seems that > > > > > > > > > > > > this message had some problems with gmane, so i’m > > > > > > resending it… > > > > > > > > > > > > > > > > > “Tomasz” == Tomasz Kontusz [tomasz....@gmail.com](mailto:tomasz....@gmail.com) > > > > > > > > > > > writes: > > > > > > > > > > > > > > I thought the more generic “nesting” > > > > > > > > would be a good thing, because > > > > > > > > > > > > > > the next guy might want to control > > > > > > > > Docker instances or Containers on > > > > > > > > > > > > > > a remote host without them having a > > > > > > > > public IP. Maybe I’ll try to > > > > > > > > > > > > > > write a connection plugin. > > > > > > > > > > > > > The way connection plugins work, it’s > > > > > > > not going to be possible to nest > > > > > > > > > > > > > existing ones. > > > > > > > > > > > > > But what you can do is, create a new > > > > > > > API for "connection plugin > > > > > > > > > > > > > layers" that can be put on top of an > > > > > > > existing “base” connection > > > > > > > > > > > > > plugin. > > > > > > > > > > > > > Something like: > > > > > > > > > > > > > class ConnectionLayer(object): > > > > > > > > > > > > > def **init** (self, > > > > > > > target\_address): > > > > > > > > > > > > > “”"target\_address is a part of > > > > > > > ansible\_ssh\_host for this > > > > > > > > > > > > > plugin, like jail’s path"“” > > > > > > > > > > > > > def wrap\_command(self, command): > > > > > > > > > > > > > “”“Wraps the command in > > > > > > > chroot/jail/etc.”“” > > > > > > > > > > > > > def unwrap\_result(self, rc, > > > > > > > stdout, stderr): > > > > > > > > > > > > > “”"Takes whatever the wrapped > > > > > > > command returned after being run > > > > > > > > > > > > > by the base connection plugin, > > > > > > > > > > > > > and returns a new tuple of > > > > > > > (rc, stdout, stderr)“”" > > > > > > > > > > > > > def wrap\_path(self, path): > > > > > > > > > > > > > “”"Takes a path inside > > > > > > > container/chroot/jail and translates it > > > > > > > > > > > > > into host path.“”" > > > > > > > > > > > > any update on this? I would like to use nsenter [1]\_ > > > > > > to run commands > > > > > > > > > > > > inside the container (how to transfer files is a > > > > > > detail i have yet to > > > > > > > > > > > > analyze) to work on docker containers either locally > > > > > > or on a remote > > > > > > > > > > > > host, and i would really like to contribute to and use > > > > > > a layer like > > > > > > > > > > > > this. Unfortunately i’m quite new to ansible and not > > > > > > all the details > > > > > > > > > > > > involving connections are clear to me. > > > > > > > > > > I’ll see what I can do, but I wouldn’t hold my breath about > > > > > opening the one I wrote at work. > > > > > > > > > > And hey, it’s always a good time to rewrite something 🙂 > > > > > > > > > > > > I would actually like to see > > > > > > > something like this, as I’ve written a > > > > > > > > > > > > > OpenVZ-over-SSH connection plugin at > > > > > > > work (and I can already give you > > > > > > > > > > > > > a hint: don’t try to put host address > > > > > > > anywhere but ansible\_ssh\_host, > > > > > > > > > > > > > this variable gets special treatment. > > > > > > > I’ve tried to have separate > > > > > > > > > > > > > ansible\_vzenter\_ctid, and in the end had > > > > > > > to rewrite that part). > > > > > > > > > > > > Nice! openvz is the other virtualization system i use > > > > > > 🙂 > > > > > > > > > > > > So, where you store the ctid? in to so other host > > > > > > related variable? Can > > > > > > > > > > > > you say more about having something like a variable > > > > > > ansible\_vzenter\_ctid > > > > > > > > > > > > is not feasible? > > > > > > > > > > I’m putting it in ansible\_ssh\_host like this: > > > > > > > > > > some\_container ansible\_connection=vzenter > > > > > ansible\_ssh\_host=| > > > > > > > > > > Using variable other than ansible\_ssh\_host is not feasible, > > > > > as they are not provided to connection plugins. > > > > > > > > > > You can extract them from runner (as connection plugins do > > > > > get access to runner), but you can’t support the > > > > > delegate\_to: ‘{{ item }}’ pattern this way (as you don’t get > > > > > access to loop items). > > > > > > > > > > > Cheers, > > > > > > > > > > > > Alberto > > > > > > > > > > – > > > > > > > > > > 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-proje...@googlegroups.com](mailto:ansible-proje...@googlegroups.com). > > > > > > > > > > To post to this group, send email to [ansible...@googlegroups.com](mailto:ansible...@googlegroups.com). > > > > > > > > > > To view this discussion on the web visit [https://groups.google.com/d/msgid/ansible-project/53E3DA41.7050904%40gmail.com](https://groups.google.com/d/msgid/ansible-project/53E3DA41.7050904%40gmail.com). > > > > > > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > > > > – > > > > > > > > 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-proje...@googlegroups.com](mailto:ansible-proje...@googlegroups.com). > > > > > > > > To post to this group, send email to [ansible...@googlegroups.com](mailto:ansible...@googlegroups.com). > > > > > > > > To view this discussion on the web visit [https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgwx54dt5OAZOyU4ZG28JeTwgvKw6cffGAUtAWiScbZiuw%40mail.gmail.com](https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgwx54dt5OAZOyU4ZG28JeTwgvKw6cffGAUtAWiScbZiuw%40mail.gmail.com?utm_medium=email&utm_source=footer). > > > > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > > – > > > > > > 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-proje...@googlegroups.com](mailto:ansible-proje...@googlegroups.com). > > > > > > To post to this group, send email to [ansible...@googlegroups.com](mailto:ansible...@googlegroups.com). > > > > > > To view this discussion on the web visit [https://groups.google.com/d/msgid/ansible-project/53E3F519.2030501%40gmail.com](https://groups.google.com/d/msgid/ansible-project/53E3F519.2030501%40gmail.com?utm_medium=email&utm_source=footer). > > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > – > > > > 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-proje...@googlegroups.com](mailto:ansible-proje...@googlegroups.com). > > > > To post to this group, send email to [ansible...@googlegroups.com](mailto:ansible...@googlegroups.com). > > > > To view this discussion on the web visit [https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgxPYib1LYxQbvoz8daoFhB6hWgtuzS\_SajAS9q%3Dz0rwhA%40mail.gmail.com](https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgxPYib1LYxQbvoz8daoFhB6hWgtuzS_SajAS9q%3Dz0rwhA%40mail.gmail.com?utm_medium=email&utm_source=footer). > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). are running I was wondering what the status was on this one? I also need the _configure jails on ssh-accessible jailhost_ functionality (I’m a bit surprised this is not considered a common use case TBH). ---
**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\ **Post date:** [September 16, 2014, 2:50pm UTC](https://forum.ansible.com/t/make-it-possible-to-nest-connection-plugins/15821/16 "2014-09-16T14:50:12Z")
No plans for this at this time. I understand the appealing nature of this one, I think it might make sense as a non-core connection plugin perhaps. But the usage of FreeBSD jails is small now, and I don’t think we’d want to continue to maintain this as sort of a “cloud starter kit”. Hope that makes sense. ---
**Author:** ![Paul\_Koerbitz](https://avatars.discourse-cdn.com/v4/letter/p/df705f/32.png) [@Paul\_Koerbitz](https://forum.ansible.com/u/Paul_Koerbitz)\ **Post date:** [September 16, 2014, 4:14pm UTC](https://forum.ansible.com/t/make-it-possible-to-nest-connection-plugins/15821/17 "2014-09-16T16:14:00Z")
Dear Michael, OK, thanks for the heads up. I’ll see if I get this working myself then. cheers P