Re: [tor-relays] Explaining Tor to worried parent
On Mon, 12 Nov 2018 13:53:55 +0100 DrNotThatEvil wrote: > Have you guys/gals ever faced situations similar to this? How did you > handle it? I have not, but to add to what others have said: - One of the benefits of running an exit is that it can be educational, from the perspective of the law as well as technology. You can get some experience with dealing with DMCA/abuse requests and potentially talking to law enforcement about a service that you can be confident of the legal status of. That can be valuable before you need to talk to LE or "rights holders" for any other reason throughout your life. Assuming niftybunny is correct on that info of operators getting prosecuted, you are arguably more likely to be prosecuted for something you have no relation to (e.g. police paperwork mixing you up with someone else) than for running an exit. - You mentioned "employment opportunities", but assuming your field of choice is related, I would think that running an exit would _improve_ your employment opportunities, even (or especially) if you encounter public legal trouble as long as you're not stupid about it. - If it's causing you issues, just run a middle relay; it's not a big deal. All relays (properly configured etc etc) are useful, even bridges. If you're pretending that you're making a big difference to some poor persecuted insurgent in China or whatever, keep in mind that I don't believe exits help clients reach hidden services, but middle relays and bridges do. - Running relays/exits is "cool" (...right?). You're just not with it, mom. Just don't run an exit from home. -- Andrew Deason adea...@dson.org ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Abuse Complaints
On Wed, 29 Aug 2018 14:48:33 +0200 Ralph Seichter wrote: > Automated complaints are a different matter. I don't feel the need to > converse with Fail2ban or WebIron bots. For what it's worth, webiron has actually responded to my replies to their reports before. I'm not saying it's a great use of time arguing with them, but the replies are actually read by a human (at least, sometimes). -- Andrew Deason adea...@dson.org ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Nyx 2.0.4-4 on armhf - Python3 error
On Fri, 27 Jul 2018 11:50:57 -0700 Damian Johnson wrote: > Hi Paul. Distutils should be a python builtin. Per chance did you > compile python yourself? If so then that can sometimes exclude modules > we expect to be there (like compression libs). On newer Debian/Ubuntu, it's in a separate package: # apt-get install python3-distutils -- Andrew Deason adea...@dson.org ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] lets stop using central big DNS resolvers (Google, Level3, OpenDNS, Quad9, Cloudflare)
On Sat, 12 May 2018 08:54:00 + nusenu <nusenu-li...@riseup.net> wrote: > "if you want to add a second DNS resolver as a fallback to your > /etc/resolv.conf configuration, try to choose a resolver within your > autonomous system and make sure it is not your first entry in that > file (the first entry should be your local resolver)" So is a non-overused same-AS fallback resolver preferable to having no fallback resolver, or the other way around? Or perhaps this doesn't matter so much, because the big problem right now is just the reliance on the 'big' resolvers? -- Andrew Deason adea...@dson.org ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] lets stop using central big DNS resolvers (Google, Level3, OpenDNS, Quad9, Cloudflare)
On Sat, 12 May 2018 04:50:29 + Matthew Finkel <matthew.fin...@gmail.com> wrote: > But isn't that what the subject line says? And the original email > contains: > > > The goal is to be bellow the following thresholds within one year: > > not have any single remoteAS entity control more than 10% exit capacity > > reduce the overall remoteAS share to bellow 20% exit capacity The subject line I think does effectively say to not use them as fallbacks, but indirectly. It requires some inferring by the relay operator and so it's easy for an operator to arrive at a different conclusion. The text you quoted immediately above (and the medium.com post) I think is not clear about this at all; it talks about an entity "controlling" dns traffic. If google's dns is set as a fallback, does google "control" my exit's dns traffic? The answer to that seems subjective to me; or if objective, then at least not obvious for the casual operator. The email and the guide page says to "not use" those dns services, but it tends to frame the issue as an either-or decision. That is, you guys are telling relay operators e.g. "if you have your resolv.conf set to google's dns, you should instead point to localhost and set up unbound". What if I just have google's dns as a fallback; does that count as "using" it? IMO, the text doesn't (explicitly) say. You can argue that the relay operator should infer that this does count, but if it was explicitly spelled out, there is less room for error. (The list of relays of course is one way of very explicitly spelling this out, by identifying problematic relays. That's the only way I found out that I was considered using google's dns.) It also would make it clear that trying to make dns resolution more "robust" (by providing fallbacks) is not considered by you to be worth the privacy implications of using those resolvers. An operator may think they're not "using" google's dns because they're pointed at localhost first, and their local resolver is working, so they shouldn't normally be using the fallback so it doesn't matter. Obviously that's not true, otherwise such relays wouldn't be identified in that list :) I imagine it's not _as_ bad as depending on google's dns first, but maybe that is an insignificant difference. I don't mean to make a big deal about this; I'm just trying to explain some of what was going through my head when reading this stuff. "Fixing" it can be very simple, like just adding a small phrase like "don't use these, even as a fallback" or "don't mention anywhere in resolv.conf", like you said. -- Andrew Deason adea...@dson.org ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] lets stop using central big DNS resolvers (Google, Level3, OpenDNS, Quad9, Cloudflare)
On Thu, 10 May 2018 22:37:00 + Tyler Durden <vi...@enn.lu> wrote: > All our nodes are using a local DNS caching server and only use google > as a fallback. I was also using google just as a fallback; I've now changed my node to just use a local resolver, with no fallback. Neither the email from nusenu nor the documentation pointed to actually says which of these options is preferable. If you (nusenu) are looking to reduce the exits using these resolvers, I'd suggest explicitly also saying to not use them even as a fallback after a local resolver (assuming that's what you want). Maybe you had intended this to come across with the existing text, but I don't think it's obvious enough. -- Andrew Deason adea...@dson.org ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
On Mon, 30 Oct 2017 17:40:05 -0500 Andrew Deason <adea...@dson.org> wrote: > It's probably worth looking into why that's happening if you are able; > whether nyx/stem/python is somehow causing that, or if it's something > wrong/weird with your machine. Looks like the same bug (or a very similar one) has been found before: https://trac.torproject.org/projects/tor/ticket/9804 -- Andrew Deason adea...@dson.org ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
On Sun, 5 Nov 2017 14:42:43 -0500 grarpamp <grarp...@gmail.com> wrote: > >> > OSError: [Errno 14] Bad address > > 14 EFAULT Bad address. The system detected an invalid address in > attempting to use an argument of a call. That's the general definition of EFAULT, yes. A more helpful definition is from getenv(3): ERRORS [...] [EFAULT] The functions setenv(), unsetenv() or putenv() failed to make a valid copy of the environment due to the environment being corrupt (i.e., a name without a value). A warning will be output to stderr with information about the issue. > > I'm not sure if it's clear, but this is FreeBSD complaining that the > > environment string is invalid (an entry is missing the '=' separating > > the name and value). > > No, os.putenv is a two argument python function and is correct > as shown above. I didn't say otherwise. FreeBSD will return an EFAULT error if the environment string for the process is malformed at the time of the putenv. You can see the logic for this here: https://github.com/freebsd/freebsd/blob/master/lib/libc/stdlib/getenv.c -- Andrew Deason adea...@dson.org ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
On Mon, 30 Oct 2017 13:32:53 -0700
Damian Johnson <ata...@torproject.org> wrote:
> > $ sudo -u _tor ./run_nyx -i 127.0.0.1:
> > nyx: environment corrupt; missing value for
> > Traceback (most recent call last):
> > File "./run_nyx", line 14, in
> > nyx.main()
> > File "/usr/home/ryan/nyx/nyx/__init__.py", line 147, in main
> > nyx.starter.main()
> > File "/usr/home/ryan/nyx/stem/util/conf.py", line 289, in wrapped
> > return func(*args, config = config, **kwargs)
> > File "/usr/home/ryan/nyx/nyx/starter.py", line 90, in main
> > os.putenv('LANG', 'C') # make subcommands (ps, netstat, etc) provide
> > english results
> > OSError: [Errno 14] Bad address
>
> Interesting! Any time you manage to make Nyx stacktrace that's a bug
> on my part. I'll get a fix out for this tomorrow.
I'm not sure if it's clear, but this is FreeBSD complaining that the
environment string is invalid (an entry is missing the '=' separating
the name and value). It's probably worth looking into why that's
happening if you are able; whether nyx/stem/python is somehow causing
that, or if it's something wrong/weird with your machine.
The commit to address this will silence the error, but it still seems
like something is wrong; all env-modifying calls should fail like this
after this point, it seems like.
--
Andrew Deason
adea...@dson.org
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
On Mon, 30 Oct 2017 14:00:44 -0700 Damian Johnson <ata...@torproject.org> wrote: > Hi all. Pushed a couple changes to address feedback thus far... Sorry if this is not the right place for nitpicking/bikeshedding, but: > * Fixed the os.putenv() issue that came up for FreeBSD... > > https://gitweb.torproject.org/nyx.git/commit/?id=bcb0122 Bare 'except:' clauses are really not recommended for error handling, since it catches things like SystemExit and GeneratorExit (not to mention it also triggers if you misspell 'putenv' or something). You can use 'except Exception:' instead, but here I would suggest at least 'except OSError:'. > * When sqlite3 is unavailable encouraging folks to contact us so we > can provide per-platform advice. For FreeBSD providing the 'pkg > install' command mentioned earlier... > > https://gitweb.torproject.org/nyx.git/commit/?id=4bfe05d s/Unfortunatley/Unfortunately/ And thanks for your work; don't mistake this for me being ungrateful :) -- Andrew Deason adea...@dson.org ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor relay making normal internet unusable
On Wed, 30 Aug 2017 01:12:31 -0400 Roger Dingledine <a...@mit.edu> wrote: > On Wed, Aug 30, 2017 at 12:53:39PM +0930, W Howard wrote: > > Thanks for the information. I wanted to run a relay from home to > >support the project but I may instead contribute financially. > > You could do both! :) That is, run a non-exit relay from home, and > also donate. > > https://www.torproject.org/docs/faq#ExitPolicies Also, if you want to run an exit relay and are willing to spend money, you can buy hosting somewhere else, and just run an exit relay there (so it's not at home). Some hosts are okay with this, but most are not, so you need to check. People sometimes report their experiences running exit relays on various hosts here: https://trac.torproject.org/projects/tor/wiki/doc/GoodBadISPs You can get more specific recommendations by asking around. I have an exit on FlokiNET, and they seem okay. -- Andrew Deason adea...@dson.org ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay installation instructions
On Sat, 18 Mar 2017 21:47:10 +0700
Jeff Duncan <wansabai@gmail.com> wrote:
> I went to install a new relay today and found the guide on torproject.org
> had changed. I used to follow this page:
> https://www.torproject.org/docs/tor-relay-debian.html.en and where it says
> : If you're on Ubuntu or if you want to track newer Tor packages, follow
> the Tor on Ubuntu or Debian instructions to use our repository. The link
> works but this link used to have instructions for installing from the tor
> project repositories and installing the gpg key. I do not see those
> instructions now. The debian instructions in section 1 installs tor
> 0.2.5.12-4
This is a bug on that page. The debian instructions are implemented
using a javascript thing that "fills in the blanks" for you, with a
fallback showing the generic instructions.
However, the content-security-policy HTTP header says that inline
javascript is prohibited ('unsafe-inline'). So when javascript is
enabled, the sections are ignored, but the inline javascript
isn't run because CSP prohibits it, so nothing is displayed.
To whoever can fix this, I would suggest maybe avoiding , and
instead have the javascript init() function "display:none" the generic
instructions at the same time that it turns on the javascript
instructions. That would avoid the page just displaying _nothing_ when
an error occurs, since that is very confusing.
Ideally I'd submit a bug for this, but Trac doesn't seem to let me. (Can
regular people create tickets?) If I'm missing something about that, I'd
happily submit a bug, or even try to fix this myself if I can be pointed
at where the website code is (if it's open for contributions).
--
Andrew Deason
adea...@dson.org
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Reaching out to webiron
On Wed, 8 Feb 2017 15:42:21 +0100 Ralph Seichter <tor-relays...@horus-it.de> wrote: > I'd like to add that the tone of the e-mails I received was quite > aggressive, threatening "blocking your whole business". Yes, I left this out of my own report, but this is similar to my own experience. However, since I wasn't expecting anyone to actually read it, my initial response to their automated report admittedly wasn't very friendly. I feel a little bad about that, but I did cool off once I saw I was actually talking to a human. And that's the other reason I feel dumping these off on someone else can be helpful if possible: trying to keep a civil technical conversation going in the face of aggression can be draining. -- Andrew Deason adea...@dson.org ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Reaching out to webiron
On Wed, 8 Feb 2017 17:55:34 +1100 teor <teor2...@gmail.com> wrote: > I'd be happy to talk to them, but perhaps the tor-access list is the > best forum: > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-access > > I'd be willing to discuss their goals and how they could achieve them, > and help them understand the collateral damage resulting from blocking > the entire tor network. I think this is clear from the rest of the thread, but just to mention it here: they seem well beyond trying to let tor users in via captchas or other such solutions like you're discussing with cloudflare etc. They seem to be of the opinion that just blocking tor is impractical, so I wouldn't have much hope in trying to get them to do anything more. I am giving them your contact info and that list, though, so if they ever reach out, you are welcome to try :) -- Andrew Deason adea...@dson.org ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Reaching out to webiron
On Wed, 8 Feb 2017 18:22:33 +1100 teor <teor2...@gmail.com> wrote: > > On 8 Feb 2017, at 18:03, Andrew Deason <adea...@dson.org> wrote: > > > And they even gave instructions for how to block ranges from individual > > exits: > > <https://www.webiron.com/supporthome/view-article/32-blocking-traffic-from-tor-exit-nodes.html> [...] > And it's wrong: > > Tor attempts to find the closest exit node to the end point in > attempts to speed up service. In most cases, because of this it is > possible to curb abuse originating from the same places by blocking > outbound traffic from just a few exit nodes. Just to be clear for the archives etc, I believe you are quoting text from that page, and that text is incorrect. Tor doesn't choose exits that way (unless a user specifically chooses a set of exits near the target or something); that would be silly. > > From my current conversation with them, they are aware of at least some > > suggested ways of blocking tor entirely, but claim some issues with > > doing so. (Something having to do with exit node IPs changing too > > frequently, making the existing methods useless.) > > > > I am not sure if there are real technical limitations, or there is just > > a misunderstanding. Since I don't work with the technical details of tor > > in and out every day, I'm a little hesitant to be arguing with them > > about the various technical details, since I might get something wrong. > > > > And of course, if there _are_ actual problems with the mechanisms of tor > > blacklisting, I can't do anything about it myself, and we have to play > > "telephone" with me reporting some issue second-hand or whatever. > > They are probably using the wrong list, there are reliable lists > maintained by Tor, as far as I know. As far as I can tell, the specific complaint here was that TorDNSEL caches results for 30 minutes; I can see the results indeed give a TTL of 30 minutes. You can just ignore the TTL though, but maybe they were also (allegedly) seeing the information itself be 30 minutes stale. I don't know. Anyway, so the claim (I think) is that the TorDNSEL data would be out of date, and they would block based on that, so they would be missing some. Attackers would then try running their exploit repeatedly until they found an exit that works; and since (they claim) tor exit IPs change so frequently, this would always be a problem. (Even if all of this were true, how this is any better at all from having individual exits block the target ranges via ExitPolicy from their automated reports is beyond me.) It also seems like a service like theirs wouldn't be using TorDNSEL, but instead maybe doing something parsed from consensus itself, but that's just me. > > So... I was wondering if there's someone I should "pass off" to :) > > Ask them to join tor-access@ and explain their issues? Yeah, I hadn't seen your other message when I sent this. It seems doubtful to get them to participate in that, but it's a good pointer to provide, and I'm at least glad that I now know about that list. So, thanks :) -- Andrew Deason adea...@dson.org ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Reaching out to webiron
On Wed, 8 Feb 2017 15:09:47 +1100 Tor <t...@xemurieh.co.uk> wrote: > I don't ignore abuse reports, and I've found that Tor's boilerplate > abuse templates almost always provide a good response. So it's just a > matter of copying and pasting the relevant section and sending it to them. > > https://trac.torproject.org/projects/tor/wiki/doc/TorAbuseTemplates Normally, yes sure, but this isn't some random place that's never heard of tor before. WebIron is well aware of what tor is, and they seem to have an issue with the tor network in general, not my specific node. They used to include this in their automated reports: >> == Tor: Please note as the abuse from Tor has gotten out of hand, >> we do not give free passes to abuse coming from Tor exits. See the >> leader board linked below for more details on the issue. == And they even gave instructions for how to block ranges from individual exits: <https://www.webiron.com/supporthome/view-article/32-blocking-traffic-from-tor-exit-nodes.html> (They no longer include this info in their reports, from what I can tell.) But blocking ranges from individual exits doesn't seem useful to them at all; it's even counterproductive, since the attacks/abuse will use a different IP, bypassing their IP-based blacklist. From my current conversation with them, they are aware of at least some suggested ways of blocking tor entirely, but claim some issues with doing so. (Something having to do with exit node IPs changing too frequently, making the existing methods useless.) I am not sure if there are real technical limitations, or there is just a misunderstanding. Since I don't work with the technical details of tor in and out every day, I'm a little hesitant to be arguing with them about the various technical details, since I might get something wrong. And of course, if there _are_ actual problems with the mechanisms of tor blacklisting, I can't do anything about it myself, and we have to play "telephone" with me reporting some issue second-hand or whatever. So... I was wondering if there's someone I should "pass off" to :) -- Andrew Deason adea...@dson.org ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Reaching out to webiron
I run an exit node, and as such, I get abuse emails like this from time to time: <https://lists.torproject.org/pipermail/tor-relays/2015-October/007982.html> Mostly I ignore them, but since their automated report contains the sentence "Please feel free to send us your comments or responses.", every so often I send something to complain about their practices. To my surprise, apparently somebody does actually read these because today I got a reply. I'm not reproducing the entire response here without permission (they seem kinda touchy), but the person that replied did mention that they have some kind of rbl "in beta" regarding tor exits. They seemed to imply that doing so was quite a burden on them, though, which I don't really understand (IME blocking tor exits is easy; intentionally so). I'm trying to keep the conversation going, but I was wondering if anyone from the tor project has tried to reach out to them in some kind of official way? I'm just some random guy, so I don't know if it would be preferable for someone more knowledgeable, or with more access to tor infrastructure, to be conversing with them. (e.g. teor) I assume some people will say this isn't even worth the effort; it's not like it's hard to just ignore those reports. But it doesn't take much effort to just try to talk ot them, and it perhaps helps to give tor a reputation of cooperation and helpfulness. -- Andrew Deason adea...@dson.org ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Draft Fallback Directory List
On Sun, 11 Dec 2016 23:45:42 +1100 teor <teor2345-re5jqeeqqe8avxtiumw...@public.gmane.org> wrote: > One or more of your relays have been selected as fallback directory > mirrors[0] for the next tor release. Please keep the relay available on > the same addresses, ports, and identity key (fingerprint) for the next > 2 years. Does ipv6 connectivity matter at all for the purposes of being a fallback directory mirror? I can see of course it's not required, but I'm not sure if an ipv6 address would be used at all (as a directory mirror). That is, if I added a v6 addr to a relay in that list, would that help anything, or not yet? I assume that adding a v6 address does not violate the "keep the same address/port/key for the next 2 years" requirement. Is that correct? -- Andrew Deason adea...@dson.org ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor relay and syslog logging
On Fri, 07 Oct 2016 09:46:54 +0200 "Dr. Who" wrote: > What facility is used by tor when logging to syslog? I didn't find that > information. It looks like the default is 'daemon', as you expected. It is changeable via a ./configure option, but debian doesn't seem to touch it. > System is a standard current debian 8.6 with tor Tor 0.2.8.8 > (git-8d8a099454d994bd), the two Log-Lines are: > > Log notice file /var/log/tor/notices.log > Log notice syslog > > Any idea what might be missing? Those lines work for me. You could try sharing a minimal example syslog config that doesn't seem to be working; maybe something's weird with that? You could also maybe 'strace' tor during startup to see if it looks like some log-related syscalls are failing. But be careful with retaining or sharing any such trace, since I assume there can be some sensitive info in there. -- Andrew Deason adea...@dson.org ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Local DNS on Exit logs failed user queries
On Wed, 17 Aug 2016 12:23:15 +1000 teor <teor2345-re5jqeeqqe8avxtiumw...@public.gmane.org> wrote: > Has anyone checked if the logs on other resolvers (like unbound) have > the same issue? On my exit running unbound, I haven't seen any messages from unbound beyond the startup/shutdown messages for the past several weeks, but maybe I just haven't gotten the right errors. I didn't see anything in the code that looked like logging requested names, but I only took a quick glance. The default verbosity seems kinda low, but of course that's no guarantee. What kind of resolution errors are you talking about? Plain NXDOMAIN failures, failing to reach nameservers, DNSSEC failed signatures, or anything else? Do you know of any domains handy that could be used to test the relevant failure cases? (e.g. a dns entry that points to an unreachable server, or results in an invalid DNSSEC response, etc.) That would make it easy for exit operators to test what happens and take out some guesswork. -- Andrew Deason adea...@dson.org ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Unmetered brandwith hosting
On Sun, 10 Apr 2016 22:09:37 +0100 (BST) Michael Canning <mcanning-u9wk5gcosnvr7s880jo...@public.gmane.org> wrote: > I use Flokinet (https://flokinet.is). They are pretty awesome and > their starting VPS is unmetered, although you will have to throttle > your relay to around 100 Mbps. While I use and generally like flokinet, their VPS offerings are not truely unmetered as you might think from their website. They complained when I used over 10TB in a month, and told me to ease up on the bandwidth (which I have) for "fair use" of the connection. A completely saturated 100 mbps connection would yield around 30TB in a month, I believe. For an actual VPS unmetered connection on flokinet, they asked for an additional 1 euro/month per mbps. -- Andrew Deason adea...@dson.org ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] VPS/dedi paid with bitcoin for exit node anyone?
On Sat, 07 Nov 2015 23:14:27 + Monoko Satou <netdi...@sigaint.org> wrote: > I'm looking for relatively cheap dedicated/VPS servers offers for > hosting more tor exit nodes that can be paid for using Bitcoin. Minimal > connection speed I'm interested in is 100mbit. I've seen some offers > here and there but maybe I'm missing something. I'd like fellow node > operators to share some insight on the topic. flokinet.is advertises itself to be tor-friendly, accepts bitcoin, and claims that you can signup without providing any detailed contact info. I didn't pay with bitcoin and I didn't try to hide my identity, but the options appear to be there. The exit node 'nibbana' (025B66CEBC070FCB0519D206CF0CF4965C20C96E) is hosted there. Don't assume that node's bandwidth is the max that they can provide; iirc it's one of their lower-end VPS options and I haven't spent time optimizing or anything (and it's new). Their VPSes are supposed to have 100mbps and the dedicated boxes are listed as 1gbps. My experience has been fine so far with them. -- Andrew Deason adea...@dson.org ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
