Help With Autoupdating Tor Software
Hello, So on Mac OS X, I am using crontab to automatically run a script I wrote for Mac OS High Sierra to automatically update the tor relaying software every day at 1am. The cron command I am using is this: 0 1 * * * /Users/oldimac/Desktop/update\ tor.scpt The script I wrote seems to work fine for updating tor, however it seems to have trouble updating homebrew. Here are the contents of the script: do shell script "$ which brew /usr/local/bin/brew update" do shell script "$ which brew /usr/local/bin/brew upgrade tor" end When the script is run, the output is this: sh: $: command not found Error: tor 0.3.2.10 already installed So it seems to be that it updates tor ok but when it tries to update homebrew the error is “command not found”. I previously tried do shell script “brew update” however that only turns to a "command not found" error and only works in terminal but not AppleScript. Also, after writing the crontab command, I launched crontab via terminal via running “crontab” which loads to a blank Terminal screen. Do you know of a way I can check the script actually ran? Thank you very much.
Hi Keifer, Depending on the version of OS X you’re using (hopefully it’s a recent one), you might have more reliable script execution using Launchd rather than Cron. For your script, I would stick to bash as you seem to be combining AppleScript and shell script. Make the following text file: #!/bin/sh /usr/local/bin/brew update /usr/localbin/brew upgrade tor echo “script ran at `date`” >> /tmp/torupdate.log exit 0 Make the file executable by typing sudo chmod +x (filename) in the terminal and pressing enter. You will be prompted for your password. You can easily make a launchd plist file using the online zerowidth tool: http://launched.zerowidth.com/ <http://launched.zerowidth.com/> . Include the complete path to the script you just made in the launchd plist file as the command. Every time it runs it will write to the log file at /tmp/torupdate.log which you can clear by restarting your Mac. Drop your plist file into /Library/LaunchDaemons or ~/Library/LaunchDaemons and restart your computer to make it take effect. If this works for you, you may want to start modifying the script to stop Tor as it is being upgraded, restart it afterwards and perhaps add some more logging or alerts. Good luck! S
On 1 May 2018, at 18:58, Keifer Bly <keifer.bly@gmail.com> wrote:
Hello,
So on Mac OS X, I am using crontab to automatically run a script I wrote for Mac OS High Sierra to automatically update the tor relaying software every day at 1am.
The cron command I am using is this: 0 1 * * * /Users/oldimac/Desktop/update\ tor.scpt
The script I wrote seems to work fine for updating tor, however it seems to have trouble updating homebrew.
Here are the contents of the script:
do shell script "$ which brew /usr/local/bin/brew update" do shell script "$ which brew /usr/local/bin/brew upgrade tor" end
When the script is run, the output is this:
sh: $: command not found Error: tor 0.3.2.10 already installed
So it seems to be that it updates tor ok but when it tries to update homebrew the error is “command not found”.
I previously tried do shell script “brew update” however that only turns to a "command not found" error and only works in terminal but not AppleScript.
Also, after writing the crontab command, I launched crontab via terminal via running “crontab” which loads to a blank Terminal screen. Do you know of a way I can check the script actually ran?
Thank you very much.
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 2 May 2018, at 03:58, Keifer Bly <keifer.bly@gmail.com> wrote:
do shell script "$ which brew /usr/local/bin/brew update" do shell script "$ which brew /usr/local/bin/brew upgrade tor" end
When the script is run, the output is this:
$ which brew
sh: $: command not found
/usr/local/bin/brew upgrade tor
Error: tor 0.3.2.10 already installed
So it seems to be that it updates tor ok but when it tries to update homebrew the error is “command not found”.
No, bash can't find the $ command. This is probably a copy-paste error. Try running the lines of your script one at a time in the terminal. Or just remove the "$ which brew" line, it doesn't do anything. T
Thank you, I will try doing this. I also want to report an interesting find that happened to me. So today, I had to shut down my router for it to install a firmware update (it’s a netgear router, this firmware update will hopefully resolve my issue of dropping connections randomly). Here’s what happened: The firmware update ended up taking long enough for my relay to be removed form the conscious list. However, I did not restart the tor relaying software on my computer while my internet was offline as my router was installing the firmware update. When my relay reappeared, my uptime on both http://torstatus.blutmagie.de/router_detail.php?FP=db1af6477bb276b6ea5e72132... and also https://metrics.torproject.org/rs.html#details/DB1AF6477BB276B6EA5E721326840... jumped immediately back to “uptime: 5 days 3 hours” which had been my about uptime before I had to shut my router down. My suspicion is that my posted uptime was retained because I did not restart the relay software while my router firmware was updating (it was offline for about 2 hours), but it thought I’d share this little thing I noticed. Thank you. From: teor Sent: Tuesday, May 1, 2018 3:44 PM To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] Help With Autoupdating Tor Software
On 2 May 2018, at 03:58, Keifer Bly <keifer.bly@gmail.com> wrote:
do shell script "$ which brew /usr/local/bin/brew update" do shell script "$ which brew /usr/local/bin/brew upgrade tor" end
When the script is run, the output is this:
$ which brew
sh: $: command not found
/usr/local/bin/brew upgrade tor
Error: tor 0.3.2.10 already installed
So it seems to be that it updates tor ok but when it tries to update homebrew the error is “command not found”.
No, bash can't find the $ command. This is probably a copy-paste error. Try running the lines of your script one at a time in the terminal. Or just remove the "$ which brew" line, it doesn't do anything. T _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hi, On 02/05/18 02:09, Keifer Bly wrote:
My suspicion is that my posted uptime was retained because I did not restart the relay software while my router firmware was updating (it was offline for about 2 hours), but it thought I’d share this little thing I noticed.
You're correct. The uptime that is shown in relay search is calculated from your relay's self-reported last restart time. This means that if your relay has not restarted, it will have the same last restart time when it rejoins the consensus and your uptime will not start back from zero. Downtime on relay search is calculated from the time that the relay was last seen in a consensus, so this would start from zero at the first consensus that does not include your relay (and so also only has a resolution of one hour, whereas your last restart time has a resolution of one second). Onionoo (the relay search backend) does keep track of the fractional time a relay was included in the consensus for a given time period in the "relay uptime documents": https://metrics.torproject.org/onionoo.html#uptime This could be confusing, as now we have two definitions for uptime: 1) the relay was running and may or may not have been in the consensus, or 2) the relay was in the consensus. Maybe we should fix the ambiguity. Thanks, Iain.
On 2 May 2018, at 18:32, Iain Learmonth <irl@torproject.org> wrote:
On 02/05/18 02:09, Keifer Bly wrote: My suspicion is that my posted uptime was retained because I did not restart the relay software while my router firmware was updating (it was offline for about 2 hours), but it thought I’d share this little thing I noticed.
You're correct. The uptime that is shown in relay search is calculated from your relay's self-reported last restart time. This means that if your relay has not restarted, it will have the same last restart time when it rejoins the consensus and your uptime will not start back from zero.
Downtime on relay search is calculated from the time that the relay was last seen in a consensus, so this would start from zero at the first consensus that does not include your relay (and so also only has a resolution of one hour, whereas your last restart time has a resolution of one second).
Onionoo (the relay search backend) does keep track of the fractional time a relay was included in the consensus for a given time period in the "relay uptime documents":
https://metrics.torproject.org/onionoo.html#uptime
This could be confusing, as now we have two definitions for uptime: 1) the relay was running and may or may not have been in the consensus, or 2) the relay was in the consensus. Maybe we should fix the ambiguity.
Being in the consensus is called "Running", but what it actually means is that a majority of directory authorities found your relay reachable. So perhaps we could use: * uptime for the amount of time since the tor process started * reachable time for the amount of time the relay has been online and available to clients T
Hi, On 02/05/18 09:50, teor wrote:
Being in the consensus is called "Running", but what it actually means is that a majority of directory authorities found your relay reachable.
So perhaps we could use: * uptime for the amount of time since the tor process started * reachable time for the amount of time the relay has been online and available to clients
I will raise this issue at the next Metrics team meeting on Thursday. I'm not sure how many clients we would break if we rename the uptime documents, but maybe it's the right thing to do in the long run. Thanks, Iain.
On 2 May 2018, at 19:20, Iain Learmonth <irl@torproject.org> wrote:
On 02/05/18 09:50, teor wrote: Being in the consensus is called "Running", but what it actually means is that a majority of directory authorities found your relay reachable.
So perhaps we could use: * uptime for the amount of time since the tor process started * reachable time for the amount of time the relay has been online and available to clients
I will raise this issue at the next Metrics team meeting on Thursday. I'm not sure how many clients we would break if we rename the uptime documents, but maybe it's the right thing to do in the long run.
I think you should prioritise renaming things in relay search and the metrics website. Renaming backends isn't as high a priority: updating the specification is much cheaper, and it achieves a similar outcome. T
One more question, if I were to restart my relay now, would that mean that my mid time between failures would NOT get closer to 6 days? That’s what is at now. Thanks. Sent from my iPhone
On May 2, 2018, at 2:33 AM, teor <teor2345@gmail.com> wrote:
On 2 May 2018, at 19:20, Iain Learmonth <irl@torproject.org> wrote:
On 02/05/18 09:50, teor wrote: Being in the consensus is called "Running", but what it actually means is that a majority of directory authorities found your relay reachable.
So perhaps we could use: * uptime for the amount of time since the tor process started * reachable time for the amount of time the relay has been online and available to clients
I will raise this issue at the next Metrics team meeting on Thursday. I'm not sure how many clients we would break if we rename the uptime documents, but maybe it's the right thing to do in the long run.
I think you should prioritise renaming things in relay search and the metrics website.
Renaming backends isn't as high a priority: updating the specification is much cheaper, and it achieves a similar outcome.
T _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hi, On 02/05/18 19:20, Keifer Bly wrote:
One more question, if I were to restart my relay now, would that mean that my mid time between failures would NOT get closer to 6 days? That’s what is at now.
Assuming that you just restart it and it comes right back up again, and it's for the purpose of a software update, you should just restart it regardless. I'm not sure if a change in the last restarted date will affect your MTBF, but it's probably more important to update the relay and then worry about keeping it stable. Thanks, Iain.
participants (4)
-
Iain Learmonth -
Keifer Bly -
Spiros Andreou -
teor