> On 5 Dec 2017, at 22:50, x9p <tor@xxxxxxx> wrote: > > > my second and third positions are similar: > > ... Please don't publicly share exact connection numbers and netblocks. They can be used in combination with other information to de-anonymise users. (For example, if an adversary knows that a guard has 5 connections from a netblock that they can't otherwise observe, they can go and hunt down those users.) > On 6 Dec 2017, at 07:42, null <null@xxxxxxxxxxxx> wrote: > > ... > @ Scott Bennett: > >> What you are seeing is most likely the same phenomenon brought up on >> this list repeatedly over at least the last decade or so. That phenomenon >> is providing HSDir service, or perhaps a rendez-vous point, for a popular >> hidden service. > >> If you don't like it, you can set >> >> HidServDirectoryV2 0 > > Thanks for your reply. The data suggests this was not the case (this > time). Some of these relays have been up almost a year with the same > configuration, often with the HSDir flag. The recent issues just > started occurring, and happened across several relays during the same > timeframe. > > Nonetheless, we're not opposed to disabling HidServDirectoryV2 to rule > it out. However it appears that option is deprecated (on 0.3.1.9). > Enabling it causes this in the log: > > [WARN] Skipping obsolete configuration option 'HidServDirectoryV2' > > It's also no longer listed in the Tor manual > (https://www.torproject.org/docs/tor-manual.html.en). It looks like we > might be able to achieve the same effect with something like this > instead: > > MinUptimeHidServDirectoryV2 52 weeks > > Anyone have any info on why HidServDirectoryV2 is consider obsolete? > Is using MinUptimeHidServDirectoryV2 instead going to achieve the same > effect? No, this option only applies to directory authorities, and determines their votes for the HSDir flag. From the tor man page: MinUptimeHidServDirectoryV2 N seconds|minutes|hours|days|weeks Minimum uptime of a v2 hidden service directory to be accepted as such by authoritative directories. (Default: 25 hours) >>> We have file descriptors (/proc/sys/fs/file-max) set to 64000, but it looks >>> like Tor sets MAX_FILEDESCRIPTORS to 16384 per /etc/init.d/tor: >>> >>> elif [ "$system_max" -gt "40000" ] ; then >>> MAX_FILEDESCRIPTORS=16384 >>> >>> Surely that is high enough for normal service? >> >> If by normal you mean "low traffic", then yes, it's probably enough. >> However, that's really not very high in a general sense. > > > Why does the default /etc/init.d/tor (from the Debian/Ubuntu pkg) cap > MAX_FILEDESCRIPTORS at 16384 then? We have it set to 64000 otherwise. > Obviously we could comment out these lines, but it seems odd the > default config tries to cap it at 16384 if that's too low for a high > traffic relay. Perhaps it's the maximum allowed on some kernels or low-memory systems? Or perhaps it's historical? I suggest that you submit a ticket or patch to the debian bug tracker. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
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