> On Sep 5, 2019, at 11:44 AM, Matt Traudt <pastly@xxxxxxxxxxxxxx> wrote: > > On 9/4/19 22:43, teor wrote: >> Hi Mike, >> >> Here's some other reasons that might affect a few operators: >> >>> On 5 Sep 2019, at 12:11, Mike Perry <mikeperry@xxxxxxxxxxxxxx> wrote: >>> >>> Unfortunately, we still have something like 2500 relays on either Tor >>> 0.2.9-LTS or Tor 0.3.5-LTS. >>> >>> What are the reasons for this? My guess is the top 5 most common >>> responses are: >>> >>> 1. "I didn't know that Debian's backports repo has latest-stable Tor!" >>> 2. "I didn't see the Tor Project repos mentioned in Tor's Relay docs!" >>> 3. "I'm running a distribution that Tor Project doesn't have repos for." >>> 4. "I rolled my own custom Tor from git and forgot about it." >>> 5. "My relay machine was not getting any updates at all. Oops." >>> >>> Does anyone have a reason that they think many other relay operators >>> also share? >> >> 6. When I tried to update, it didn't work with my old config >> 7. I need features that only exist in older Tors >> - I can think of Tor2web, there may be others >> 8. I am maintaining research or other patches against tor, and rebases >> are difficult >> > > Regarding my relays, which currently are [0] > > - Two were stuck on 0.3.4.11 because I had to install Tor from source on > that machine and am bad about updating it (just updated) > - Two are stuck on 0.3.5.7 because research and rebasing to new versions > is liable to create inconsistencies and general doubt about results > > [0]: https://metrics.torproject.org/rs.html#search/contact:pastly > >>> How can we fix that for you, or at least, how can we make it easier to >>> run the very latest stable series Tor on your relay? > > This is a huge ask and I don't expect anything to come of this > suggestion, but: > > Auto updates from within Tor itself (not relying on distro package > managers). Put it behind a torrc option, allow the authorities to tell > relays with the option enabled to download a new tor binary from $PLACE, > create a bunch of infrastructure that builds Tor for all supported > platforms reliably and efficiently, use a bunch of signatures everywhere > so nothing bad can happen, done. So easy a caveman could do it, nothing > bad could ever happen, absolutely no downsides, it's $CURRENT_YEAR so > why don't we have this, etc. etc. > > -- > Matt This may not matter for LTS versions, but I just wanted to mention it it in reference it to the possible idea that Tor possibly updating itself. I’ve never relied on the OS Package of Tor, mainly because OS’s OpenSSL versions are behind the current version of OpenSSL, so I normally compile Tor against the latest OpenSSL. Example, FreeBSD 12.0-RELEASE has OpenSSL 1.1.1a-freebsd, which generates a slight crypto error during the startup of Tor. If you download OpenSSL 1.1.1c and just compile against it, eh, problem fixed. Sorry, maybe I just don’t like seeing errors :). Anyway, why don’r we try to simplify the update process even further and just ship Tor with some ansible scripts that will replace the binary, check the config file and comment out any settings that will break the new version, then restart? It’s pretty simple to write an sensible script to do this function. --- Conrad Rockenhaus conrad@xxxxxxxxxxxxxx https://www.rockenhaus.com/ (254) 292-3350
Attachment:
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays