[tor-relays] Tor relay/btc node script

Sharif Olorin sio at tesser.org
Mon May 18 06:46:34 UTC 2015


> Please give me any comments criticisms. Appreciated. 

Just a few comments from a quick read through:

 - The code you have to upgrade to jessie (presumably from wheezy) isn't
   very safe (for instance, what if the server needs custom repositories
   in its sources.list which the script wipes out?). In the UNIX
   tradition of doing one thing well, I'd suggest just telling the user
   they need to upgrade first and exiting if they're still on wheezy.
   (Sidenote, you can get this information from /etc/debian_version; you
   don't need to ask the user.)

 - > echo -e "\033[1;33m""If you're on a shared/virtual server you can't set the time
   This isn't usually true. For example, KVM provides paravirtualized
   access to the system clock. In either case, running ntpd is best
   practice on the guest always - I'm not sure what the advantage is in
   stopping ntpd, running ntpdate and starting ntpd again.

 - You use sudo in a lot of places, but you also exit at the top if the
   script isn't run as root; it isn't necessary to do both.

 - Related to the above, it's not a good idea to do things like building
   packages (particularly those downloaded from the web) as root; I'd
   recommend having your script run as an unprivileged user and using
   sudo for e.g., invoking apt-get or the final `sudo make install` step.

 - Given that your script is intended for jessie hosts, it'd be nice to
   have bitcoind run under systemd (put a unit file for the bitcoind
   service under /etc/systemd); use of rc.local is definitely
   deprecated. Likewise, using systemd would eliminate the need to set up
   logrotate and would have the added advantage of all daemon logs being in
   the same place (journald).

 - For safety reasons, all complex scripts like this should start with
   `set -e` - that way if a particular command fails the script will
   stop executing, rather than continuing in an inconsistent state and
   possibly breaking something.


PGP: 6FB7 ED25 BFCF 3E22 72AE 6E8C 47D4 CE7F 6B9F DF57
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20150518/d87a6d24/attachment.sig>

More information about the tor-relays mailing list