announcement/call for testing ansible role for tahoe-lafs

David Stainton dstainton415 at
Thu Apr 17 06:49:41 UTC 2014


I recently wrote a Tahoe-LAFS Ansible role.

It can be used to write many different kinds of Ansible playbooks for
dealing with Tahoe-LAFS
component servers such as Introducers, Storage nodes and clients...
for instance the readme
shows an example playbook to create an entire onion-grid; a Tahoe-LAFS
grid running on Tor hidden services
such that the Introducer's furl and storage node furls contains a Tor
hidden service .onion address instead of the DNS name or IP address of
the host.

I've done a lot of cleanup and bugfixes to this ansible role... but it
could probably use some more.
All the example playbooks currently demonstrate how to use Tahoe-LAFS
with tor... utilizing both torsocks
and Tor hidden services. The tor install/configuration is handled by
my Tor ansible role here:
However this Tahoe-LAFS Ansible role *should* work without Tor... if
you really wanna... but there may be some minor bugs to fix
as I have not tested that use case of tahoe.

One of the reasons that Ansible is great is that the only requirement
for Ansible to run is ssh access (authorized_keys) with sudo nopasswd.
Actually that's not true because some Ansible modules need certain
python modules... but that's easy to deal with.
Ansible tasks are meant to be idempotent operations. By default
ansible will execute each task in parallel on a group of hosts... and
will not proceed with the next task until all hosts in the group are
in the same state.

I would very much like to have this tahoe-lafs ansible role gpg verify
the git release tag signatures. Speaking of git tag signatures... I
should use them too! This morning I read some #tahoe-lafs scrollback
and saw something relevant to the "secure" install process:
15:42 < sickness> I really *HATE* how tahoe can automagically pull
things from the net without notice, I'd like that if I have a .zip to
build the *same* way every time
                  I build it instead of rotting over time :(
15:43 < dstufft> that's not tahoe, that's setuptools
15:43 < sickness> well so I hate setuptools :p
15:43 < dstufft> there's a long line of people who want to hate on setuptools
15:44 < sickness> blocking internet access from that machine is a
workaround, but I think it's not normal to have to do that =_)
15:44 < dstufft> so you will not be alone :]
15:44 < dstufft> probably you could just set allowed hosts to None
15:44 < dstufft>
(in the config file)

However, right now I do not set allowed hosts to None (perhaps I
should?)... but instead set an invalid proxy host like wiretapped



More information about the tahoe-dev mailing list