[tor-project] Decommissioning siv.sunet.se

[teor]

> On 28 Nov 2018, at 19:57, juga <juga at riseup.net> wrote:
> 
> teor:
>>> 
>>> On 27 Nov 2018, at 07:21, Tom Ritter <tom at ritter.vg> wrote:
>>> 

>>> So what's the best choice here? I don't think I have the capacity
>>> (neither speed or bandwidth cap) to self-host this on ritter.vg. I can
>>> use https://www.seul.org/ like moria. Or I can use fastly. Or
>>> something else?
>> 
>> If no-one can run a server,
> 
> Maybe because very few people knows that these type of servers exist and
> are needed.
> What if we request for volunteers in the next meeting?.

> On 28 Nov 2018, at 09:14, Vasilis <andz at torproject.org> wrote:
> 
> What are the requirements for this server?

The trust requirements are:

Bandwidth download servers are a critical part of Tor's infrastructure.
If they break or are malicious, relay weights can change dramatically.
So we need trusted volunteers to run them.

Each directory authority operator decides what trust means to them.
Many operators run the servers themselves.

But if we can find a volunteer that the directory authority operator trusts,
we can deploy a server now. Why wait until the next meeting?


The technical requirements are:

For Torflow (possibly outdated):
* A HTTPS server with 500Mbit-1Gbit upstream (but other Torflow docs say 100Mbits+)
* A fixed IP
* 12-15Gbytes/day
* Some files using the script at:
https://gitweb.torproject.org/torflow.git/tree/NetworkScanners/BwAuthority/README.BwAuthorities#n157

For sbws:
* A HTTP or HTTPS server that supports GET, HEAD, and Range
  (for example, Apache or Nginx)
* A 1 GB file
https://gitweb.torproject.org/sbws.git/tree/DEPLOY.rst#n16

We plan on replacing Torflow with sbws. So any new servers should be able
to support both.

T
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.torproject.org/pipermail/tor-project/attachments/20181128/2f0ad5de/attachment.sig>