Hi all,

>  Yes, it is. I've started hacking on it (see 
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



On Tuesday, August 12, 2014 8:05:43 PM UTC+2, Tomasz Kontusz wrote:
>
>  On 09.08.2014 01:23, Michael DeHaan wrote:
>  
>
>
> "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. 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.
>
>  
>  
>
>  
>  
>
> On Thu, Aug 7, 2014 at 5:52 PM, Tomasz Kontusz <[email protected]> 
> wrote:
>
>
>>
>>
>>
>>  
>> On 07.08.2014 23:35, Michael DeHaan
>> wrote:
>>
>>  
>>
>>
>> "I'm putting it in ansible_ssh_host like
>> this:
>>
>> some_container ansible_connection=vzenter
>> ansible_ssh_host=<SSH host>|<CTID>"
>>
>>
>>  
>> 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=<connection
>> plugin>=<hostname for that plugin>;<connection
>> layer>=<"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 :-))
>>
>>
>>
>>  
>>
>>
>>
>>
>>
>> On Thu, Aug 7, 2014 at 3:57 PM, Tomasz Kontusz <[email protected]>
>> wrote:
>>
>>
>>>
>>> On 07.08.2014 17:47, Alberto Berti wrote:
>>>
>>>
>>>> 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 <[email protected]>
>>>>>>>>> writes:
>>>>>>>>>
>>>>>>>>>  
>>>>>>>>  
>>>>>>>  
>>>>>>  
>>>>>  
>>>>      Tomasz> On 04.08.2014 12:14, Filias Heidt
>>>> wrote:
>>>>
>>>>      >> 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.
>>>>
>>>>      Tomasz> The way connection plugins work, it's
>>>> not going to be possible to nest
>>>>
>>>>      Tomasz> existing ones.
>>>>
>>>>      Tomasz> But what you can do is, create a new
>>>> API for "connection plugin
>>>>
>>>>      Tomasz> layers" that can be put on top of an
>>>> existing "base" connection
>>>>
>>>>      Tomasz> plugin.
>>>>
>>>>      Tomasz> Something like:
>>>>
>>>>
>>>>
>>>>      Tomasz> class ConnectionLayer(object):
>>>>
>>>>      Tomasz>     def __init__(self,
>>>> target_address):
>>>>
>>>>      Tomasz>         """target_address is a part of
>>>> ansible_ssh_host for this
>>>>
>>>>      Tomasz> plugin, like jail's path"""
>>>>
>>>>
>>>>
>>>>      Tomasz>     def wrap_command(self, command):
>>>>
>>>>      Tomasz>         """Wraps the command in
>>>> chroot/jail/etc."""
>>>>
>>>>
>>>>
>>>>      Tomasz>     def unwrap_result(self, rc,
>>>> stdout, stderr):
>>>>
>>>>      Tomasz>         """Takes whatever the wrapped
>>>> command returned after being run
>>>>
>>>>      Tomasz> by the base connection plugin,
>>>>
>>>>      Tomasz>         and returns a new tuple of
>>>> (rc, stdout, stderr)"""
>>>>
>>>>
>>>>
>>>>      Tomasz>     def wrap_path(self, path):
>>>>
>>>>      Tomasz>         """Takes a path inside
>>>> container/chroot/jail and translates it
>>>>
>>>>      Tomasz> 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 :-)
>>>
>>>
>>>
>>>
>>>
>>>>         Tomasz> I would actually like to see
>>>> something like this, as I've written a
>>>>
>>>>      Tomasz> OpenVZ-over-SSH connection plugin at
>>>> work (and I can already give you
>>>>
>>>>      Tomasz> a hint: don't try to put host address
>>>> anywhere but ansible_ssh_host,
>>>>
>>>>      Tomasz> this variable gets special treatment.
>>>> I've tried to have separate
>>>>
>>>>      Tomasz> 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=<SSH host>|<CTID>
>>>
>>>
>>>
>>> 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 [email protected].
>>>
>>> To post to this group, send email to [email protected].
>>>
>>>  
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/ansible-project/53E3DA41.7050904%40gmail.com
>>> .
>>>
>>>
>>>
>>> For more options, visit 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 [email protected].
>>
>> To post to this group, send email to [email protected].
>>  
>> 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.
>>
>>  
>>
>>
>>  
>>
>>
>>
>>
>> -- 
>>
>> 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 [email protected].
>>
>> To post to this group, send email to [email protected].
>>  
>> 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.
>>
>>   
>  
>
>
>
> -- 
>
> 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 [email protected].
>
> To post to this group, send email to [email protected].
>
> 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.
>
>
>
>
>  
>
>  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).



On Tuesday, August 12, 2014 8:05:43 PM UTC+2, Tomasz Kontusz wrote:
>
>  On 09.08.2014 01:23, Michael DeHaan wrote:
>  
>
>
> "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. 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.
>
>  
>  
>
>  
>  
>
> On Thu, Aug 7, 2014 at 5:52 PM, Tomasz Kontusz <[email protected] 
> <javascript:>> wrote:
>
>
>>
>>
>>
>>  
>> On 07.08.2014 23:35, Michael DeHaan
>> wrote:
>>
>>  
>>
>>
>> "I'm putting it in ansible_ssh_host like
>> this:
>>
>> some_container ansible_connection=vzenter
>> ansible_ssh_host=<SSH host>|<CTID>"
>>
>>
>>  
>> 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=<connection
>> plugin>=<hostname for that plugin>;<connection
>> layer>=<"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 :-))
>>
>>
>>
>>  
>>
>>
>>
>>
>>
>> On Thu, Aug 7, 2014 at 3:57 PM, Tomasz Kontusz <[email protected] 
>> <javascript:>>
>> wrote:
>>
>>
>>>
>>> On 07.08.2014 17:47, Alberto Berti wrote:
>>>
>>>
>>>> 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 <[email protected] <javascript:>>
>>>>>>>>> writes:
>>>>>>>>>
>>>>>>>>>  
>>>>>>>>  
>>>>>>>  
>>>>>>  
>>>>>  
>>>>      Tomasz> On 04.08.2014 12:14, Filias Heidt
>>>> wrote:
>>>>
>>>>      >> 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.
>>>>
>>>>      Tomasz> The way connection plugins work, it's
>>>> not going to be possible to nest
>>>>
>>>>      Tomasz> existing ones.
>>>>
>>>>      Tomasz> But what you can do is, create a new
>>>> API for "connection plugin
>>>>
>>>>      Tomasz> layers" that can be put on top of an
>>>> existing "base" connection
>>>>
>>>>      Tomasz> plugin.
>>>>
>>>>      Tomasz> Something like:
>>>>
>>>>
>>>>
>>>>      Tomasz> class ConnectionLayer(object):
>>>>
>>>>      Tomasz>     def __init__(self,
>>>> target_address):
>>>>
>>>>      Tomasz>         """target_address is a part of
>>>> ansible_ssh_host for this
>>>>
>>>>      Tomasz> plugin, like jail's path"""
>>>>
>>>>
>>>>
>>>>      Tomasz>     def wrap_command(self, command):
>>>>
>>>>      Tomasz>         """Wraps the command in
>>>> chroot/jail/etc."""
>>>>
>>>>
>>>>
>>>>      Tomasz>     def unwrap_result(self, rc,
>>>> stdout, stderr):
>>>>
>>>>      Tomasz>         """Takes whatever the wrapped
>>>> command returned after being run
>>>>
>>>>      Tomasz> by the base connection plugin,
>>>>
>>>>      Tomasz>         and returns a new tuple of
>>>> (rc, stdout, stderr)"""
>>>>
>>>>
>>>>
>>>>      Tomasz>     def wrap_path(self, path):
>>>>
>>>>      Tomasz>         """Takes a path inside
>>>> container/chroot/jail and translates it
>>>>
>>>>      Tomasz> 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 :-)
>>>
>>>
>>>
>>>
>>>
>>>>         Tomasz> I would actually like to see
>>>> something like this, as I've written a
>>>>
>>>>      Tomasz> OpenVZ-over-SSH connection plugin at
>>>> work (and I can already give you
>>>>
>>>>      Tomasz> a hint: don't try to put host address
>>>> anywhere but ansible_ssh_host,
>>>>
>>>>      Tomasz> this variable gets special treatment.
>>>> I've tried to have separate
>>>>
>>>>      Tomasz> 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=<SSH host>|<CTID>
>>>
>>>
>>>
>>> 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 [email protected] 
>>> <javascript:>.
>>>
>>> To post to this group, send email to [email protected] 
>>> <javascript:>.
>>>
>>>  
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/ansible-project/53E3DA41.7050904%40gmail.com
>>> .
>>>
>>>
>>>
>>> For more options, visit 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 [email protected] <javascript:>.
>>
>> To post to this group, send email to [email protected] 
>> <javascript:>.
>>  
>> 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.
>>
>>  
>>
>>
>>  
>>
>>
>>
>>
>> -- 
>>
>> 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 [email protected] <javascript:>.
>>
>> To post to this group, send email to [email protected] 
>> <javascript:>.
>>  
>> 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.
>>
>>   
>  
>
>
>
> -- 
>
> 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 [email protected] <javascript:>.
>
> To post to this group, send email to [email protected] 
> <javascript:>.
>
> 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.
>
>
>
>
>  
>
>  

-- 
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/2a66d3ef-6259-4360-93d8-7931c15f1fc0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to