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. On Tue, Sep 16, 2014 at 4:54 AM, Paul Körbitz <[email protected]> wrote: > 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%2BnsWgwx54dt5OAZOyU4ZG28JeTwgv >>> Kw6cffGAUtAWiScbZiuw%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%2BnsWgxPYib1LYxQbvoz8daoFhB6hW >> gtuzS_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]> >> 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%2BnsWgwx54dt5OAZOyU4ZG28JeTwgv >>> Kw6cffGAUtAWiScbZiuw%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%2BnsWgxPYib1LYxQbvoz8daoFhB6hW >> gtuzS_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 > <https://groups.google.com/d/msgid/ansible-project/2a66d3ef-6259-4360-93d8-7931c15f1fc0%40googlegroups.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%2BnsWgzRfDLp6BqUZoj7FYmBsHu15JU8AhFeq9DBqqnkCbQ4ow%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
