- tor-relays - lists.torproject.org

difficulty installing
by potlatch 03 Mar '21

03 Mar '21

I've been deploying Tor nodes for over a decade--maybe several dozen or more. I still have ten nodes operating in six developing or smaller countries. Many are exits. Recently, I leased a VPS in a Eastern European country with permission to use it as an exit relay. This brought back some bad memories of a year ago when I last tried to make the Tor software function. The problems then are the problems I have now. I'm disappointed by the state of the installation packages and documentation these days (since a year ago at least). Tor won't start after the initialization message. But it displays 'If you do want to run an exit Relay, please set the ExitRelay option to 1 to disable this warning, and for forward compatibility'. Where the hell is the Exit Relay option? Then there is the issue of not being able to acquire the Tor keys or for the VPS to find the key-ring. Another message: 'The repository '[https://deb.torproject.org/torproject.org](https://ded.torproject.org/torpr… stretch InRelease' is not signed. Data from such a repository can't be authenticated and is therefore potentially dangerous to use.' So, is it just that the documentation is messed up or has everyone given up on the Tor project? Nyx has never completely worked for me. Never with a local config file. I think there are some python utilities that need to be installed to make it work. I never asked but no one ever offered. The documentation is silent regarding this point. The old ARM software would give me an idea of how many file descriptors I was using and if I had provided enough. Arm also filled in the users list with column information instead of providing mostly ????. I donate regularly to Tor, EFF and Riseup. It's what I believe in. Does Tor need some volunteer help? I can only code python--would that help? potlatch in WA State Sent with [ProtonMail](https://protonmail.com) Secure Email.

3 2

IPv6 auto-discovery vs. privacy extensions
by Onion Operator 01 Mar '21

01 Mar '21

Saluton, My relay started to log this message since 0.4.5.5: Auto-discovered IPv6 address [...]:443 has not been found reachable. However, IPv4 address is reachable. Publishing server descriptor without IPv6 address. [2 similar message(s) suppressed in last 2400 seconds] I think it started with the introduction of IPv6 auto-discovery. The problem, as I understand it, is that my relay has IPv6 privacy extensions enabled and therefore the IPv6 detection logic gets fooled. Indeed the IPv6 I see in the logs is one of the temporary addresses used as client towards other relays. Relevant config is: ORPort 443 IPv4Only ORPort [...]:443 IPv6Only I added the IPv{4,6}Only options only in searching a solution to this problem, before 0.4.5.5 the IPv6 relay worked perfectly without. In reading the documentation of AddressDisableIPv6 I got the impression that if (any?) ORPort is configured with IPv4Only the IPv6 auto-discovery gets disabled but evidence does not support my understanding. Is it a bug? Any other way to disable IPv6 auto-discovery? -- flev

4 4

Re: [tor-relays] bug message from 02/28/2020 on 4.5.6
by William Kane 01 Mar '21

01 Mar '21

Hi Matt, this is non fatal and as you can see by the most recent log entries, you could ignore it - anyway, some contributor warned about this occurring with more recent tor builds since the way tor probes for listening sockets has changed / it now always binds to all IPv4 & IPv6 addresses and then does reachability checks for each? It was something along the lines of that. What if you manually specify your listening IP addresses and port like I do: ORPort 37.157.195.83:38619 ORPort [2a02:2b88:2:1::3239:0]:38619 This should satisfy tor, at least it does on 0.4.4.6 which is the newest version available through the official ArchLinux repositories, not sure about 0.4.5.x branch which states the following in it's change log: This release series introduces significant improvements in relay (IPv6) address discovery. That would be much safer and cleaner than tor trying to guess which addresses it's supposed to bind to anyway :-) Thank you for running a relay! Best Regards, William 2021-03-01 12:49 GMT, William Kane <ttallink(a)googlemail.com>: > Hi Matt, > > this is non fatal and as you can see by the most recent log entries, > you could ignore it - anyway, some contributor warned about this > occurring with more recent tor builds since the way tor probes for > listening sockets has changed / it now always binds to all IPv4 and > IPv6 addresses an does reachability checks for each? > > It was something along the lines of that. > > What if you manually specify your listening IP addresses and port like I > do: > > ORPort 37.157.195.83:38619 > ORPort [2a02:2b88:2:1::3239:0]:38619 > > This should satisfy tor, at least it does on 0.4.4.6 which is the > newest version available through the official ArchLinux repositories, > not sure about 0.4.5.x branch which states the following in it's > changelog: > > This release series introduces significant improvements in relay > (IPv6) address discovery. > > That would be much safer and cleaner than tor trying to guess which > addresses it's supposed to bind to anyway :-) > > Hope I helped, > William > > > > 2021-02-28 15:28 GMT, tor <tor(a)kevinandmatt.com>: >> Hi All, >> This popped up today after running successfully for about a week. >> -matt >> >> >> x 09:32:50 [NOTICE] Self-testing indicates your ORPort *.*.*.*:443 is >> reachable from the outside. Excellent. Publishing server descriptor. >> x 09:32:50 [NOTICE] Now checking whether IPv4 ORPort *.*.*.* :443 is >> reachable... (this may take up to 20 minutes -- look for log messages >> indicating success) >> x 09:32:26 [NOTICE] External address seen and suggested by a directory >> authority: *.*.*.* >> x 09:30:52 [NOTICE] Bootstrapped 100% (done): Done >> x 09:30:52 [NOTICE] Bootstrapped 95% (circuit_create): Establishing a >> Tor >> circuit >> x 09:30:52 [NOTICE] Bootstrapped 90% (ap_handshake_done): Handshake >> finished with a relay to build circuits >> x 09:30:52 [NOTICE] Bootstrapped 89% (ap_handshake): Finishing handshake >> with a relay to build circuits >> x 09:30:52 [NOTICE] Bootstrapped 85% (ap_conn_done): Connected to a >> relay >> to build circuits >> x 09:30:52 [NOTICE] Bootstrapped 80% (ap_conn): Connecting to a relay to >> build circuits >> x 09:30:52 [NOTICE] Bootstrapped 75% (enough_dirinfo): Loaded enough >> directory info to build circuits >> x 09:30:51 [NOTICE] Bootstrapped 68% (loading_descriptors): Loading >> relay >> descriptors >> x 09:30:51 [NOTICE] Bootstrapped 63% (loading_descriptors): Loading >> relay >> descriptors >> x 09:30:51 [NOTICE] Bootstrapped 55% (loading_descriptors): Loading >> relay >> descriptors >> x 09:30:50 [NOTICE] Bootstrapped 50% (loading_descriptors): Loading >> relay >> descriptors >> x 09:30:50 [NOTICE] Bootstrapped 45% (requesting_descriptors): Asking >> for >> relay descriptors >> x 09:30:50 [NOTICE] Bootstrapped 15% (handshake_done): Handshake with a >> relay done >> x 09:30:50 [NOTICE] Bootstrapped 14% (handshake): Handshaking with a >> relay >> x 09:30:50 [WARN] Bug: >> /usr/lib/aarch64-linux-gnu/libevent-2.1.so.6(+0x21a10) [0xffff8575ba10] >> (on >> Tor 0.4.5.6 ) >> x 09:30:50 [WARN] Bug: /usr/bin/tor(+0x81854) [0xaaaae3745854] (on Tor >> 0.4.5.6 ) >> x 09:30:50 [WARN] Bug: /usr/bin/tor(+0x21419c) [0xaaaae38d819c] (on Tor >> 0.4.5.6 ) >> x 09:30:50 [WARN] Bug: /usr/bin/tor(consider_publishable_server+0x5c) >> [0xaaaae377099c] (on Tor 0.4.5.6 ) >> x 09:30:50 [WARN] Bug: /usr/bin/tor(router_rebuild_descriptor+0x90) >> [0xaaaae3770588] (on Tor 0.4.5.6 ) >> x 09:30:50 [WARN] Bug: /usr/bin/tor(router_build_fresh_descriptor+0x44) >> [0xaaaae377016c] (on Tor 0.4.5.6 ) >> x 09:30:50 [WARN] Bug: /usr/bin/tor(+0xabaa0) [0xaaaae376faa0] (on Tor >> 0.4.5.6 ) >> x 09:30:50 [WARN] Bug: /usr/bin/tor(relay_addr_learn_from_dirauth+0x1a8) >> [0xaaaae38d6bb0] (on Tor 0.4.5.6 ) >> x 09:30:50 [WARN] Bug: /usr/bin/tor(tor_bug_occurred_+0x164) >> [0xaaaae37c15dc] (on Tor 0.4.5.6 ) >> x 09:30:50 [WARN] Bug: /usr/bin/tor(log_backtrace_impl+0x68) >> [0xaaaae37b5fc0] (on Tor 0.4.5.6 ) >> x 09:30:50 [WARN] Bug: Tor 0.4.5.6: Non-fatal assertion !(!ei) failed in >> relay_addr_learn_from_dirauth at >> ../src/feature/relay/relay_find_addr.c:235. Stack trace: (on Tor 0.4.5.6 >> ) >> x 09:30:50 [WARN] tor_bug_occurred_(): Bug: >> ../src/feature/relay/relay_find_addr.c:235: >> relay_addr_learn_from_dirauth: >> Non-fatal assertion !(!ei) failed. (on Tor 0.4.5.6 ) >> x 09:30:50 [NOTICE] Unable to find IPv4 address for ORPort 443. You >> might >> want to specify IPv4Only to it or set an explicit address or set Address. >> x 09:30:50 [NOTICE] Opened Control listener connection (ready) on >> /run/tor/control >> qj 09:30:50 [NOTICE] Opening Control listener on /run/tor/control >> >

1 0

bug message from 02/28/2020 on 4.5.6
by tor 28 Feb '21

28 Feb '21

Hi All, This popped up today after running successfully for about a week. -matt x 09:32:50 [NOTICE] Self-testing indicates your ORPort *.*.*.*:443 is reachable from the outside. Excellent. Publishing server descriptor. x 09:32:50 [NOTICE] Now checking whether IPv4 ORPort *.*.*.* :443 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) x 09:32:26 [NOTICE] External address seen and suggested by a directory authority: *.*.*.* x 09:30:52 [NOTICE] Bootstrapped 100% (done): Done x 09:30:52 [NOTICE] Bootstrapped 95% (circuit_create): Establishing a Tor circuit x 09:30:52 [NOTICE] Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits x 09:30:52 [NOTICE] Bootstrapped 89% (ap_handshake): Finishing handshake with a relay to build circuits x 09:30:52 [NOTICE] Bootstrapped 85% (ap_conn_done): Connected to a relay to build circuits x 09:30:52 [NOTICE] Bootstrapped 80% (ap_conn): Connecting to a relay to build circuits x 09:30:52 [NOTICE] Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits x 09:30:51 [NOTICE] Bootstrapped 68% (loading_descriptors): Loading relay descriptors x 09:30:51 [NOTICE] Bootstrapped 63% (loading_descriptors): Loading relay descriptors x 09:30:51 [NOTICE] Bootstrapped 55% (loading_descriptors): Loading relay descriptors x 09:30:50 [NOTICE] Bootstrapped 50% (loading_descriptors): Loading relay descriptors x 09:30:50 [NOTICE] Bootstrapped 45% (requesting_descriptors): Asking for relay descriptors x 09:30:50 [NOTICE] Bootstrapped 15% (handshake_done): Handshake with a relay done x 09:30:50 [NOTICE] Bootstrapped 14% (handshake): Handshaking with a relay x 09:30:50 [WARN] Bug: /usr/lib/aarch64-linux-gnu/libevent-2.1.so.6(+0x21a10) [0xffff8575ba10] (on Tor 0.4.5.6 ) x 09:30:50 [WARN] Bug: /usr/bin/tor(+0x81854) [0xaaaae3745854] (on Tor 0.4.5.6 ) x 09:30:50 [WARN] Bug: /usr/bin/tor(+0x21419c) [0xaaaae38d819c] (on Tor 0.4.5.6 ) x 09:30:50 [WARN] Bug: /usr/bin/tor(consider_publishable_server+0x5c) [0xaaaae377099c] (on Tor 0.4.5.6 ) x 09:30:50 [WARN] Bug: /usr/bin/tor(router_rebuild_descriptor+0x90) [0xaaaae3770588] (on Tor 0.4.5.6 ) x 09:30:50 [WARN] Bug: /usr/bin/tor(router_build_fresh_descriptor+0x44) [0xaaaae377016c] (on Tor 0.4.5.6 ) x 09:30:50 [WARN] Bug: /usr/bin/tor(+0xabaa0) [0xaaaae376faa0] (on Tor 0.4.5.6 ) x 09:30:50 [WARN] Bug: /usr/bin/tor(relay_addr_learn_from_dirauth+0x1a8) [0xaaaae38d6bb0] (on Tor 0.4.5.6 ) x 09:30:50 [WARN] Bug: /usr/bin/tor(tor_bug_occurred_+0x164) [0xaaaae37c15dc] (on Tor 0.4.5.6 ) x 09:30:50 [WARN] Bug: /usr/bin/tor(log_backtrace_impl+0x68) [0xaaaae37b5fc0] (on Tor 0.4.5.6 ) x 09:30:50 [WARN] Bug: Tor 0.4.5.6: Non-fatal assertion !(!ei) failed in relay_addr_learn_from_dirauth at ../src/feature/relay/relay_find_addr.c:235. Stack trace: (on Tor 0.4.5.6 ) x 09:30:50 [WARN] tor_bug_occurred_(): Bug: ../src/feature/relay/relay_find_addr.c:235: relay_addr_learn_from_dirauth: Non-fatal assertion !(!ei) failed. (on Tor 0.4.5.6 ) x 09:30:50 [NOTICE] Unable to find IPv4 address for ORPort 443. You might want to specify IPv4Only to it or set an explicit address or set Address. x 09:30:50 [NOTICE] Opened Control listener connection (ready) on /run/tor/control qj 09:30:50 [NOTICE] Opening Control listener on /run/tor/control

1 0

Relay metrics - chart never populates
by marsbanks 27 Feb '21

27 Feb '21

Does anyone know why I never see any data in the chart showing the number of clients using my bridge over time? https://metrics.torproject.org/rs.html#details/A675511F2F8EDD6974C3C093B8F3… I'm just concerned I haven't configured something correctly. Thanks. Sent with [ProtonMail](https://protonmail.com) Secure Email.

1 0

current requirements for Fast and HSDir flags
by Scott Bennett 26 Feb '21

26 Feb '21

What are the current requirements to get an HSDir flag assigned to a relay? MYCROFTsOtherChild has, at last heartbeat message, been up for 35 days and 7 hours. To the best of my knowledge, it has not had an HSDir flag in the consensus at any time since it was last started more than a month ago. What are the current requirements to get a Fast flag assigned to a relay? MYCROFTsOtherChild often runs busily at 330 KB/s to 350 KB/s. Sometimes since it was last started over a month ago it has had a Fast flag in the consensus, and at other times it has not. The Fast flag seems to come and go like the wayward breezes. The Bandwidth= value in the consensus entry for MYCROFTsOtherChild has varied from somewhere in the 30s to the 110s, AFAI have seen, but is always subject to the delayed effects of the presence or absence of the Fast flag, of course, and prior to the currently running instance has also been subject to the presence or absence of the HSDir flag. The authorities have seemed to be acting more or less at random when assigning flags for the consensus for many months. Does the tor project envision any timeline for a return to rational, predictable behavior on the part of the authorities? Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************

1 0

Re: [tor-relays] IPv6
by Dr Gerard Bulger 25 Feb '21

25 Feb '21

Thinking of IPv6: How far has the team got in implementing IPv6 only OR port facility ? Currently you can only run tor relay of any sort if there is open IPv4 OR port to the internet. This is getting a bit quaint. I am sure I am not alone in having much wasted bandwidth that could be put to good Tor use but they are only accessible via IPv6, while they can exit of course IPv4 and IPv6 I realise that so far, despite IPv6 being open on my main exit for some years, there is still little IPv6 traffic, but that might suddenly change. Gerry From: tor-relays <tor-relays-bounces(a)lists.torproject.org> On Behalf Of Onion Operator Sent: 24 February 2021 10:08 To: tor-relays(a)lists.torproject.org Subject: [tor-relays] IPv6 auto-discovery vs. privacy extensions Saluton, My relay started to log this message since 0.4.5.5: Auto-discovered IPv6 address [...]:443 has not been found reachable. However, IPv4 address is reachable. Publishing server descriptor without IPv6 address. [2 similar message(s) suppressed in last 2400 seconds] I think it started with the introduction of IPv6 auto-discovery. The problem, as I understand it, is that my relay has IPv6 privacy extensions enabled and therefore the IPv6 detection logic gets fooled. Indeed the IPv6 I see in the logs is one of the temporary addresses used as client towards other relays. Relevant config is: ORPort 443 IPv4Only ORPort [...]:443 IPv6Only I added the IPv{4,6}Only options only in searching a solution to this problem, before 0.4.5.5 the IPv6 relay worked perfectly without. In reading the documentation of AddressDisableIPv6 I got the impression that if (any?) ORPort is configured with IPv4Only the IPv6 auto-discovery gets disabled but evidence does not support my understanding. Is it a bug? Any other way to disable IPv6 auto-discovery? -- flev

4 5

Stable flag and client load
by enrollado 22 Feb '21

22 Feb '21

I am running a bridge, realseven, fingerprint 10B5293C71793DC1E56A5B17434C0539F70FBB38. It's been up for 71 days and has yet to get the stable flag or more than 3 or 4 connected clients. Is there something misconfigured? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ No me preguntas nada, no te diré una mentira. Enrollado Sent with ProtonMail Secure Email.

2 2

anyone else getting sync floods from russia?
by niftybunny 22 Feb '21

22 Feb '21

https://i.imgur.com/nDbaXqH.png <https://i.imgur.com/nDbaXqH.png> https://i.imgur.com/Y5259wW.png It is now on a daily bases and it is starting to suck. nifty

4 8

Re: [tor-relays] Nyx
by Dr Gerard Bulger 21 Feb '21

21 Feb '21

Fixed it by installing from deb file. -----Original Message----- From: Dr Gerard Bulger <gerard(a)bulger.co.uk> Sent: 21 February 2021 19:09 To: 'tor-relays(a)lists.torproject.org' <tor-relays(a)lists.torproject.org> Subject: Nyx Sorry if wrong forum Nyx install out of the box, never had this error on starting before Ubuntu 18.04 Traceback (most recent call last): File "/usr/bin/nyx", line 11, in <module> load_entry_point('nyx==2.0.4', 'console_scripts', 'nyx')() File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 480, in load_entry_point return get_distribution(dist).load_entry_point(group, name) File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2693, in load_entry_point etc Tor itself is running happily What dependency is it missing. Purge and reinstall made no difference. Gerry

1 0

Nyx
by Dr Gerard Bulger 21 Feb '21

21 Feb '21

Sorry if wrong forum Nyx install out of the box, never had this error on starting before Ubuntu 18.04 Traceback (most recent call last): File "/usr/bin/nyx", line 11, in <module> load_entry_point('nyx==2.0.4', 'console_scripts', 'nyx')() File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 480, in load_entry_point return get_distribution(dist).load_entry_point(group, name) File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2693, in load_entry_point etc Tor itself is running happily What dependency is it missing. Purge and reinstall made no difference. Gerry

1 0

metrics
by Manager 21 Feb '21

21 Feb '21

2 1

relayor v21.0.0 is released
by nusenu 20 Feb '21

20 Feb '21

Hi, relayor v21.0.0 is released. relayor is an ansible [1] role that helps you with running tor relays with minimal effort (automate everything). https://github.com/nusenu/ansible-relayor [1] https://www.ansible.com/ This version contains a bugfix: * the GPG key for deb.torproject.org expired and we shipped the expired version, we now fetch the public key directly from torproject.org instead of shipping it with the ansible role. The relayor signing key itself has also been updated: https://keys.openpgp.org/search?q=A7B5DB91CE04C9E0BE66446B8CBE52BD4D705DE9 https://github.com/nusenu/ansible-relayor/releases/tag/v21.0.0 kind regards, nusenu -- https://nusenu.github.io

1 0

TOR Exit Relay Bandwidth Drop
by pimpnet 19 Feb '21

19 Feb '21

I run a fast tor exit relay. It goes to 100MB/s easy after a few days but every 2 weeks something happens (no hardware/network issue on this node locally) and the tor bandwidth drops down to 1-2MB/s. Then I have to stop the tor service and start it again after a couple mins. Most of the times, I am not aware this has happened and the exit relay then takes 10 days to start pumping full bandwidth again The server runs Ubuntu 18.04 LTS Seeking advice from some big brains here, thanks.

1 0

orport
by Anonforpeace 18 Feb '21

18 Feb '21

Hello: Am trying to configure my bridge according to instructions on Tor site. Using Ubuntu. No matter what port I pick for the ORPort I keep getting this error: Unable to find IPv4 address for ORPort 80. You might want to specify IPv4Only to it or set an explicit address or set Address. Have never seen this before. Please help. Thanks

3 4

Optimizing Tor Relay
by friendlyexitnode 17 Feb '21

17 Feb '21

Hello everyone, I'm running a very small family of exit nodes (who are friendly) and was curious if anyone had any advice on ways to optimize their relay configuration? I'm running them all on Ubuntu 20.04. I've reviewed the [Arch Wiki,](https://wiki.archlinux.org/index.php/Tor#+100Mbps_Exit_Relay_configu… but didn't notice much of an improvement. Anyone have an advice to improve Tor performance for relays? - The Friendly Exit Node Family

2 1

Is my relay broken? No stable, hsdir or guard flags
by raltullou＠posteo.org 17 Feb '21

17 Feb '21

Hi, I'm looking for help because I can't figure out what's going on. https://metrics.torproject.org/rs.html#details/11DF0017A43AF1F08825CD5D9732… - At the beginning of January the relay seems to have lost the guard flag - A week ago I checked and noticed that the relay had also lost the stable flag despite having an uptime of >2 months at that point - A week ago I rebooted the server but the situations hasn't changed - flags are still gone - metrics.torproject graphs show that the server has been transmitting data the entire time - so it doesn't seem like I missed some downtime - Serverlogs show no problems - Relay has been running continuously for almost 4 years and only gets rebooted for kernel/tor upgrades -> so uptime and MTBF should not be a problem Is there a problem on my side? Is there anything I can do or check? It is a fallback relay - is it still useful as such? TY

4 7

Huge increase in bridge connections
by Eddie 14 Feb '21

14 Feb '21

Just trying to understand if this is normal or if something else is going on. I have 2 bridges on a VPS. One is designated as "moat", the other "email". Until earlier today, for over a year, both averaged under 10 unique clients, per 6-hour reporting period. Today, the "moat" bridge, in a single period went from single digits to almost 300 unique clients. Is this normal/possible or what other explanation could there be.

4 3

Bridge Location matter?
by Astroskis Lists 13 Feb '21

13 Feb '21

Hello, Does the physical location matter for a Bridge? For example if I'm able to put it in a unusual geographical place would that benefit the network? I'm asking because I believe when you request a bridge it does not take location into account so would it matter? Thank you

3 3

ulyssa
by Anonforpeace 12 Feb '21

12 Feb '21

Hello: Does anyone know what repo I need to install for Linux Mint Ulyssa 20.1? Trying to update my bridge and can't find this repo. Thanks

2 1

Re: [tor-relays] 'reserved' bridge distribution mechanism average time until use
by Robert Bloch 11 Feb '21

11 Feb '21

How long does it take for a bridge with 'reserved' bridge distribution to see its first user? On average.

1 0

cannot update respository
by Anonforpeace 10 Feb '21

10 Feb '21

Hello: I hope you can help. My bridge is offline because: Please upgrade! This version of Tor (0.4.2.7) is not recommended, according to the directory authorities. Recommended versions are: 0.3.5.10,0.3.5.11,0.3.5.12,0.3.5.13,0.4.3.3-alpha,0.4.3.4-rc,0.4.3.5,0.4.3.6,0.4.3.7,0.4.3.8,0.4.4.1-alpha,0.4.4.2-alpha,0.4.4.3-alpha,0.4.4.4-rc,0.4.4.5,0.4.4.6,0.4.4.7,0.4.5.1-alpha,0.4.5.2-alpha,0.4.5.3-rc,0.4.5.4-rc,0.4.5.5-rc,0.4.5.6 When I try to update it I get this: darkhoodie@darkhoodie-HP-Compaq-Pro-6300-SFF:~$ lsb_release -c Codename: ulyssa darkhoodie@darkhoodie-HP-Compaq-Pro-6300-SFF:~$ cd /etc/apt/sources.list bash: cd: /etc/apt/sources.list: Not a directory darkhoodie@darkhoodie-HP-Compaq-Pro-6300-SFF:~$ cd /etc/apt/sources.list.d/ darkhoodie@darkhoodie-HP-Compaq-Pro-6300-SFF:/etc/apt/sources.list.d$ sudo nano /etc/apt/sources.list.d darkhoodie@darkhoodie-HP-Compaq-Pro-6300-SFF:/etc/apt/sources.list.d$ ls official-package-repositories.list tor-project.list darkhoodie@darkhoodie-HP-Compaq-Pro-6300-SFF:/etc/apt/sources.list.d$ sudo nano /etc/apt/sources.list.d/ darkhoodie@darkhoodie-HP-Compaq-Pro-6300-SFF:/etc/apt/sources.list.d$ lsb_release -c Codename: ulyssa darkhoodie@darkhoodie-HP-Compaq-Pro-6300-SFF:/etc/apt/sources.list.d$ sudo nano /etc/apt/sources.list.d/ darkhoodie@darkhoodie-HP-Compaq-Pro-6300-SFF:/etc/apt/sources.list.d$ wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E8… | gpg --import gpg: key EE8CBC9E886DDD89: 83 signatures not checked due to missing keys gpg: error writing keyring '/home/darkhoodie/.gnupg/pubring.kbx': Permission denied gpg: error reading '[stdin]': Permission denied gpg: import from '[stdin]' failed: Permission denied gpg: Total number processed: 0 darkhoodie@darkhoodie-HP-Compaq-Pro-6300-SFF:/etc/apt/sources.list.d$ sudo wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E8… | gpg --import gpg: key EE8CBC9E886DDD89: 83 signatures not checked due to missing keys gpg: error writing keyring '/home/darkhoodie/.gnupg/pubring.kbx': Permission denied gpg: error reading '[stdin]': Permission denied gpg: import from '[stdin]' failed: Permission denied gpg: Total number processed: 0 darkhoodie@darkhoodie-HP-Compaq-Pro-6300-SFF:/etc/apt/sources.list.d$ sudo gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | apt-key add - gpg: directory '/root/.gnupg' created gpg: keybox '/root/.gnupg/pubring.kbx' created gpg: WARNING: nothing exported E: This command can only be used by root. darkhoodie@darkhoodie-HP-Compaq-Pro-6300-SFF:/etc/apt/sources.list.d$ sudo apt update Ign:1 http://packages.linuxmint.com ulyssa InRelease Hit:2 http://packages.linuxmint.com ulyssa Release Hit:3 http://archive.canonical.com/ubuntu focal InRelease Hit:5 http://security.ubuntu.com/ubuntu focal-security InRelease Hit:6 http://archive.ubuntu.com/ubuntu focal InRelease Hit:7 http://archive.ubuntu.com/ubuntu focal-updates InRelease Hit:8 http://archive.ubuntu.com/ubuntu focal-backports InRelease Ign:9 https://deb.torproject.org/torproject.org ulyssa InRelease Err:10 https://deb.torproject.org/torproject.org ulyssa Release 404 Not Found [IP: 95.216.163.36 443] Reading package lists... Done N: Ignoring file 'sources.list.d' in directory '/etc/apt/sources.list.d/' as it has an invalid filename extension E: The repository 'https://deb.torproject.org/torproject.org ulyssa Release' does not have a Release file. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details. darkhoodie@darkhoodie-HP-Compaq-Pro-6300-SFF:/etc/apt/sources.list.d$ Not sure where I'm going wrong. Please help. Thank you

2 1

Re: [tor-relays] Tor on Rpi (relay.jackash@simplelogin.fr)
by Patrice Bönig 10 Feb '21

10 Feb '21

> Hello Patrice > > would be great if you can share your script , thanks. Hi, sure, with pleasure. But I have to say I am not a professional programmer. There are surely better ways to do this, but it works for me. Before you can use it you have to make it executable with this command: chmod +x build_tor_from_source.sh And make sure to read the info in the script. After that you are ready to roll. regards Patrice ## build_tor_from_source.sh ######################################################################## ####################################################### ## This script is for a automatic installation of tor out of the sources. ## What it will do: # # 1. It downloads the newest tarball, compiles and installs it. # 2. It copies the data dir (with the keys) and the torrc. # 3. It removes all installations files. # 4. It starts tor as the current user # 5. It adds tor as crontab (@bootup) of current user # 6. changes the permissions of the tor logs, tor folder and torrc for the current user # 6. At the end it shows the logs to check the tor startup process ## What are the requirements for this installation script # # - the torrc must be in the same folder as this script # - check the paths used in this script if they fit for your system (the default paths are for Pi OS) # - this script must be in a location where it has write permisssions (for example home folder of current user) ## What this script can't do # # Tor is not compiled wioth systemd support, so this won't work until you switch it on. ####################################################### #! /bin/bash # echo output colour # green="tput setaf 2" white="tput setaf 7" yellow="tput setaf 3" red="tput setaf 1" ##################### $yellow echo -e "\n\n####################" echo -e "# Tor Installation #" echo -e "####################\n" # show tor version for comparison $yellow echo -e "\nTor version on the system ->" $green tor --version | cut -b 13-20 echo # new line $yellow echo -e "Tor version online available ->" $green lynx -nonumbers -dump https://dist.torproject.org | grep "https://dist.torproject.org/tor-" | grep -v "alpha" | grep -v "rc" | grep -v "asc" | tail -1 | cut -b 33-40 # question for installation $red echo -e "\n\n" read -p "Installing new version? [y/n]: " -n 1 -r echo if [[ $REPLY =~ ^[Yy]$ ]] then $green echo -e "\nstopping tor on system...\n" $white sudo killall tor $green echo -e "\ndone.\n" $green echo -e "\nsystem update and installing needed packages...\n" $white sudo apt update sudo apt upgrade -y sudo apt install -y libevent-dev libssl-dev zlib1g-dev asciidoc lynx $green echo -e "\ndone.\n" $white build_dir="temp" mkdir $build_dir cd $build_dir # in ./temp $green echo -e "\ndownloading tor from git repo...\n" $white lynx -nonumbers -dump https://dist.torproject.org | grep "https://dist.torproject.org/tor-" | grep -v "alpha" | grep -v "rc" | grep -v "asc" | tail -1 | xargs wget tar -xvf tor*.tar.gz cd `ls -d */` # in ./temp/tor-* $green echo -e "\ndone.\n" $green echo -e "\nbacking up data dir, and changing its user..." $white sudo cp -arv /var/lib/tor ./tor sudo chown -R $(whoami) ./tor $green echo -e "\ndone.\n" $green echo -e "\ncompiling, removing old version, installing new version...\n" $white ./configure && make && sudo make uninstall && sudo make install $green echo -e "\ndone.\n" $green echo -e "\ncopying torrc and restoring data directory...\n" $white sudo cp -av ../../torrc /usr/local/etc/tor/torrc sudo chwon $(whoami):root /usr/local/etc/tor/torrc sudo cp -arv ./tor /var/lib/tor $green echo -e "\ndone.\n" cd .. # in ./temp cd .. # in ./ $green echo -e "\nremoving build folder and system files...\n" $white sudo rm -R $build_dir sudo apt autoclean sudo apt autoremove $green echo -e "\ndone.\n" $green echo -e "\nadding tor as crontab to start tor on boot...\n" $white if sudo grep -q "@reboot /usr/local/bin/tor --quiet" /var/spool/cron/crontabs/$(whoami) then echo -e "tor is already present as crontab" else #echo -e "@reboot /usr/local/bin/tor --quiet" | sudo tee -a /var/spool/cron/crontabs/$(whoami) echo -e "tor is added as crontab" fi $green echo -e "\ndone.\n" $green echo -e "\nchanging user of log files...\n" $white sudo chown -R $(whoami) /var/log/tor $green echo -e "\ndone.\n" $green echo -e "\nstarting tor...\n" $white # start tor /usr/local/bin/tor --quiet echo # new line $yellow echo -e "\ntor log\n" $white sudo tail -c+1 -f /var/log/tor/notices.log else $white exit 1 fi ########################################################################

1 0

tor on Ubuntu Server 20.04.2 LTS
by tor 09 Feb '21

09 Feb '21

Hi All, Which version of tor runs on Ubuntu Server 20.04.2 LTS 64bit, if any? Thanks matt

1 0

Re: [tor-relays] Tor relay failed to start after upgrade (0.4.4.6 --> 0.4.5.5) [solved]
by David Goulet 09 Feb '21

09 Feb '21

On 09 Feb (11:55:12), tschador(a)posteo.de wrote: > Tonight my Tor relay on Raspberry Pi (buster) was upgraded from > 0.4.4.6-1~bpo10+1 to 0.4.5.5-rc-1~bpo10+1 automaticly, but failed to start: > > --- > [notice] Opening OR listener on 0.0.0.0:587 > [notice] Opened OR listener connection (ready) on 0.0.0.0:587 > [notice] Opening OR listener on [::]:587 > [warn] Socket creation failed: Address family not supported by protocol > [notice] Opening Directory listener on 0.0.0.0:995 > [notice] Closing partially-constructed OR listener connection (ready) on > 0.0.0.0:587 > [notice] Closing partially-constructed Directory listener connection (ready) > on 0.0.0.0:995 > --- > > Until then there was no change in my torrc: > > ORPort 587 > DIRPORT 995 Oh wow, interesting, so your Pi doesn't support IPv6 for some reasons and it failed to start with this config. I have opened: https://gitlab.torproject.org/tpo/core/tor/-/issues/40283 In 0.4.5.x tor, things have changed where tor will try to auto discover an IPv6 and automatically bind to it if only "ORPort <PORT>" is used. In other words, it now binds to 0.0.0.0 and [::] by default. It then publish any discovered _usable_ and _reachable_ IPv4/IPv6. If it doesn't find any IPv6, it will still listen but won't publish any IPv6. > > It seems the value [address:] is no longer optional if you're not IPv6 ready > [1]: > > ORPort [address:]PORT|auto [flags] > DirPort [address:]PORT|auto [flags] > > So I have to change my torrc to: > > ORPort 0.0.0.0:587 > DIRPORT 0.0.0.0:995 Another option would have been to add the "IPv4Only" flag to the ORPort line and should have done it for you. Cheers! David -- YrY9JHvSOJpDfyKS5AyL8h/BjZ/SQEkh00q9ek+1BXk=

1 0