Re: [tor-relays] DigitalOcean bandwidth billing changes

[Nathaniel Suchy (Lunorian)]

They are slowly becoming an AWS Clone - they keep adding more and more
services making the UI Confusing. Now they've even copied AWSs bill per
GB. What's next?

Ralph Seichter:
> On 02.05.18 18:17, mick wrote:
> 
>> Following this I went back to Rafael Rosa, the Product Manager at
>> DigitalOcean who originally sent the email about the changes seeking
>> clarification.
> 
> I also had a back-and-forth with DigitalOcean support staff. Sadly, no
> revelations ensued, so I'll be closing my DO account at the end of this
> month.
> 
> /me shrugs
> 
> -Ralph
> 
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] DigitalOcean bandwidth billing changes

[Ralph Seichter]

On 02.05.18 18:17, mick wrote:

> Following this I went back to Rafael Rosa, the Product Manager at
> DigitalOcean who originally sent the email about the changes seeking
> clarification.

I also had a back-and-forth with DigitalOcean support staff. Sadly, no
revelations ensued, so I'll be closing my DO account at the end of this
month.

/me shrugs

-Ralph

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Help With Autoupdating Tor Software

[Iain Learmonth]

Hi,

On 02/05/18 19:20, Keifer Bly wrote:
> One more question, if I were to restart my relay now, would that mean that my 
> mid time between failures would NOT get closer to 6 days? That’s what is at 
> now.

Assuming that you just restart it and it comes right back up again, and
it's for the purpose of a software update, you should just restart it
regardless.

I'm not sure if a change in the last restarted date will affect your
MTBF, but it's probably more important to update the relay and then
worry about keeping it stable.

Thanks,
Iain.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Help With Autoupdating Tor Software

[Keifer Bly]

One more question, if I were to restart my relay now, would that mean that my 
mid time between failures would NOT get closer to 6 days? That’s what is at 
now. Thanks.

Sent from my iPhone

> On May 2, 2018, at 2:33 AM, teor  wrote:
> 
> 
>>> On 2 May 2018, at 19:20, Iain Learmonth  wrote:
>>> 
>>> On 02/05/18 09:50, teor wrote:
>>> Being in the consensus is called "Running", but what it actually means is
>>> that a majority of directory authorities found your relay reachable.
>>> 
>>> So perhaps we could use:
>>> * uptime for the amount of time since the tor process started
>>> * reachable time for the amount of time the relay has been online and
>>> available to clients
>> 
>> I will raise this issue at the next Metrics team meeting on Thursday.
>> I'm not sure how many clients we would break if we rename the uptime
>> documents, but maybe it's the right thing to do in the long run.
> 
> I think you should prioritise renaming things in relay search and the
> metrics website.
> 
> Renaming backends isn't as high a priority: updating the specification
> is much cheaper, and it achieves a similar outcome.
> 
> T
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] DigitalOcean bandwidth billing changes

[mick]

On Wed, 25 Apr 2018 14:15:35 +
Cody Logan  allegedly wrote:

> Regarding grandfathered accounts, section 3.7 of their terms of
> service is worth a closer look:
> 
> “Subscribers of Grandfathered Accounts must NOT: (i) run Torrents for
> download or Seed Servers, TOR, or services that include content of an
> adult or pornographic nature [...] or otherwise circumvent the
> intended fair usage of free bandwidth by distributing it freely to
> others. Failure of Subscribers of Grandfathered Accounts to follow
> these terms will result in the revocation of their Accounts'
> grandfathered status.”
> 
> https://www.digitalocean.com/legal/terms/
> 

All 

Following this I went back to Rafael Rosa, the Product Manager at
DigitalOcean who originally sent the email about the changes seeking
clarification. I also pointed him to the discussion here on this list
because I was unlikely to be the only one affected by the change. 

Following several emails Rafael kindly confirmed that so long as my
droplet was not the source of any "abuse" reported to DO by third
parties I could continue as is. By "abuse" RR meant hostile activity
such as port scanning. I pointed out that since my droplet was a
non-exit relay, then it would be unlikely to be the source of
such activity. RR did say however, that non "grandfathered" accounts
would in future automatically be billed for any over limit bandwidth
usage. I should also note here that exit relays are, by their nature,
likely to see activity which DO might categorise as abuse so any exit
relay operators using DO should take care.

Our correspondence is shown below. Rafael has kindly agreed that I may
share this with the list and I am grateful to him for that agreement. I
am also exceptionally grateful for the continued ability to provide my
Tor node to the community at its current usage level without
incurring the sort of financial penalty I could have expected.

My thanks to all at DO and to Rafael in particular for this.


Mick


-- correspondence --

RR original email

Hello, 

I’m Rafael Rosa, Product Manager at DigitalOcean. I want to share a
heartfelt thank you for being such a valued, long-time customer. As you
may know, we’ve made some updates to our bandwidth pricing plans 
. With gratitude for your
loyalty, we want to assure you that your account has been grandfathered
into your current pricing plan and you will not incur any charges for
bandwidth usage as long as you comply with the guidelines outlined in
section 3.7 of our Terms of Service
. 

If you are interested in viewing your bandwidth usage, you can now
track usage in the billing page
 where Droplet data
transfer is updated daily. And if you’re curious to learn more about
the details of the bandwidth update, I encourage you to take a look at
this FAQ page
.
 

Happy Coding,

Rafael Rosa
Product Manager, DigitalOcean


Me

Many thanks for this. However, I note that section 3.7 says, inter alia:

"Notwithstanding the foregoing, Subscribers of
Grandfathered Accounts must NOT: (i) run Torrents for download or Seed
Servers, TOR, or services that include content of an adult or
pornographic nature; (ii) resell services through their Account to
provide free bandwidth to other individuals;"

My droplet "roof.rlogin.net" is , and always has been, a Tor (not
"TOR") relay node.

Do I take it from section 3.7 that you will no longer permit that? If
so, I will need to move to another provider.


RR

Sorry about the delay in replying. So, the current policy does have a
restriction on tor nodes, but we are not enforcing it automatically. As
long as we don't detect abuse it should be fine.

I hope this helps.


Me

Many thanks for this, but with respect the answer is a little
ambiguous. Your policy statement at 3.7 of your ToS implies that any
bandwidth usage above that permitted wil be chargeable /regardless/ of
grandfather status if that bandwidth is "given away" to third parties
(such as through Tor). Yet you say here that you are "not enforcing
that automatically". How will I know if/when you do decide to enforce
that? And what do you define as "abuse"?

I am sure that you will understand that I need clarification because I
could potentially be hit with a severe financial penalty should you
choose to enforce the policy without my noticing. I appreciate that as
a $10.00 a month customer I am getting a phenomenally good deal and
fully accept that I may have to pay more in future (regardless of your
original offer back in 2013 of "free bandwidth forever" when I was
grandfathered in). If I have to throttle my Tor node to a particular
level of usage then I need to know what that "acceptable usage" level
would be.

I am not alone in this position. 

Re: [tor-relays] Help With Autoupdating Tor Software

[teor]

> On 2 May 2018, at 19:20, Iain Learmonth  wrote:
> 
>> On 02/05/18 09:50, teor wrote:
>> Being in the consensus is called "Running", but what it actually means is
>> that a majority of directory authorities found your relay reachable.
>> 
>> So perhaps we could use:
>> * uptime for the amount of time since the tor process started
>> * reachable time for the amount of time the relay has been online and
>>  available to clients
> 
> I will raise this issue at the next Metrics team meeting on Thursday.
> I'm not sure how many clients we would break if we rename the uptime
> documents, but maybe it's the right thing to do in the long run.

I think you should prioritise renaming things in relay search and the
metrics website.

Renaming backends isn't as high a priority: updating the specification
is much cheaper, and it achieves a similar outcome.

T
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Help With Autoupdating Tor Software

[Iain Learmonth]

Hi,

On 02/05/18 09:50, teor wrote:
> Being in the consensus is called "Running", but what it actually means is
> that a majority of directory authorities found your relay reachable.
> 
> So perhaps we could use:
> * uptime for the amount of time since the tor process started
> * reachable time for the amount of time the relay has been online and
>   available to clients

I will raise this issue at the next Metrics team meeting on Thursday.
I'm not sure how many clients we would break if we rename the uptime
documents, but maybe it's the right thing to do in the long run.

Thanks,
Iain.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Help With Autoupdating Tor Software

[teor]

> On 2 May 2018, at 18:32, Iain Learmonth  wrote:
> 
>> On 02/05/18 02:09, Keifer Bly wrote:
>> My suspicion is that my posted uptime was retained because I did not
>> restart the relay software while my router firmware was updating (it was
>> offline for about 2 hours), but it thought I’d share this little thing I
>> noticed.
> 
> You're correct. The uptime that is shown in relay search is calculated
> from your relay's self-reported last restart time. This means that if
> your relay has not restarted, it will have the same last restart time
> when it rejoins the consensus and your uptime will not start back from zero.
> 
> Downtime on relay search is calculated from the time that the relay was
> last seen in a consensus, so this would start from zero at the first
> consensus that does not include your relay (and so also only has a
> resolution of one hour, whereas your last restart time has a resolution
> of one second).
> 
> Onionoo (the relay search backend) does keep track of the fractional
> time a relay was included in the consensus for a given time period in
> the "relay uptime documents":
> 
>  https://metrics.torproject.org/onionoo.html#uptime
> 
> This could be confusing, as now we have two definitions for uptime: 1)
> the relay was running and may or may not have been in the consensus, or
> 2) the relay was in the consensus. Maybe we should fix the ambiguity.

Being in the consensus is called "Running", but what it actually means is
that a majority of directory authorities found your relay reachable.

So perhaps we could use:
* uptime for the amount of time since the tor process started
* reachable time for the amount of time the relay has been online and
  available to clients

T
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Help With Autoupdating Tor Software

[Iain Learmonth]

Hi,

On 02/05/18 02:09, Keifer Bly wrote:
> My suspicion is that my posted uptime was retained because I did not
> restart the relay software while my router firmware was updating (it was
> offline for about 2 hours), but it thought I’d share this little thing I
> noticed.

You're correct. The uptime that is shown in relay search is calculated
from your relay's self-reported last restart time. This means that if
your relay has not restarted, it will have the same last restart time
when it rejoins the consensus and your uptime will not start back from zero.

Downtime on relay search is calculated from the time that the relay was
last seen in a consensus, so this would start from zero at the first
consensus that does not include your relay (and so also only has a
resolution of one hour, whereas your last restart time has a resolution
of one second).

Onionoo (the relay search backend) does keep track of the fractional
time a relay was included in the consensus for a given time period in
the "relay uptime documents":

  https://metrics.torproject.org/onionoo.html#uptime

This could be confusing, as now we have two definitions for uptime: 1)
the relay was running and may or may not have been in the consensus, or
2) the relay was in the consensus. Maybe we should fix the ambiguity.

Thanks,
Iain.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Info about Provider Scaleway and cheap "ARM server"

[Roman Mamedov]

On Wed, 02 May 2018 04:20:57 -0400
Artur Pedziwilk  wrote:

> > https://www.scaleway.com/baremetal-cloud-servers/
> >
> > My order was "C1 - A true metal ARM server running in the cloud."
> >
> > "4 Dedicated ARM Cores, 2GB Memory, 50GB SSD Disk / 200Mbit/s unmetered
> > bandwith"
> 
> I think you are mistaken. As far as I know they use Cavium ThunderX 
> processors.
> https://www.cavium.com/product-thunderx-arm-processors.html

They have a range of ARM64-based VPS, those indeed use Cavium ThunderX.

But they also provide ARM dedicated servers (with shared network-based storage)
https://www.cnx-software.com/2015/09/02/scaleway-c1-dedicated-arm-server-price-drops-to-3-euros-per-month/
Those use 32-bit Marvell Armada SoC, have much lower performance than Cavium
and AFAIK are considered a legacy offer to be phased out over time. (They did
not receive IPv6 support when the rest of the plans got it deployed, for
example).

> Can you share more details what make you thinking you are on Raspberry Pi?

This is certainly not a Raspberry Pi, and overheating concerns are unfounded;
before providing this as a commercial service to the general public, I'm sure
they figured out ways to provide sufficient cooling so it can be used 24x7 no
matter what's the CPU load.

But in any case, Online.net is already heavily utilized for Tor relays and
exits, so can't be considered the best choice to add another one at.

-- 
With respect,
Roman
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Info about Provider Scaleway and cheap "ARM server"

[Artur Pedziwilk]

> On 1 May 2018, at 22:53, Olaf Grimm  wrote:
>
> Dear readers,
>
> I tried to use different operating systems and hardware architectures
> for my Tor relays for diversity. So I came to the Parisian provider
> Scaleways, which has a cheap offer for ARM servers for € 2.99 per month.
> Debian was available with architecture "armhf / armv7l". I knew that,
> but I did not want to believe it. After performance trouble and a server
> crash I tested "/etc/cpuinfo" and 'lscpu'. There are Raspberry Pi in the
> cloud! From my personal device at home I know, that full cpu performance
> will kill the device due to overheating. Oh no! Must change to the next
> offer with x86_64 for € 11,99 / month. What can I expect? An old Pentium
> with 400MHz?
>
> https://www.scaleway.com/baremetal-cloud-servers/
>
> My order was "C1 - A true metal ARM server running in the cloud."
>
> "4 Dedicated ARM Cores, 2GB Memory, 50GB SSD Disk / 200Mbit/s unmetered
> bandwith"

I think you are mistaken. As far as I know they use Cavium ThunderX processors.
https://www.cavium.com/product-thunderx-arm-processors.html

Can you share more details what make you thinking you are on Raspberry Pi?___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays