Re: [tor-relays] Become a Fallback Directory Mirror (deadline: July 23)
08F4692B60862640F688B86826B66F30DEA7AB73 Le 8 juillet 2020 19:36:57 GMT+02:00, gus a écrit : >Dear Relay Operators, > >Do you want your relay to be a Tor fallback directory mirror? >Will it have the same address and port for the next 2 years? > >Just reply to this email with your relay's fingerprint. > >Important: you have until July 23 2020 to reply to this message to get >in the fallback directory mirror list. > >If your relay is on the current fallback list, you don't need to do >anything. > >If you're asking: > >Q: What's a fallback directory mirror? > >Fallback directory mirrors help Tor clients connect to the network. For >more details, see [1]. > >Q: Is my relay on the current list? > >Search [2] and [3] for your relay fingerprint or IP address and port. >[2] is the current list of fallbacks in Tor. >[3] is used to create the next list of fallbacks. > >Q: What do I need to do if my relay is on the list? > >Keep the same IP address, keys, and ports. Email tor-relays if the >relay's details change. > >Q: Can my relay be on the list next time? > >We need fast relays that will be on the same IP address and port for 2 >years. Reply to this email to get on the list, or to update the details >of your relay. > >Once or twice a year, we run a script to choose about 150-200 relays >from the potential list [3] for the list in Tor [2]. > >Q: Why didn't my relay get on the list last time? > >We check a relay's uptime, flags, and speed [4]. Sometimes, a relay >might be down when we check. That's ok, we will check it again next >time. > >It's good to have some new relays on the list every release. That helps >tor clients, because blocking a changing list is harder. > >cheers, >Gus > >[1] >https://gitlab.torproject.org/tpo/core/tor/-/wikis/NetworkTeam/FallbackDirectoryMirrors >[2] >https://gitweb.torproject.org/tor.git/tree/src/app/config/fallback_dirs.inc >[3] >https://gitweb.torproject.org/fallback-scripts.git/tree/fallback_offer_list >[4] >https://trac.torproject.org/projects/tor/attachment/ticket/21564/fallbacks_2017-05-16-0815-09cd78886.log >-- >The Tor Project >Community Team Lead >http://expyuzz4wqqyqhjn.onion/ ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Uptime missing from Arm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 There is a git repository with recent commits named nyx (https://gitweb.torproject.org/nyx.git). This seems to be the repository for arm. When cloning the repository and running nyx (aka arm) from the source code it shows the correct average bandwidth. But the uptime is completely hidden. On fedora the python package 'stem' must also be installed from source, the version in the repositories misses 'stem.manual'. -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJYc+FVAAoJEK6hLaeDn2v6q7cP/iISMQoLqz/j2Wb8bToB8qqg rLholrmzaKwn2tKCUm5UHe1lS2JPx+Q1zK5dslC8swajHJqPynIczUay4b/oejId 2RWOZH1sO3WkZmFRTF3hmOVYXvDYJXyVG6guHKE81MIW59cDtqkPyRxg0kgeKwwJ xyjdHUSNTLqd17a9INWoi3+yVHupjmkzCX1ClUerujT+POgtru9b0BlkBZ0pjg3r MGjD+k0VBMJna2/ajiZWHaQGi4jpat+FwOow0rTX7aRXfOwxqB+iWGZYzTgDw+e1 DrXgaA3NwvJHq/LSMBv5KFw5C4CEbKDHzQGXskla1pTwusb5qE4RiBMo+rnNHeY8 F2HoiGGzCWVNVYmU38sEJ9KEp0ftBCDQClmCpSgjAQuo5ZciW11sPcVkqQA48FQR IOZqMwkVWW2fpaNji7kp44fulN+y2VlxRz3elQzwEpdKWBx3LfkQ7b3aNSWgOVpw HPYu+/d952zUOkQnUbX/boFYFH7zWb2PPvd0biHgg5rwfvGzhPO3CiYPheROQnwH JmfG9UBZ/ir92msXyTCd8MxR6emVa68dVJMS93jRbF/4PovZRqy+K2MqI6EJep9l rT635DIciNaa8btznrQsWPGseTWjg8Br49m7yvQTyZLDQy5AHADYcOsa/2OA7KPj lfajw+nEO/oA/LmdVYC+ =NlGU -END PGP SIGNATURE- (Hopefully it does not screw up my signature again, last time the signature was invalid after sending the message...) On Mon, 2017-01-09 at 11:08 +0100, mistral.re...@posteo.net wrote: > Just to confirm - I see the same issue (Debian). So arm is only > partially useful (not being really reliable) but I think it's not > maintained anymore (?). I was looking into theonionbox for status > reporting but that one also needs further development before becoming > a > reliable tool for monitoring... > > > > Am 09.01.2017 10:27 schrieb Norman Rieß: > > Same on plain old Debian. > > > > Norman > > > > > > Am 08.01.2017 um 21:34 schrieb Alan: > > > Yes I have this exact problem aswell > > > > > > > I have a similar problem, > > > > arm does not show uptime and the average bandwidth rate is way > > > > to > > > > high. > > > > When I start arm I get a log entry that looks like this: > > > > "20:37:54 [ARM_NOTICE] Read the last day of bandwidth history > > > > from > > > > the > > > > state file (21 minutes is missing)" > > > > The time varies, sometimes it is even negative. > > > > The operation system is Fedora 25, with arm 1.4.5.0 > > > > > > > > Greetings, > > > > Simon Fischer. > > > > > > > > On Sun, 2017-01-08 at 10:47 -0800, Damian Johnson wrote: > > > > > Hi Alan, what linux distribution is this with? The only > > > > > platform I'm > > > > > aware of having issues with the uptime is OpenBSD. This is > > > > > because > > > > > the > > > > > uptime requires parsing ps output and on that sole platform > > > > > they > > > > > show > > > > > it in 12-hour local time with am/pm indicators, and a format > > > > > that > > > > > shifts if over a day (ie. a true parsing pita :P). > > > > > > > > > > Cheers! -Damian > > > > > > > > > > On 1/8/17, Alan wrote: > > > > > > I have 3 relays running but on Arm only one shows the > > > > > > uptime. Also > > > > > > the > > > > > > Averages it keeps are way off. > > > > > > > > > > > > Alan. > > > > > > > > > > ___ > > > > > tor-relays mailing list > > > > > tor-relays@lists.torproject.org > > > > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-rel > > > > > ays___ > > > > > > > > tor-relays mailing list > > > > tor-relays@lists.torproject.org > > > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relay > > > > s > > > > > > > > > > ___ > > > 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 > > ___ > 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] Uptime missing from Arm
I have a similar problem, arm does not show uptime and the average bandwidth rate is way to high. When I start arm I get a log entry that looks like this: "20:37:54 [ARM_NOTICE] Read the last day of bandwidth history from the state file (21 minutes is missing)" The time varies, sometimes it is even negative. The operation system is Fedora 25, with arm 1.4.5.0 Greetings, Simon Fischer. On Sun, 2017-01-08 at 10:47 -0800, Damian Johnson wrote: > Hi Alan, what linux distribution is this with? The only platform I'm > aware of having issues with the uptime is OpenBSD. This is because > the > uptime requires parsing ps output and on that sole platform they show > it in 12-hour local time with am/pm indicators, and a format that > shifts if over a day (ie. a true parsing pita :P). > > Cheers! -Damian > > On 1/8/17, Alan wrote: > > I have 3 relays running but on Arm only one shows the uptime. Also > > the > > Averages it keeps are way off. > > > > Alan. > > ___ > 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] Running a relay with low transfer limits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Why don't you use the Accounting setting? AccountingMax and AccountingStart in the settings. I think the only downside with it is that Tor does not advertise the directory port. -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJYbVuPAAoJEK6hLaeDn2v6XG0P/3wdrPeFBSANP6BaSQyWiTRO HzN3bG0qQjyqsapFb85LBOpaZUq+xrQiXFbqcKc5dkVta2SHmh44TfyZXCocgNNy +5RUcN/ccJfsdGVJEcTkDe1mTTp/EDJomEnc10ZvFoYmXOpHXoRPxGZGtM+SI+ny pDSs3hRBzsxhxfF18ANkSJUhDVo1DzP8CHdR6UIILyEHBjK90Qv+/aIECjZaor4Y BFhYkcb9YKRh5453m16VgnIbhH+mxsXegAk9KBt1yDykSJNgrUozgAF7X7yKgrtp 3uu3wHMGP4HQiLPiON5MbcSibMu2AC5YqHdRf27yltPhI052OPt7RFYIR+LuWCuJ TeS8U5oxBF8fHpwGypwFVPu/1L80yBDr3UG36Pllmqq6OO5v44ScrHINzFCGL5Eg 9RlDJRHZ+0iPVaI+OkppkUsXXQfJBfQNEhpE0z058bvpZxrd4CbMGA2uyHBHxbl1 P8I+TOq1fYJiz2/Cb+b5mbkcLxtSkLTe6i2tdgW87CmFV5ZLotIKw/rRglqqy05Q 8VDnmcxDNUcnqCfUHD/3wYthdtw/v2o7p5fq0bqQRwRjRFMdHrhLv9iUrOzFlrfa uJ42we3OurC1IeAm8Bvrpqb96yEqpPxhys3OZCPalUar63SQEggpWo+lBh3fwtEA 9Mc81HwvPwQ/z07Ozjzn =faXm -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Web server and TOR bridge at same IP:port
On 16.08.2016 14:26, Alen Hiew wrote: > Is it possible to configure on own physical server a https Web server > (for ex., Apache) at port 443 and obfs4 or meek bridge at same static > global IP address and same port 443? I've set up something like this for normal tor node (not obfs), see nginx site config details here: https://ghostbin.com/paste/9rnw9 The important thing is that you have a different advertise port (80 in my case) and listen port (9080) configured in your tor settings; and that your website can only be reached by domain name, not by typing in the IP address directly into the browser, but this shouldn't be a problem normally. Note that in my case it is for dirPort and an exit node, not a bridge, so you probably have to tweak the settings. But the differentiation based on whether a dns hostname is requested (open website in browser) or not (Tor traffic) is working. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Got a visit from the police this morning..
On 01.08.2016 08:15, stig atle steffensen wrote: > I decided today to turn the node into a non-exit node this morning. > The stress of not knowing if something will happen again is too much for > me to go around thinking about. What hoster did you use? You mentioned the server being located in sweden. Might put a new exit there, can't have police visits lead to lower exit capacity. I understand you don't want to run it yourself anymore though. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Bridge Authority closure
On 21.07.2016 17:36, Marina Brown wrote: > Maybe i am out of line for suggesting this but i will suggest anyway. > Might i suggest that the next bridge authority be hosted on tor inc ip > space and perhaps be 2 hosts instead of one. > > It looks like this was a single point of failure. It would be easy > enough to have a volunteer bgp announce a specific ip address. If they > decided to drop out then it would not cause this type of consternation > in the future. Having more than one bridge auth has obvious benefits. While hijacking the bridge authority does not directly and immediately harm the Tor network, and an evil BGP entry could most probably not be upheld for more than 24h worst-case, I still support the idea of introducing more authority nodes than just a single one. But then again, I don't have much knowledge about the related source code either. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] suspicious "Relay127001" relays
On 06.07.2016 15:50, Ivan Markin wrote: > The introduction of peering policy definitely solves this issue in a > transparent and harmless way. Filed a ticket #19625 [1] to move this > discussion > there. On 06.07.2016 14:56, Roger Dingledine wrote: > Speaking of which, a while ago I started a discussion of how to > streamline that process: > https://trac.torproject.org/projects/tor/ticket/16558 As I see it, removing via directory authority consensus is still the cleaner way, especially in a case of ~100 similar nodes. What came to my mind was something like a bugtracker for bad nodes. This way, all node operators can file suspicious nodes to be excluded, which achieves more than blacklisting on their tiny fraction of the network. It would introduce more transparency because relay operators can actually see someone is working on getting a dir auth consensus and get status updates; or at least there is a discussion why there won't be any blocking. Lastly, it would prevent partitioning attacks or similar in contrast to per-node blacklisting. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] suspicious "Relay127001" relays
On 05.07.2016 13:31, Xza wrote: > 91 at the moment and they will soon gain more flags. > https://sourceforge.net/p/nepenthes/wiki/Home/ > Seems like some sort of honeypot. > Most seem to be from AWS & Linode & Leaseweb USA. How does the process work to exclude nodes from the network? If I understood the documentation correctly, as a node operator I can't blacklist hosts individually (unless I'm putting them into MyFamily, which I don't want to). ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] suspicious relays
On 23.06.2016 22:47, yandere...@riseup.net wrote: > I check torstatus/atlas regularly and this was showing up : > https://atlas.torproject.org/#search/Relay127001 i just thought i report > it here. I copypasted some of the IP addresses into my webbrowser's url bar to check for a dirfrontpage; but what actually shows up is "Directory listing for /" for several of them. I've seen something similar for "involuntary" FTP servers before. Botnet? ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Multiple fingerprints for same IP:Port combo
Hi, Is it possible to have multiple Tor-nodes (with different keypair and fingerprint) at the same IP-Port combination? Or does that not work with the Directory implementation? The idea would be to have nodes under an anycast IP, because the anycast network has a lot of unused capacity. Another possibilty is to replicate the same node and re-use the same keypair in multiple physical locations for the same anycast IP, but I'm not sure this is a good idea. Simon ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] New Tor node operator hibernation question
On Tue, Jul 1, 2014 at 7:34 AM, wrote: > Hello, > > I am a new Tor relay operator, and have setup my first relay. It's been > running as a Tor middle relay for about 10 days now, and it's been running > solid. It has the stable, guard, fast, running, and valid flags. I have my > AccountingMax quota set to start at the first of each month at midnight. > However, just past midnight on 07-01 Tor said it was going to hibernate > until 07-05. This had me confused as I was only about half way through my > monthly quota setup in AccountingMax for June, and my hosting provider > reset the data on the first at midnight. I read the manual page about > AccountingMax again, and it appears this may have been normal behavior. > However before I read the manual page, I forced my relay to wake up out of > that hibernation. It appears to be operating normally right now. However, I > am wondering if this will cause any issues this month, or in future months? > Also, can someone explain if the hibernation of 5 days was normal behavior > to begin with. > > Thank you > As far as I know, tor startes at some random point so that not all nodes are up in the beginning of the month. If every node would do that, at the end of the month (or day if all have accounting per day) nobody would be able to use tor... ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Shutting down middle relays (off-topic)
On Fri, Jun 20, 2014 at 6:47 AM, Tora Tora Tora wrote: > Regretfully, I have to shutdown my two middle relays (not too big, you > won't even notice it :-D), since I am unable to resolve issues with the > latest OpenSSL bug. > > I was able to find upgraded packages for Centos and Fedora that are > supposed to address CVE-2014-0224 vulnerability (the change log claims > so). However, the Tripwire )SSL_CCS_InjectTest and Qualys onlien tests > both disagree. > > If someone can suggest a resolution that works, I might be able to keep > them running, otherwise I see no point in running vulnerable relays > until I figure things out. > Did you restart all applications that are using openssl? If not, they continue to use the old librariers. Best way is to just do a complete restart.. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor-relay - IP
On Wed, Jun 18, 2014 at 5:54 PM, Rui Branco wrote: > > > In the atlas project why the tor-relays ip are discovered? isn't it > dangerous? > > There is nothing strange or dangerous about that. After all your ip has to be published somewhere otherwise no one would be able to use your relay. You could set up a bridge relay. in that case, your ip isn't listed in the complete tor directory - but still accessible, check the docs ( https://www.torproject.org/docs/bridges.html.en) Security is gained by using a firewall, and having an up-to-date-system. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Tor Slides
Hello Is there a public share with presentationslides for tor ? I'll soon hava a presentation, and i want to use the most recent informations. Simon ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
