Trouble Running Middle Relay On Google Cloud Debian VBS
Hi all, So I am starting a new middle relay using a VPS hosted on Google Cloud running Debian. though the relay is running, it is not appearing in the consensus after 10 hours. Here is the tor log, any thoughts on what is going on would be greatly appreciated thank you. May 15 18:23:47.096 [notice] Opening OR listener on 0.0.0.0:65534 May 15 18:23:47.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. May 15 18:23:47.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. May 15 18:23:47.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. May 15 18:23:47.000 [warn] You are running Tor as root. You don't need to, and you probably shouldn't. May 15 18:23:47.000 [notice] Your Tor server's identity key fingerprint is 'torworld 3A4E582092E7C6B822EC01F4D76F680F6C65B0A2' May 15 18:23:47.000 [notice] Bootstrapped 0%: Starting May 15 18:23:50.000 [notice] Bootstrapped 80%: Connecting to the Tor network May 15 18:23:51.000 [notice] Guessed our IP address as 35.238.140.120 (source: 193.23.244.244). May 15 18:23:52.000 [notice] Bootstrapped 85%: Finishing handshake with first hop May 15 18:23:52.000 [notice] Bootstrapped 90%: Establishing a Tor circuit May 15 18:23:53.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. May 15 18:23:53.000 [notice] Bootstrapped 100%: Done May 15 18:23:53.000 [notice] Now checking whether ORPort 35.238.140.120:65534 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) May 15 18:23:54.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. May 15 18:23:56.000 [notice] Performing bandwidth self-test...done. May 16 00:23:50.000 [notice] Heartbeat: It seems like we are not in the cached consensus. May 16 00:23:50.000 [notice] Heartbeat: Tor's uptime is 5:59 hours, with 0 circuits open. I've sent 789 kB and received 7.41 MB. May 16 00:23:50.000 [notice] Average packaged cell fullness: 100.000%. TLS write overhead: 27% May 16 00:23:50.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 6/6 NTor. May 16 00:23:50.000 [notice] Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 8 v4 connections; and received 1 v1 connections, 0 v2 connections, 0 v3 connections, and 6 v4 connections. May 16 00:23:50.000 [notice] DoS mitigation since startup: 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. May 16 00:58:51.000 [warn] Received http status code 404 ("Not found") from server '45.62.242.212:9030' while fetching consensus directory. I also had another thing I wanted to ask. I am working on a crontab script to automatically update and restart the tor relay once a month automatically, as I am already running a bridge on another network that needs to be updated manually. Does this script look like it would get the job done? I don't have much experience with crontab. # m h dom mon dow command 0 0 1 * * apt-get update apt update && apt install -y --only-upgrade tor killall tor tor root@instance-1:/home/keifer_bly# Thank you very much. --Keifer
Keifer, I think your Cron script is problematic. The script: 0 0 1 * * apt-get update apt update && apt install -y --only-upgrade tor killall tor tor Would kill Tor and since you don't have "&& tor" after the "killall tor", it is not restarting it. But I'd advise just giving up on cron. For automatic updates, you should look into unattended-upgrades instead of using cron. Also, forcefully killing Tor using cron isn't a good idea because it would terminate circuits using your relay instead of gracefully stopping them. Disclaimer: I don't run Debian on my relays. I run FreeBSD relays. I have used Debian on my desktop briefly in 2012 before switching to FreeBSD as a desktop. I have never **really** run Debian as a server so I can't help you further with unattended-upgrades. -Neel === https://www.neelc.org/ On 2019-05-16 01:26, Keifer Bly wrote:
Hi all,
So I am starting a new middle relay using a VPS hosted on Google Cloud running Debian. though the relay is running, it is not appearing in the consensus after 10 hours. Here is the tor log, any thoughts on what is going on would be greatly appreciated thank you.
May 15 18:23:47.096 [notice] Opening OR listener on 0.0.0.0:65534 [1] May 15 18:23:47.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. May 15 18:23:47.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. May 15 18:23:47.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. May 15 18:23:47.000 [warn] You are running Tor as root. You don't need to, and you probably shouldn't. May 15 18:23:47.000 [notice] Your Tor server's identity key fingerprint is 'torworld 3A4E582092E7C6B822EC01F4D76F680F6C65B0A2' May 15 18:23:47.000 [notice] Bootstrapped 0%: Starting May 15 18:23:50.000 [notice] Bootstrapped 80%: Connecting to the Tor network May 15 18:23:51.000 [notice] Guessed our IP address as 35.238.140.120 (source: 193.23.244.244). May 15 18:23:52.000 [notice] Bootstrapped 85%: Finishing handshake with first hop May 15 18:23:52.000 [notice] Bootstrapped 90%: Establishing a Tor circuit May 15 18:23:53.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. May 15 18:23:53.000 [notice] Bootstrapped 100%: Done May 15 18:23:53.000 [notice] Now checking whether ORPort 35.238.140.120:65534 [2] is reachable... (this may take up to 20 minutes -- look for log messages indicating success) May 15 18:23:54.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. May 15 18:23:56.000 [notice] Performing bandwidth self-test...done. May 16 00:23:50.000 [notice] Heartbeat: It seems like we are not in the cached consensus. May 16 00:23:50.000 [notice] Heartbeat: Tor's uptime is 5:59 hours, with 0 circuits open. I've sent 789 kB and received 7.41 MB. May 16 00:23:50.000 [notice] Average packaged cell fullness: 100.000%. TLS write overhead: 27% May 16 00:23:50.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 6/6 NTor. May 16 00:23:50.000 [notice] Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 8 v4 connections; and received 1 v1 connections, 0 v2 connections, 0 v3 connections, and 6 v4 connections. May 16 00:23:50.000 [notice] DoS mitigation since startup: 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. May 16 00:58:51.000 [warn] Received http status code 404 ("Not found") from server '45.62.242.212:9030 [3]' while fetching consensus directory.
I also had another thing I wanted to ask. I am working on a crontab script to automatically update and restart the tor relay once a month automatically, as I am already running a bridge on another network that needs to be updated manually.
Does this script look like it would get the job done? I don't have much experience with crontab.
# m h dom mon dow command
0 0 1 * * apt-get update apt update && apt install -y --only-upgrade tor killall tor tor root@instance-1:/home/keifer_bly#
Thank you very much.
--Keifer
Links: ------ [1] http://0.0.0.0:65534 [2] http://35.238.140.120:65534 [3] http://45.62.242.212:9030 _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Thanks. I wonder why the relay is not showing up in the consensus, it is sending and reiceving data but is showing this error. ay 16 00:58:51.000 [warn] Received http status code 404 ("Not found") from server ' 45.62.242.212:9030' while fetching consensus directory. Heartbeat: It seems like we are not in the cached consensus. I wonder why might this might be. Thanks. --Keifer On Fri, May 17, 2019 at 1:26 AM Neel Chauhan <neel@neelc.org> wrote:
Keifer,
I think your Cron script is problematic.
The script:
0 0 1 * * apt-get update apt update && apt install -y --only-upgrade tor killall tor tor
Would kill Tor and since you don't have "&& tor" after the "killall tor", it is not restarting it.
But I'd advise just giving up on cron. For automatic updates, you should look into unattended-upgrades instead of using cron.
Also, forcefully killing Tor using cron isn't a good idea because it would terminate circuits using your relay instead of gracefully stopping them.
Disclaimer: I don't run Debian on my relays. I run FreeBSD relays. I have used Debian on my desktop briefly in 2012 before switching to FreeBSD as a desktop. I have never **really** run Debian as a server so I can't help you further with unattended-upgrades.
-Neel
===
On 2019-05-16 01:26, Keifer Bly wrote:
Hi all,
So I am starting a new middle relay using a VPS hosted on Google Cloud running Debian. though the relay is running, it is not appearing in the consensus after 10 hours. Here is the tor log, any thoughts on what is going on would be greatly appreciated thank you.
May 15 18:23:47.096 [notice] Opening OR listener on 0.0.0.0:65534 [1] May 15 18:23:47.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. May 15 18:23:47.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. May 15 18:23:47.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. May 15 18:23:47.000 [warn] You are running Tor as root. You don't need to, and you probably shouldn't. May 15 18:23:47.000 [notice] Your Tor server's identity key fingerprint is 'torworld 3A4E582092E7C6B822EC01F4D76F680F6C65B0A2' May 15 18:23:47.000 [notice] Bootstrapped 0%: Starting May 15 18:23:50.000 [notice] Bootstrapped 80%: Connecting to the Tor network May 15 18:23:51.000 [notice] Guessed our IP address as 35.238.140.120 (source: 193.23.244.244). May 15 18:23:52.000 [notice] Bootstrapped 85%: Finishing handshake with first hop May 15 18:23:52.000 [notice] Bootstrapped 90%: Establishing a Tor circuit May 15 18:23:53.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. May 15 18:23:53.000 [notice] Bootstrapped 100%: Done May 15 18:23:53.000 [notice] Now checking whether ORPort 35.238.140.120:65534 [2] is reachable... (this may take up to 20 minutes -- look for log messages indicating success) May 15 18:23:54.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. May 15 18:23:56.000 [notice] Performing bandwidth self-test...done. May 16 00:23:50.000 [notice] Heartbeat: It seems like we are not in the cached consensus. May 16 00:23:50.000 [notice] Heartbeat: Tor's uptime is 5:59 hours, with 0 circuits open. I've sent 789 kB and received 7.41 MB. May 16 00:23:50.000 [notice] Average packaged cell fullness: 100.000%. TLS write overhead: 27% May 16 00:23:50.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 6/6 NTor. May 16 00:23:50.000 [notice] Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 8 v4 connections; and received 1 v1 connections, 0 v2 connections, 0 v3 connections, and 6 v4 connections. May 16 00:23:50.000 [notice] DoS mitigation since startup: 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. May 16 00:58:51.000 [warn] Received http status code 404 ("Not found") from server '45.62.242.212:9030 [3]' while fetching consensus directory.
I also had another thing I wanted to ask. I am working on a crontab script to automatically update and restart the tor relay once a month automatically, as I am already running a bridge on another network that needs to be updated manually.
Does this script look like it would get the job done? I don't have much experience with crontab.
# m h dom mon dow command
0 0 1 * * apt-get update apt update && apt install -y --only-upgrade tor killall tor tor root@instance-1:/home/keifer_bly#
Thank you very much.
--Keifer
Links: ------ [1] http://0.0.0.0:65534 [2] http://35.238.140.120:65534 [3] http://45.62.242.212:9030 _______________________________________________ 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
On 17.05.2019 02:22, Neel Chauhan wrote:
But I'd advise just giving up on cron. For automatic updates, you should look into unattended-upgrades instead of using cron. +1
on Debian: apt-get install -y unattended-upgrades apt-listchanges cp /usr/share/unattended-upgrades/20auto-upgrades /etc/apt/apt.conf.d/20auto-upgrades service unattended-upgrades restart Default it upgrades the security sources. see comments in 50unattended-upgrades -- Ciao Marco!
on Debian:
apt-get install -y unattended-upgrades apt-listchanges cp /usr/share/unattended-upgrades/20auto-upgrades /etc/apt/apt.conf.d/20auto-upgrades service unattended-upgrades restart This is what happened after running that. root@instance-1:/home/keifer_bly# apt-get install -y unattended-upgrades apt-listchanges Reading package lists... Done Building dependency tree Reading state information... Done apt-listchanges is already the newest version (3.10). unattended-upgrades is already the newest version (0.93.1+nmu1). 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. root@instance-1:/home/keifer_bly# cp /usr/share/unattended-upgrades/20auto-upgrades cp: missing destination file operand after '/usr/share/unattended-upgrades/20auto-upgrades' Try 'cp --help' for more information. What file would be missing I wonder? Thanks. --Keifer On Sat, May 18, 2019 at 6:35 AM <lists@for-privacy.net> wrote:
On 17.05.2019 02:22, Neel Chauhan wrote:
But I'd advise just giving up on cron. For automatic updates, you should look into unattended-upgrades instead of using cron. +1
on Debian:
apt-get install -y unattended-upgrades apt-listchanges cp /usr/share/unattended-upgrades/20auto-upgrades /etc/apt/apt.conf.d/20auto-upgrades service unattended-upgrades restart
Default it upgrades the security sources. see comments in 50unattended-upgrades
-- Ciao Marco! _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Oh sorry. What it actually says is everything is already up to date. So I wonder, why would the relay not appear in the consensus? Thanks. --Keifer On Sat, May 18, 2019 at 11:23 AM Keifer Bly <keifer.bly@gmail.com> wrote:
on Debian:
apt-get install -y unattended-upgrades apt-listchanges cp /usr/share/unattended-upgrades/20auto-upgrades /etc/apt/apt.conf.d/20auto-upgrades service unattended-upgrades restart
This is what happened after running that.
root@instance-1:/home/keifer_bly# apt-get install -y unattended-upgrades apt-listchanges Reading package lists... Done Building dependency tree Reading state information... Done apt-listchanges is already the newest version (3.10). unattended-upgrades is already the newest version (0.93.1+nmu1). 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. root@instance-1:/home/keifer_bly# cp /usr/share/unattended-upgrades/20auto-upgrades cp: missing destination file operand after '/usr/share/unattended-upgrades/20auto-upgrades' Try 'cp --help' for more information.
What file would be missing I wonder? Thanks.
--Keifer
On Sat, May 18, 2019 at 6:35 AM <lists@for-privacy.net> wrote:
On 17.05.2019 02:22, Neel Chauhan wrote:
But I'd advise just giving up on cron. For automatic updates, you should look into unattended-upgrades instead of using cron. +1
on Debian:
apt-get install -y unattended-upgrades apt-listchanges cp /usr/share/unattended-upgrades/20auto-upgrades /etc/apt/apt.conf.d/20auto-upgrades service unattended-upgrades restart
Default it upgrades the security sources. see comments in 50unattended-upgrades
-- Ciao Marco! _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
May 18 07:20:01.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 5/5 NTor. May 18 07:20:01.000 [notice] Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 6 v4 connections; and received 0 v1 connections, 0 v2 connections, 0 v3 connections, and 5 v4 connections. May 18 07:20:01.000 [notice] DoS mitigation since startup: 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. May 18 13:20:01.000 [notice] Heartbeat: It seems like we are not in the cached consensus. May 18 13:20:01.000 [notice] Heartbeat: Tor's uptime is 11:59 hours, with 0 circuits open. I've sent 877 kB and received 15.21 MB. May 18 13:20:01.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 0/0 NTor. May 18 13:20:01.000 [notice] Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 6 v4 connections; and received 0 v1 connections, 0 v2 connections, 0 v3 connections, and 5 v4 connections. May 18 13:20:01.000 [notice] DoS mitigation since startup: 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. This is the recent log. So it is sending and receiving data but not appearing in the relay list. I wonder why that might be? Thanks. --Keifer On Sat, May 18, 2019 at 11:40 AM Keifer Bly <keifer.bly@gmail.com> wrote:
Oh sorry. What it actually says is everything is already up to date. So I wonder, why would the relay not appear in the consensus? Thanks. --Keifer
On Sat, May 18, 2019 at 11:23 AM Keifer Bly <keifer.bly@gmail.com> wrote:
on Debian:
apt-get install -y unattended-upgrades apt-listchanges cp /usr/share/unattended-upgrades/20auto-upgrades /etc/apt/apt.conf.d/20auto-upgrades service unattended-upgrades restart
This is what happened after running that.
root@instance-1:/home/keifer_bly# apt-get install -y unattended-upgrades apt-listchanges Reading package lists... Done Building dependency tree Reading state information... Done apt-listchanges is already the newest version (3.10). unattended-upgrades is already the newest version (0.93.1+nmu1). 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. root@instance-1:/home/keifer_bly# cp /usr/share/unattended-upgrades/20auto-upgrades cp: missing destination file operand after '/usr/share/unattended-upgrades/20auto-upgrades' Try 'cp --help' for more information.
What file would be missing I wonder? Thanks.
--Keifer
On Sat, May 18, 2019 at 6:35 AM <lists@for-privacy.net> wrote:
On 17.05.2019 02:22, Neel Chauhan wrote:
But I'd advise just giving up on cron. For automatic updates, you should look into unattended-upgrades instead of using cron. +1
on Debian:
apt-get install -y unattended-upgrades apt-listchanges cp /usr/share/unattended-upgrades/20auto-upgrades /etc/apt/apt.conf.d/20auto-upgrades service unattended-upgrades restart
Default it upgrades the security sources. see comments in 50unattended-upgrades
-- Ciao Marco! _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Wed, 15 May 2019 22:26:25 -0700 Keifer Bly <keifer.bly@gmail.com> wrote:
Hi all,
So I am starting a new middle relay using a VPS hosted on Google Cloud running Debian. though the relay is running, it is not appearing in the consensus after 10 hours. Here is the tor log, any thoughts on what is going on would be greatly appreciated thank you.
May 15 18:23:53.000 [notice] Now checking whether ORPort 35.238.140.120:65534 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) May 15 18:23:54.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent.
FWIW this 35.238.140.120:65534 is not reachable right now from any of my machines. Did you change the port or IP since then? Also, I never used a Google VPS, but it appears you need to do extra steps to ensure you get a static external IP: https://cloud.google.com/compute/docs/ip-addresses/reserve-static-external-i... Did you do that? -- With respect, Roman
participants (4)
-
Keifer Bly -
lists＠for-privacy.net -
Neel Chauhan -
Roman Mamedov