Re: [tor-relays] arm crashes
OK, thanks, I think that worked. Nyx is running and tor-arm is uninstalled. And: Yes there is a log which I enclosed to this message. I not able to see anything helpful in it. Tor has now a uptime of about 22 hrs, it ran with an up-/download-average of about 47 KB/sec which is really low. Now there is no up- or download at all. Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ Am 22. März 2018 11:54 AM schrieb Vasilis : > Hi, > > smichel0: > > > This morning nyx was still working but tor was down - now restarting. > > The Tor daemon (instance) is unrelated to nyx, arm or other software that > > monitors your Tor relay. In order to verify if the Tor daemon is running on > your > > system you should check the logs usually under '/var/log/syslog'. > > > Whow can I get rid of the arm-installation? > > From your previous post it seems that you are running a system with the apt > > manager, the following command will remove arm from your system (given that > you > > have installed arm via the package manager): > > apt-get remove tor-arm > > ~Vasilis > > > > > Fingerprint: 8FD5 CF5F 39FC 03EB B382 7470 5FBF 70B1 D126 0162 > > Pubkey: https://pgp.mit.edu/pks/lookup?op=get&search=0x5FBF70B1D1260162 > > 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] DoSer is back, Tor dev's please consider
> Suggestion: DoSCircuitCreationMinConnections=1 be established in consensus The man page for the above option says: "Minimum threshold of concurrent connections before a client address can be flagged as executing a circuit creation DoS. In other words, once a client address reaches the circuit rate and has a minimum of NUM concurrent connections, a detection is positive. "0" means use the consensus parameter. If not defined in the consensus, the value is 3. (Default: 0)" Reading this, I get the impression that lowering the value to 1 would negatively impact clients behind carrier NAT. Isn't that the case? If we only allow 1 concurrent connection per IP, wouldn't that prevent multiple users behind a single IP? I would think the same problem would apply to lowering DoSConnectionMaxConcurrentCount as well (which I think is currently 50 in the consensus, but I've seen suggestions to lower it to 4). Am I misunderstanding? ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Previous Guard not getting Guard flag back
Came in a day early with six authorities voting yea and three voting nay. Implies the median uptime percentage for guard candidates is slightly under 95.8. NSDFreedom_guard_recovery.xls Description: Binary data ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] DoSer is back, Tor dev's please consider
Please note: Here parameter DoSCircuitCreationMinConnections=1 is set (rather than the default value of 3). Mar 11 17:23:53 Tor[]: DoS mitigation since startup: 0 circuits rejected . . . . . . Mar 22 11:23:54 Tor[]: DoS mitigation since startup: 299608 circuits rejected. . . Mar 22 17:23:54 Tor[]: DoS mitigation since startup: 806025 circuits rejected. . . I.E. mitigation circuit rejections increased 170% in six hours after moving vaguely for over ten days. Also: top - 19:05:53 up 11 days. PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 1998 tor 20 0 662m 611m 108m R 47.2 15.4 7901:32 tor 2000 tor 20 0 662m 611m 108m S 42.2 15.4 343:28.28 tor 2001 tor 20 0 662m 611m 108m R 56.8 15.4 343:24.46 tor I.E. crypto workers pegged after barely registering since DoSer shut it down on March 7th. 'iptables' mitigation rule here shows the DoS source-IPs ablaze. == Suggestion: DoSCircuitCreationMinConnections=1 be established in consensus ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor-instance-create vs. /etc/tor/torrc
On 21.03.2018 13:46, Gary wrote: > Firstly, delete what you dont want from > /usr/share/tor/tor-service-defaults-torrc file and its copies. Please don't. As general advice, really avoid messing with configuration files that ship with the distribution. Editing files in /usr/share is *never* a good option. Nusenu's suggestion to "mask" the default systemd service is much better. > Secondly, enable logs for all relays. You will have to change the > default file from /var/log/tor/notices.log to notices_instance1.log or > something for each instance. This will stop race conditions for the > logs, you will have to follow the same logic for everything else (eg > race to use port 9050) On systemd-based machines, journalctl takes care of logging. You do not need to have any additional logging enabled in Tor (unless you really want to). By default, journalctl logs are not persistent across sessions. Also here, in most cases you will want to do it "the systemd way" and change your logging policies globally, instead of on a custom per-service level. > BTW if you delete /etc/tor/torrc apt-get will ask you displaying a > screen that says "the package maintainer has shipped a new configuration > file what you do want to do" with about 4/5 options. It will only > (re-)install /etc/tor/torrc if you tell it to (the default option is no > I think). I recommend that people use an update manager like unattended-upgrades and let it auto-upgrade everything, and even let it auto-reboot if necessary. Add some external monitoring (a cheap option are free services like uptimerobot.com), and you will learn if something goes wrong. It is better to have a Tor relay that is up to date and have it break sometimes (I have not seen this happening ever) than to have outdated packages/kernels. See https://torservers.net/wiki/setup/server for some references. -- Moritz Bartl https://www.torservers.net/ ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] exit operators: DNS failure rate increased - please check your DNS
Understandably I got the following question from an operator (off-list): > How do we fix this? This was my answer: For fast exits we generally recommend to run a local caching and validating resolver like unbound, without using forwarding. Besides being more reliable this also improves latency since many hostnames will be resolved using cached entries. Regardless of how you proceed: Please do _not_ use Google's DNS server, they see already a lot of DNS traffic. https://nymity.ch/dns-traffic-correlation/ -- https://mastodon.social/@nusenu twitter: @nusenu_ 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] arm crashes
Hi, smichel0: > This morning nyx was still working but tor was down - now restarting. The Tor daemon (instance) is unrelated to nyx, arm or other software that monitors your Tor relay. In order to verify if the Tor daemon is running on your system you should check the logs usually under '/var/log/syslog'. > Whow can I get rid of the arm-installation? From your previous post it seems that you are running a system with the apt manager, the following command will remove arm from your system (given that you have installed arm via the package manager): apt-get remove tor-arm ~Vasilis -- Fingerprint: 8FD5 CF5F 39FC 03EB B382 7470 5FBF 70B1 D126 0162 Pubkey: https://pgp.mit.edu/pks/lookup?op=get&search=0x5FBF70B1D1260162 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
