- tor-relays - lists.torproject.org

How Best to Maximize Impact of $500/mo Budget?
by Tor at 1AEO 05 May '25

05 May '25

If you have a budget of $500/mo (EUR or USD, roughly) that could be used to strengthen Tor network, what would you use it for and why? Some ideas: Run new relays: Lease VPS or colocate hardware yourself Fund existing operators: Provide stipends or grants to help other operators Donate to the Tor Foundation: Support core development, research, and docs. Other ideas: e.g. donation platforms, bandwidth grants, research funding? Which approach (or mix) yields the best consensus-weight gain per dollar? Any tips on pitfalls, vetting, or recommended donation channels? I've been leaning towards running new relays since it seems to always benefit from more diverse growth but wondering what others think. Thanks for your insights!

2 1

Tor Relay Deployment Dilemma: Handle BGP yourself or have it done upstream to announce your own AS?
by Tor at 1AEO 02 May '25

02 May '25

I'm currently evaluating the best approach for having my AS announced with my owned (not rented) IPv4 addresses, and I've observed that hosting providers have different preferences for handling BGP sessions. For example, one provider requires that the BGP session be managed on the same server running the Tor relays, while another handles the announcement with my AS entirely on their side. This inconsistency makes it challenging to determine the most effective approach. I'm seeking guidance on the following points (or others you think are helpful): - When given the option: Should I manage the BGP session myself, or is it preferable to delegate it to the upstream provider whenever possible? - When required to manage BGP myself: - To conserve CPU/RAM resources for Tor, is it advisable to only use a default route (0.0.0.0/24) rather than a full routing table, relying on the upstream provider for full routing? - Under what circumstances should I implement multi-homed strategies myself versus allowing the upstream provider to manage them? - Are there best practices for route filtering or failover management? - What are your experiences regarding the compute and memory requirements for these configurations? - What are some preferred monitoring solutions? bgpmon.net doesn't seem free... Helpful read and suggestions at the end from this 6 year old article from nusenu, but couldn't find too much beyond this: https://nusenu.medium.com/how-vulnerable-is-the-tor-network-to-bgp-hijackin… I'm already using ROA and RPKI via ARIN for each /24 and limit max length to /24 to help as well. "The Tor exit fraction located in /24 prefixes is much higher than the guard capacity. So hijacks against exit capacity might be harder than attacks against guard capacity." - Seems also good to have /24 prefixes for guards, not just exits. Thanks!

2 2

relayor v25.0.0 is released
by nusenu 29 Apr '25

29 Apr '25

Hi, relayor v25.0.0 is released. relayor is an ansible role that helps you with running tor relays with minimal effort (automate everything). https://github.com/nusenu/ansible-relayor#main-benefits-for-a-tor-relay-ope… Most notable changes: * Support the MyFamily successor "happy families". This new relayor feature is currently opt-in as it also requires an alpha release of tor. When happy families reaches a tor stable release we will enable it by default and make the opt-in setting obsolete. I'm not so happy about the details but I also didn't want to introduce new dependencies so relayor is copying the family key file for **every** tor instance - see the background here [1]. Happy families is especially useful for large operators running many tor instances. The MyFamily configuration is not replaced by happy families, both designs are used when happy families is enabled. * prometheus integration improvement (backward incompatible change): remove variable tor_prometheus_config_file. relayor makes use of prometheus conf.d folder support instead of generating the entire configuration, relayor only drops the scrape config files into a configurable folder where prometheus is expected to read them. See prometheus' global config: scrape_config_files [1] https://gitlab.torproject.org/tpo/core/tor/-/issues/41046 Changelog: https://github.com/nusenu/ansible-relayor/releases/tag/v25.0.0 kind regards, nusenu -- https://nusenu.github.io

1 0

Self hosting bridge at home - de-anonymization risk?
by bjewrn2a＠anonaddy.com 28 Apr '25

28 Apr '25

is there any documentation on self-hosting a bridge at home and using it for your own connections? I am trying to understand why this isn't a recommended setup, would it lead to de-anonymization? Why/how much? your traffic blends with other users directly via the same connection other users use your bridge on a regular basis together with you and your hidden services ISP monitoring of your exact connection times are made harder (not sure how much exactly) I don't understand why hosting a bridge outside of your geographic location is necessary? is it a problem that the first hop is from your own IP address if the other two hops are external? were there any studies or similar questions asked before? I couldn't find anything I can't find help anywhere, so would appreciate any advice

6 16

Tor Relay Deployment Dilemma: Colocation vs Dedicated Servers for 10 Gbps
by Tor at 1AEO 05 Apr '25

05 Apr '25

Part 2 - Looking for feedback on our Tor relay configuration decision: Assuming both options cost the same and provide the same aggregate bandwidth—and by “better,” I mean improved advertised bandwidth, reliability, and diversity—is it preferable to deploy: Option 2A: Colocation, where we own the hardware, for 2 x 10 Gbps, or Option 2B: Dedicated servers, where we rent the hardware, for 4 x 10 Gbps? We lean toward Option 2B because it offers higher total bandwidth and may provide enhanced hardware redundancy and scalability. Additionally, does the ideal choice depend on the relay's role (e.g., exit vs. guard/middle nodes)? Also, is there a more comprehensive way to define “better” for this context? We appreciate any suggestions or refinements

2 1

Open source scripts for parsing CollecTor Tor server descriptor files?
by Tor at 1AEO 03 Apr '25

03 Apr '25

Couldn't find open source scripts to download and parse metrics from CollecTor server descriptor files so started creating some with help of ChatGPT. It'd be great if these already existed somewhere to build from and contribute back to! Created something very basic to parse and group relays by family fingerprint showing contact info, aggregated observed bandwidth, average observed bandwidth, unique IPv4 count, and unique AS count. Will keep dumping code here: https://github.com/1aeo/relayradar/ What would be helpful to see that you can't find elsewhere? Ex: I want to summarize total bandwidth observed by relay family per AS to see how different providers are performing Source files: https://metrics.torproject.org/collector/recent/relay-descriptors/server-de… Some initial insights, might be specifically incorrect but should have the right magnitude, from parsing March 27th, 28th and 29th server descriptor files: March 28th 6814 number of unique IPv4 addresses ~900 number of unique ASN Screenshot attached of example output in .html and attached .html file Used a 3rd party API, ipinfo.io, to lookup AS per unique IP and they shared some more metrics below via images, based on the 3 days of server descriptor unique IP to AS lookup calls. Top 5 countries and cities, highly concentrated in Europe Top 5 companies, mostly hosting companies and 1AEO, us, as #3 (guessing by quantity of IP addresses) 38 mobile carrier IPs running relays [image.png] [image.png] [image.png] [image.png] [image.png]

1 0

Running an obfs4 Bridge behind a UniFi UXG
by Malcolm MacDonald 01 Apr '25

01 Apr '25

Hello All! Not sure if anyone else is running a bridge behind a UniFi UXG but in my Flow log I am seeing blocked items with the Category of "DShield Block List" and Signature of "ET DROP Dshield Block Listed Source group 1" and the connection is being blocked. I'm thinking these alerts can be set to Allow Signature? Am I wrong on this one? Malcolm

2 1

Re: Guidance on optimal Tor relay server configurations - Best CPUs to Lower Colocation Costs for 10Gbps+ Tor Relays
by Tor at 1AEO 01 Apr '25

01 Apr '25

AMD EPYC 8534P and AMD EPYC 9535 are the best CPUs to minimize monthly colocation cost, based on two main factors of power (watts) and rack size, for Tor relay servers at 10 Gbps+ with 128 threads. Power seems to be largest contributor to colocation cost and CPU seems to be largest contributor to power. Open to thoughts / additional insights to lower colocation costs. The comments about EPYC were very helpful, especially as I've only had Intel until now. I've started moving to EPYC 8534P. After comparing options, AMD’s EPYC line currently offers the most power-efficient CPUs for 128+ threads—outperforming even the new Xeon 6E cores in threads-per-watt (and threads-per-watt weighted by clock speed) from 200 to 500 watts TDP. Selection criteria: - >=128 threads - lowest TDP wattage (also using "AMD configurable TDP (cTDP)" - maximizing PCIe version (5.0) - PCIe lanes (>= x96) - DDR5 RAM capacity (>=576GB) - DDR5 RAM speed (>= 4800 MT/s) For scenarios needing more than 128 threads, consider: - AMD EPYC 9634: 168 threads, 2.25 GHz base, min TDP 240W - AMD EPYC 9845: 320 threads, 2.1 GHz base, min TDP 320W For older generation systems (PICe 4.0 or DDR4), EPYC 7702 and EPYC 7763 were best options. Brief table: Name Series # of CPU Cores # of Threads Base Clock Max. Boost Clock All Core Boost Speed L3 Cache Default TDP Min TDP AMD Configurable TDP (cTDP) Socket Count PCI Express® Version System Memory Type Memory Channels System Memory Specification Per Socket Mem BW AMD EPYC™ 8534P EPYC 8004 Series 64 128 2.3 GHz Up to 3.1 GHz 3.1 GHz 128 MB 200W 155 155-225W 1P PCIe® 5.0 x96 DDR5 6 Up to 4800 MT/s 230.4 GB/s AMD EPYC™ 9634 EPYC 9004 Series 84 168 2.25 GHz Up to 3.7 GHz 3.1 GHz 384 MB 290W 240 240-300W 1P / 2P PCIe® 5.0 x128 DDR5 12 Up to 4800 MT/s 460.8 GB/s AMD EPYC™ 9535 EPYC 9005 Series 64 128 2.4 GHz Up to 4.3 GHz 3.5 GHz 256 MB 300W 240 240-300W 1P / 2P PCIe® 5.0 x128 DDR5 12 Up to 6400 MT/s 614 GB/s AMD EPYC™ 9845 EPYC 9005 Series 160 320 2.1 GHz Up to 3.7 GHz 3.25 GHz 320 MB 390W 320 320-400W 1P / 2P PCIe® 5.0 x128 DDR5 12 Up to 6400 MT/s 614 GB/s ~200 AMD CPU full list: https://www.amd.com/en/products/specifications/server-processor.html >> On Friday, February 21st, 2025 at 2:40 AM, mail--- via tor-relays <tor-relays(a)lists.torproject.org> wrote: >> >>> Hi, >>> >>>> Summary from your email - did I miss anything? >>> >>> Yes, with the general disclaimer (not to sound like a lawyer) that your mileage may vary. For example we run everything bare metal on FreeBSD and run a mix of guard/middle/exit relays. Running the same workload virtualized or on another operating system may impact the performance/overhead (either positively or negatively). Also your RAM budget of 4 GB per relay may be a bit on the safe side, I don't think it would hurt to lower this. >>> >>>> What are the primary factors that justify running up to two Tor relays per physical core (leveraging SMT) versus a one-to-one mapping? >>> >>> Tor relays sadly don't scale well. They fluctuate on a daily basis (the Tor network as a whole does) and even their general utilization is kind of unpredictable. So I think there are two approaches to this: >>> >>> 1) Run 1 relay per physical core, accepting that your CPU will idle a large amount of the time (50%+ in our case). >>> >>> 2) Run multiple Tor relays per physical core until you saturate 90-95% of your CPU cycles, accepting additional system overhead/congestion. >>> >>> There is no right or wrong here. In our case we went with running multiple relays per core because we want to utilize the (very expensive) hardware we run on as much as possible. Every CPU cycle not spent on privacy enhancing services is a wasted CPU cycle from our point of view ;). >>> >>>> Is one-to-one mapping of Tor relay to core/thread the most compute- and system-efficient approach? >>> >>> Yes, this should lower the amount of congestion (interrupts and stuff). In this sense it can also be beneficial to lock your NIC/irq threads to specific cores. >>> >>>> Are the clock speeds you listed base or turbo numbers (3.4, 2.25 and 2.0 Ghz)? >>> >>> Base indeed. No CPU is able to consistently maintain their turbo speed on this many cores. When all cores are utilized, the base speed pretty much is the max speed in practice. >>> >>>> From your real world scenario #2 and advice for the "fastest/best hardware", would this type of server work well for a $20k budget? >>> >>> Looks like a capable server. That CPU looks powerful enough but keep in mind that it has a rather low clockspeed, so you will be running many medium speed relays. Nothing wrong with that since CPUs with this many cores simply don't/can't have high base clocks. Also I think 512 GB of RAM would be enough unless you run a *lot* of relays on it (which may be a viable strategy to utilize your CPU fully). >>> >>> Just a note: in my experience the Epyc platform (especially when self-build) provides a bit more bang for your buck. For example a AMD Epyc 9969 with 192 cores/384 threads(a)2.25 Ghz baseclock will probably outperform the Intel 6980P considerably (for Tor workloads at least), while being much cheaper (listing price at least). But of course this greatly depends on where you buy the server or parts so your mileage may vary. When I look around here locally a complete self-build system with the 192 core Epyc, 512 GB RAM and a 100 Gb/s NIC would cost ~12k excluding VAT before any tax benefits. But your proposed server will work perfectly fine as well so if you prefer a brand, go for it :). >>> >>>> Assuming one relay per core/thread, would this setup be capable of saturating 40 Gbps, given that 10 Gbps typically saturated with ~31.5 physical cores + ~31.5 SMT threads at 2 Ghz and thus 256 relays vs ~63 relays translates roughly to 4×10 Gbps = 40 Gbps? >>> >>> Assuming you get the Tor relays to saturate their cores, yes. That CPU should be able to push 40 Gb/s of Tor traffic. Our ~2019 64 core/128 thread Epyc pushes 10 Gb/s of Tor traffic on a bit less than half it's capacity. And your CPU is newer (better IPC hopefully if Intel finally stepped up their game since 2019), has much more cache and runs on DDR5 while having a bit lower base clock. So it should perform at least similar but probably better than ours. >>> >>> Do you have the network capacity covered already? If you plan to do 40 Gb/s, then you also need enough peers/upstream capacity. The required networking equipment and connections themselves for this can also be costly. >>> >>> Cheers, >>> >>> tornth >>> >>> Feb 20, 2025, 08:42 by tor(a)1aeo.com: >>> >>>> Excellent information, especially the real world scenarios! Exactly what I was looking for! >>>> >>>> Summary from your email - did I miss anything? >>>> >>>> To saturate 10 Gbps connection: >>>> 1) IPv4 Allocation: Use between 5 and 20. Much lower than 256 in a /24! >>>> 2) Tor Relay Count: Run roughly ~40 to ~150, depending on CPU clock speed, i.e. faster clock, fewer relays needed. >>>> 3) CPU Utilization: 1 Tor relay per physical core preferred but okay to scale to 1 Tor relay per threads/SMT as well, up to 2x Tor relays per core/thread >>>> 4) RAM requirements: Maintain a 4:1 RAM-to-core/relay ratio (4GB per core/relay), including extra 32GB per server to cover DoS, OS, networking, etc. overheads >>>> >>>> In general, some ideals but not required: >>>> CPU clock speed: Higher CPU clock speed, better relay performance >>>> RAM: Fewer relays, lower RAM requirements >>>> RAM: Add ~32GB to overall RAM capacity sizing for OS, DNS, networking, DoS, etc. >>>> IPv4: One IPv4 per relay with common traffic ports >>>> >>>> Scaling: Start with 1 Tor relay per physical core, then add 1 Tor relay per thread/SMT and stop at 2 Tor relays per each core / thread. >>>> >>>> What are the primary factors that justify running up to two Tor relays per physical core (leveraging SMT) versus a one-to-one mapping? >>>> Ex: 37-74 for ~18.5 physical + SMT and 63-126 for ~31.5 physical + SMT. >>>> >>>> Is one-to-one mapping of Tor relay to core/thread the most compute- and system-efficient approach? >>>> >>>> Are the clock speeds you listed base or turbo numbers (3.4, 2.25 and 2.0 Ghz)? I'm assuming base. Not sure if anybody has data on how these impact Tor relays? >>>> >>>> From your real world scenario #2 and advice for the "fastest/best hardware", would this type of server work well for a $20k budget? >>>> A single-socket Xeon 6980P (128 physical cores, 256 threads, base clock 2.0 GHz, turbo up to 3.9 GHz) with 1024GB DDR5 (maintaining a 4:1 ratio) and an AIOM Mellanox NIC be optimal? Assuming one relay per core/thread, would this setup be capable of saturating 40 Gbps, given that 10 Gbps typically saturated with ~31.5 physical cores + ~31.5 SMT threads at 2 Ghz and thus 256 relays vs ~63 relays translates roughly to 4×10 Gbps = 40 Gbps? >>>> >>>> For those curious, according to ChatGPT o3-mini-high deep research: >>>> 1) 20% cap on bandwidth contributions for exit relays is roughly 50+ Gbit/s for the largest operators. >>>> 2) 10% of Tor's consensus weight in terms of bandwidth for 2025 is roughly 90-95 Gbps of sustained bandwidth. In 2022, it would have been ~68 Gbps. >>>> I don't plan to have this issue any time soon, but good to be aware! >>>> >>>> Screenshots of the lengthy responses below and attached. >>>> >>>> [image.png] >>>> >>>> [image.png] >>>> [image.png] >>>> [image.png] >>>> >>>> Sent with[Proton Mail](https://proton.me/mail/home)secure email. >>>> >>>> On Tuesday, February 18th, 2025 at 2:23 PM, mail(a)nothingtohide.nl <mail(a)nothingtohide.nl> wrote: >>>> >>>>> Hi, >>>>> >>>>> Many people already replied, but here are my (late) two cents. >>>>> >>>>>> 1) If a full IPv4 /24 Class C was available to host Tor relays, what are some optimal ways to allocate bandwidth, CPU cores and RAM to maximize utilization of the IPv4 /24 for Tor? >>>>> >>>>> "Optimal" depends on your preferences and goals. Some examples: >>>>> >>>>> - IP address efficiency: run 8 relays per IPv4 address. >>>>> - Use the best ports: 256 relays (443) or 512 relays (443+80). >>>>> - Lowest kernel/system congestion: 1 locked relay per core/SMT thread combination, ideally on high clocked CPUs. >>>>> - Easiest to manage: as few relays as possible. >>>>> - Memory efficiency: only run middle relays on very high clocked CPUs (4-5 Ghz). >>>>> - Cost efficiency: run many relays on 1-2 generations old Epyc CPUs with a high core count (64 or more). >>>>> >>>>> There are always constraints. The hardware/CPU/memory and bandwidth/routing capability available to you are probably not infinite. Also the Tor Project maximizes bandwidth contributions to 20% and 10% for exit relay and overall consensus weight respectively. >>>>> >>>>> With 256 IP addresses on modern hardware, it will be very hard to not run in to one of these limitations long before you can make it 'optimal'. Hardware wise, one modern/current gen high performance server only running exit relays will easily push enough Tor traffic to do more than half of the total exit bandwidth of the Tor network. >>>>> >>>>> My advice would be: >>>>> 1) Get the fastest/best hardware with current-ish generation CPU IPC capabilities you can get within your budget. To lower complexity with keeping congestion in control, one socket is easier to deal with than a dual socket system. >>>>> >>>>> (tip for NIC: if your switch/router has 10 Gb/s or 25 Gb/s ports, get some of the older Mellanox cards. They are very stable (more so than their Intel counterparts in my experience) and extremely affordable nowadays because of all the organizations that throw away their digital sovereignty and privacy of their employees/users to move to the cloud). >>>>> >>>>> 3) Start with 1 Tor relay per physical core (ignoring SMT). When the Tor relays have ramped up (this takes 2-3 months for guard relays) and there still is considerable headroom on the CPU (Tor runs extremely poorly at scale sadly, so this would be my expectation) then move to 1 Tor relay per thread (SMT included). >>>>> >>>>> (tip: already run/'train' some Tor relays with a very limited bandwidth (2 MB/s or something) parallel to your primary ones and pin them all to 1-2 cores to let them ramp up in parallel to your primary ones. This makes it *much* less cumbersome to scale up your Tor contribution when you need/want/can do that in the future). >>>>> >>>>> 4) Assume at least 1 GB of RAM per relay on modern CPUs + 32 GB additionally for OS, DNS, networking and to have some headroom for DoS attacks. This may sound high, especially considering the advice in the Tor documentation. But on modern CPUs (especially with a high clockspeed) guard relays can use a lot more than 512 MB of RAM, especially when they are getting attacked. Middle and exit relays require less RAM. >>>>> >>>>> Don't skimp out on system memory capacity. DDR4 RDIMMs with decent clockspeeds are so cheap nowadays. For reference: we ran our smaller Tor servers (16C(a)3.4Ghz) with 64 GB of RAM and had to upgrade it to 128 GB because during attacks RAM usage exceeded the amount available and killed processes. >>>>> >>>>> 5) If you have the IP space available, use one IPv4 address per relay and use all the good ports such as 443. If IP addresses are more scarce, it's also not bad to run 4 or 8 relays per IP address. Especially for middle and exit relays the port doesn't matter (much). Guard relays should ideally always run on a generally used (and generally unblocked) port. >>>>> >>>>>> 2) If a full 10 Gbps connection was available for Tor relays, how many CPU cores, RAM and IPv4 addresses would be required to saturate the 10 Gbps connection? >>>>> >>>>> That greatly depends on the CPU and your configuration. I can offer 3 references based on real world examples. They all run a mix of guard/middle/exit relays. >>>>> >>>>> 1) Typical low core count (16+SMT) with higher clockspeed (3.4 Ghz) saturates a 10 Gb/s connection with ~18.5 physical cores + SMT. >>>>> 2) Typical higher core count (64+SMT) with lower clockspeed (2.25 Ghz) saturates a 10 Gb/s connection with ~31.5 physical cores + SMT. >>>>> 3) Typical energy efficient/low performance CPU with low core count (16) with very low clockspeed (2.0 Ghz) used often in networking appliances saturates a 10 Gb/s connection with ~75 physical cores (note: no SMT). >>>>> >>>>> The amount of IP addresses required also depends on multiple factors. But I'd say that you would need between the amount and double the amount of relays of the mentioned core+SMT count in order to saturate 10 Gb/s. This would be 37-74, 63-126 and 75-150 relays respectively. So between 5 and 19 IPv4 addresses would be required at minimum, depending on CPU performance level. >>>>> >>>>> RAM wise the more relays you run, the more RAM overhead you will have. So in general it's better to run less relays at a higher speed each than run many at a low clock speed. But since Tor scales so badly you need more Relays anyway so optimizing this isn't easy in practice. >>>>> >>>>>> 3) Same for a 20 Gbps connection, how many CPU cores, RAM and IPv4 addresses are required to saturate? >>>>> >>>>> Double the amount compared to 10 Gb/s. >>>>> >>>>> Good luck with your Tor adventure. And let us know your findings with achieving 10 Gb/s when you get there :-). >>>>> >>>>> Cheers, >>>>> >>>>> tornth >>>>> >>>>> Feb 3, 2025, 18:14 by tor-relays(a)lists.torproject.org: >>>>> >>>>>> Hi All, >>>>>> >>>>>> Looking for guidance around running high performance Tor relays on Ubuntu. >>>>>> >>>>>> Few questions: >>>>>> 1) If a full IPv4 /24 Class C was available to host Tor relays, what are some optimal ways to allocate bandwidth, CPU cores and RAM to maximize utilization of the IPv4 /24 for Tor? >>>>>> >>>>>> 2) If a full 10 Gbps connection was available for Tor relays, how many CPU cores, RAM and IPv4 addresses would be required to saturate the 10 Gbps connection? >>>>>> >>>>>> 3) Same for a 20 Gbps connection, how many CPU cores, RAM and IPv4 addresses are required to saturate? >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Sent with[Proton Mail](https://proton.me/mail/home)secure email.

1 0

Tor Relay Deployment Dilemma: Single 40Gbps Server or Four 10Gbps Machines?
by Tor at 1AEO 01 Apr '25

01 Apr '25

Looking for feedback on my Tor relay configuration decision: Assuming both options cost the same and provide the same aggregate bandwidth—and by “better,” I mean improved advertised bandwidth, reliability, and diversity—is it preferable to deploy: Option A: One hardware server on a 40Gbps link, or Option B: Four hardware servers, each on a 10Gbps link, located in different geographic areas and/or with different upstream providers? I lean toward Option B because it offers advantages in advertised bandwidth, reliability, and diversity. Additionally, does the ideal choice depend on whether the relays serve as exit nodes or as guard/middle nodes? Also, is there a more comprehensive way to define “better” for this context? I appreciate any suggestions or refinements!

2 2

Happy Families - Relay Operator Friendlyness
by nusenu 30 Mar '25

30 Mar '25

Hi Marco, moving the discussion from: https://gitlab.torproject.org/tpo/core/tor/-/issues/41033#note_3181625 to tor-relays as the features in the issue have already been implemented by Nick and the discussion has evolved into a more general direction. > I think many people have > HiddenService instances in addition to their relay instances. > HiddenService instances must then be configured not to use default > FamilyId * if tor automatically detect and use those. > Ultimately, > @nickm has to decide how much work he wants to put into c-tor. > (Especially auto detecting KeyDir on all OS requires a lot of time > to test.) Happy families is not relevant for onion services. I sense a misunderstanding of "FamilyId *". It only looks for family keys in the "keys" subfolder of a specific tor instance's DataDirectory or within the directory given in "FamilyKeyDirectory". See also the man page section: "KeyDirectory" because "keys" is just the default but can be configured. It does not search across the all "keys" subfolders of multiple tor instances on the same server, which would fail anyway with proper filesystem permissions, because one tor instance should not be able to read another tor instance's data directory if setup correctly. kind regards, nusenu -- https://nusenu.github.io

1 0