Re: [tor-relays] Operator straw poll: Reasons why you use Tor LTS versions?
Hi Am Do., 5. Sept. 2019 um 04:12 Uhr schrieb Mike Perry < mikepe...@torproject.org>: > How can we fix that for you, or at least, how can we make it easier to > run the very latest stable series Tor on your relay? > When i started my first relay i had zero knowledge about Linux so i can describe my whole experience from a noob position. I wanted to start to learn about something new and someone told me a Raspberry Pi is good to start with Linux. Then i had that Pi with Raspbian and didnt knew what to do with it now. I found an instruction on google how to install a Tor relay to contribute to Tor. It took me more than two weeks with many angry moments followed by many facepalms but finally my first relay was working. Now about one year later i operate 25 relays and i love it. I constantly learn something new and i read everything i can about Tor because its fascinating and awesome. It took me months to realize that there is an instruction on your website how to install a relay. At the beginning i always used some guides which i found on google because they appear before the instruction site of the Torproject appears. If you could point out that the instructions for installing a relay on Debian are the same like for Raspbian it had safed me many hours because i thought it will not work if i use the Debian instructions and i thought its more like a "tweak" to make a relay running on a Pi because on your website i can find several OSs but nothing about Raspbian. After i finally understood how to install packages on my Raspberry Pi i was very happy that it worked and i was afraid to touch anything. It took me some more months to even realize that the package in the repositories is not the latest one. I thought its working like Windows Update where you will automatically get the latest stable one when you run apt-get upgrade. After that realization it took me some more months to understand what an additional repository is and how and why to add it. I think there is not much you can do against that. Maybe just support the versions "as short as necessary" because if someone really wants to understand what is going on then he will take his time to make it working. I dont know how big that fraction is but maybe there are several people outside who just dont know that their relay is outdated. I am subscribed on this mailing-list after i had half of my relays already running so maybe there are some people who just dont realize that their relays version is outdated because they still can see traffic on it. So i think kicking out relays with outdated versions "as fast as useful" is a good way to show the operator that he is not very helpful anymore. When they dont see any traffic anymore they either will try to find out why and upgrade or they will close the relay but i think if they decide to close the relay they are anyway not very reliable. To sum it up: - Make it as easy as possible to find the setup instructions - Point out that Raspbian is supported too - Make it more obvious that an operator could be much more useful if he would take a few minutes to upgrade I remembered that someone here asked a few months ago how to set up a relay on Windows. Out of boredom a few days ago i grabbed a one-month-description VPS with Windows Server 2012 R2 on it and tried to set up a relay there. I felt familiar immediatelly even if i had never worked with Windows Server before and the relay was running after 15 minutes. F9C203B9FB710FC9C7C45F2CCDF8B626F2320253 There were only three small points where i struggled a little bit because Tor crashed without telling me why but setting it up on Windows seems to be as easy as on Linux. If it helps i can describe the crashes i had or write a ticket about it. An instruction about setting it up on Windows might be not worth the work but pointing out that if someone is more familiar with Windows that he should just try his luck because it will likely work could be helpful too. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] What could cause a huge clock skew (9 days) across Tor restarts - anyone else experienced something like this?
teor wrote: > Hi, > >> On 7 Sep 2019, at 20:25, s7r wrote: >> >> So, Tor had the time Sep 06 21:03:46.000 before restart. >> >> After restart, it thought it had Aug 28 07:40:07.000 and then Aug 28 >> 07:40:08.000 and then it healed and reported Sep 06 21:04:50.000. >> >> This is kind of odd. What could be the reason for this? The server is >> just a Debian machine that runs Tor and nothing else. > > Sounds like a bug in Tor's wallclock or log modules. > Or a problem with your OS time APIs. > > What version/commit of Tor were you running before and after the upgrade? Before upgrade: 0.4.1.2-alpha-dev Upgraded to: 0.4.2.0-alpha-dev (from deb.tpo -> tor-nightly-master-stretch) Just to add something I missed in my first email: -> after upgrading from 0.4.1.2 to 0.4.2.0, I did an entire system reboot because I also updated some other stuff. So the entire OS restarted, not just Tor daemon. > What time did your OS show when this issue happened? When I checked the log file and saw these anomalies, I immediately checked the current time/date on my OS and it was accurate. But Tor was already seeing an accurate time as well according to the logs, and it was already "healed". > > Can you please post all the logs from Tor's shutdown, startup with the wrong > time, and correct time, and then a few more entries? > Yes, sure. Before reboot of server: Sep 06 20:23:34.000 [notice] Bootstrapped 0% (starting): Starting Sep 06 20:23:36.000 [notice] This version of Tor (0.4.2.0-alpha-dev) is newer than any recommended version, according to the directory authorities. Recommended versions are: 0.2.9.15,0.2.9.16,0.2.9.17,0.3.5.8,0.4.0.5,0.4.0.6,0.4.1.2-alpha,0.4.1.3-alpha,0.4.1.4-rc,0.4.1.5 Sep 06 20:23:59.000 [notice] Starting with guard context "default" Sep 06 20:23:59.000 [notice] Signaled readiness to systemd Sep 06 20:24:00.000 [notice] Bootstrapped 5% (conn): Connecting to a relay Sep 06 20:24:00.000 [notice] Bootstrapped 10% (conn_done): Connected to a relay Sep 06 20:24:00.000 [notice] Bootstrapped 14% (handshake): Handshaking with a relay Sep 06 20:24:01.000 [notice] Bootstrapped 15% (handshake_done): Handshake with a relay done Sep 06 20:24:01.000 [notice] Bootstrapped 56% (loading_descriptors): Loading relay descriptors Sep 06 20:24:01.000 [notice] Bootstrapped 61% (loading_descriptors): Loading relay descriptors Sep 06 20:24:01.000 [notice] Opening Control listener on /run/tor/control Sep 06 20:24:01.000 [notice] Opened Control listener on /run/tor/control Sep 06 20:24:02.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Sep 06 20:24:02.000 [notice] Bootstrapped 66% (loading_descriptors): Loading relay descriptors Sep 06 20:24:03.000 [notice] Bootstrapped 71% (loading_descriptors): Loading relay descriptors Sep 06 20:24:03.000 [notice] Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits Sep 06 20:24:03.000 [notice] Bootstrapped 80% (ap_conn): Connecting to a relay to build circuits Sep 06 20:24:03.000 [notice] Bootstrapped 85% (ap_conn_done): Connected to a relay to build circuits Sep 06 20:24:03.000 [notice] Bootstrapped 89% (ap_handshake): Finishing handshake with a relay to build circuits Sep 06 20:24:04.000 [notice] Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits Sep 06 20:24:04.000 [notice] Bootstrapped 95% (circuit_create): Establishing a Tor circuit Sep 06 20:24:04.000 [notice] Bootstrapped 100% (done): Done Sep 06 20:25:01.000 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent. Publishing server descriptor. Sep 06 20:25:03.000 [notice] Performing bandwidth self-test...done. Sep 06 21:03:16.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 06 21:03:17.000 [notice] Delaying directory fetches: We are hibernating or shutting down. Sep 06 21:03:46.000 [notice] Clean shutdown finished. Exiting. After reboot (when systemd started Tor automatically): Sep 06 21:03:46.000 [notice] Clean shutdown finished. Exiting. Aug 28 07:39:54.000 [notice] Tor 0.4.2.0-alpha-dev opening log file. Aug 28 07:39:54.198 [notice] We compiled with OpenSSL 101000af: OpenSSL 1.1.0j 20 Nov 2018 and we are running with OpenSSL 101000bf: OpenSSL 1.1.0k 28 May 2019. These two versions should be binary compatible. Aug 28 07:39:54.223 [notice] Tor 0.4.2.0-alpha-dev running on Linux with Libevent 2.0.21-stable, OpenSSL 1.1.0k, Zlib 1.2.8, Liblzma 5.2.2, and Libzstd 1.1.2. Aug 28 07:39:54.223 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Aug 28 07:39:54.223 [notice] This version is not a stable Tor release. Expect more bugs than usual. Aug 28 07:39:54.224 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc". Aug 28 07:39:54.224 [notice] Read configuration file "/etc/tor/torrc". Aug 28 07:39:54.244
Re: [tor-relays] What could cause a huge clock skew (9 days) across Tor restarts - anyone else experienced something like this?
Hi, > On 7 Sep 2019, at 20:25, s7r wrote: > > So, Tor had the time Sep 06 21:03:46.000 before restart. > > After restart, it thought it had Aug 28 07:40:07.000 and then Aug 28 > 07:40:08.000 and then it healed and reported Sep 06 21:04:50.000. > > This is kind of odd. What could be the reason for this? The server is > just a Debian machine that runs Tor and nothing else. Sounds like a bug in Tor's wallclock or log modules. Or a problem with your OS time APIs. What version/commit of Tor were you running before and after the upgrade? What time did your OS show when this issue happened? Can you please post all the logs from Tor's shutdown, startup with the wrong time, and correct time, and then a few more entries? T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Operator straw poll: Reasons why you use Tor LTS versions?
Hi, On 6 Sep 2019, at 20:14, Roman Mamedov wrote: >> Where does the security weakpoint risk come from? Does >> apt-transport-tor/onion service repository availability help in your >> mind here? > > As with adding any third-party repository, it means trusting the repository > provider to install and run any root-privilege code on the machine. In case > the repository server (or actually the release process, including signing) is > compromised, on the next update it can serve malicious or backdoored versions > of the software. So naturally from the security standpoint it is beneficial to > add (and trust) as few repositories as possible, just to reduce the "attack > surface". So one thing Tor could do here is run easily and securely without root? T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] What could cause a huge clock skew (9 days) across Tor restarts - anyone else experienced something like this?
Hello, I'd like to hear if anyone else experienced this and has an idea of what the cause might be. I did not oped a ticket about this yet because I am not sure there is a problem in Tor, and it eventually healed by itself. The relay was running just fine. Server had an accurate time before upgrade and time service ntp was running. I only did an upgrade to Tor from the latest nightly build and of course it does a service stop -> upgrade -> service start. After Debian finished installing the new Tor, I did as usual: check the log file to see that all is OK and circuits were built and descriptors published, etc. I saw this: The log before restart was reporting: Sep 06 21:03:16.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 06 21:03:17.000 [notice] Delaying directory fetches: We are hibernating or shutting down. Sep 06 21:03:46.000 [notice] Clean shutdown finished. Exiting. [skipped boring part intentionally] Aug 28 07:40:07.000 [warn] Our clock is 9 days, 11 hours, 20 minutes behind the time published in the consensus network status document (2019-09-06 23:00:00 UTC). Tor needs an accurate clock to work correctly. Please check your time and date settings! Aug 28 07:40:07.000 [warn] Received ns flavor consensus with skewed time (CONSENSUS): It seems that our clock is behind by 9 days, 11 hours, 20 minutes, or that theirs is ahead. Tor requires an accurate clock to work: please check your time, timezone, and date settings. Aug 28 07:40:07.000 [warn] Problem bootstrapping. Stuck at 0% (starting): Starting. (Clock skew -818406 in ns flavor consensus from CONSENSUS; CLOCK_SKEW; count 2; recommendation warn; host ? at ?) Aug 28 07:40:08.000 [warn] Our clock is 9 days, 12 hours, 20 minutes behind the time published in the consensus network status document (2019-09-07 00:00:00 UTC). Tor needs an accurate clock to work correctly. Please check your time and date settings! Aug 28 07:40:08.000 [warn] Received microdesc flavor consensus with skewed time (CONSENSUS): It seems that our clock is behind by 9 days, 12 hours, 20 minutes, or that theirs is ahead. Tor requires an accurate clock to work: please check your time, timezone, and date settings. Aug 28 07:40:08.000 [warn] Problem bootstrapping. Stuck at 0% (starting): Starting. (Clock skew -822006 in microdesc flavor consensus from CONSENSUS; CLOCK_SKEW; count 3; recommendation warn; host ? at ?) and then Sep 06 21:04:50.000 [notice] Starting with guard context "default" ...proceed to normal start and everything as usual from now... So, Tor had the time Sep 06 21:03:46.000 before restart. After restart, it thought it had Aug 28 07:40:07.000 and then Aug 28 07:40:08.000 and then it healed and reported Sep 06 21:04:50.000. This is kind of odd. What could be the reason for this? The server is just a Debian machine that runs Tor and nothing else. Thanks! 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
