> 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