Re: [tor-relays] Tor not starting but log inconclusive
On Tue, Dec 14, 2021 at 09:26:21PM +0100, yl wrote: > The standard Debian tor@default.service has "After=network.target > nss-lookup.target" in it, so one would think network should be fully > functional when the services starts, but it was not in my case. > At the time when tor started the eno0 did not yet have a IPv6, so it > complained that it could not bind to some port in the config, because the IP > supplied with the port was not ready yet. Great find. If it's easy for you to do, can you install a Tor 0.4.5 deb and see if it has the same behavior? If yes, then this is a problem with your particular situation, or a problem with IPv6 that has been there all along. But if the 0.4.5 deb works and the 0.4.6 deb doesn't, then it is a regression, perhaps related to the ipv6 changes we did in 0.4.6, and we should try to track it down. Thanks, --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor not starting but log inconclusive
Hello, as there were some follow up emails let me explain the problem. The standard Debian tor@default.service has "After=network.target nss-lookup.target" in it, so one would think network should be fully functional when the services starts, but it was not in my case. At the time when tor started the eno0 did not yet have a IPv6, so it complained that it could not bind to some port in the config, because the IP supplied with the port was not ready yet. The after that 5 retries to start tor it gets stuck, systemd status tells it is running, but nyx can says it is not running. After the 5 restarts I saw that ifup had some issue too, which was caused by some config in /etc/network/interfaces, which was working ok and the IPv6 was also reachable, but still the ifup@eno0.service was not working well. I have no idea about how and where to find that service. However, I changed the "network" parameter in the interfaces config to be supplied with the IPv6, so like 2001:0DB8:0001::0002/64 instead of "network 64" in a separate line. This satisfied ifup it seems, but still it was too slow to be up and running before Tor was started. Then I searched again and found a quick and dirty (aka lazy) solution for that, in "tor@default.service" I added this line: ExecStartPre=/bin/sh -c 'until ping -c1 google.com; do sleep 1; done;' in the "[Service]" section. I also tried to add "network-online.target" and some "ifup@eno0.service" in the "After=" line above, but I guess it must be somehow different, maybe has to be some target instead. So with this line a ping of google.com has to work at least once for the service to be started. In combination with the standard "TimeoutStartSec=300" that should work well. I am sure there is nicer solutions, but why bother. yours yl ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [Looking for feedback] An easier way to declare families
On Tue, Dec 14, 2021 at 12:55 PM Toralf Förster wrote: > On 12/14/21 17:06, Nick Mathewson wrote: > > > > A relay operator has asked me, offline, if it is possible under this > > proposal for a relay to belong to more than one family. (For example, > > if there were two relay operators who each operated some relays on their > > own, but also operated some relays jointly, it might make sense to put > > the jointly operated relays into _both_ of the operators' families .) > > Why not just consider the shared set as an own family? > The theory is that, if either operator's infrastructure were compromised or hostile, they would be a danger both to their own relays and to the shared relays. Thus, you wouldn't want to use a shared relay in the same circuit with _either_ operator's non-shared relays, but it would be okay to use either one of operator's relays in the same circuit with one of the other operator's relays. And that maps to a situation where each operator has their own relay family, and the shared relays would belong to both families. cheers, -- Nick ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [Looking for feedback] An easier way to declare families
On Tue, Dec 14, 2021 at 1:07 PM nusenu wrote: > Nick Mathewson: > > 1) The proposal currently limits each relay to no more than 3 families. > > Is that a reasonable upper bound? > > Yes, 3 is a reasonable limit. > > > 2) We hadn't been planning to implement multi-family support right > away, > > though I could if needed. Is that something that many operators would > want? > > I believe it is a rarely used feature, but > we could do some analysis to see how many use it currently. > > > Will the new family design with its bridge support be part of tor 0.4.7.x ? > I don't think so; we haven't started implementing it yet, and we're trying not to put any more stuff into 0.4.7.x except for what we need for improved congestion-control support. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [Looking for feedback] An easier way to declare families
Nick Mathewson: 1) The proposal currently limits each relay to no more than 3 families. Is that a reasonable upper bound? Yes, 3 is a reasonable limit. 2) We hadn't been planning to implement multi-family support right away, though I could if needed. Is that something that many operators would want? I believe it is a rarely used feature, but we could do some analysis to see how many use it currently. Will the new family design with its bridge support be part of tor 0.4.7.x ? -- https://nusenu.github.io ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [Looking for feedback] An easier way to declare families
On 12/14/21 17:06, Nick Mathewson wrote: A relay operator has asked me, offline, if it is possible under this proposal for a relay to belong to more than one family. (For example, if there were two relay operators who each operated some relays on their own, but also operated some relays jointly, it might make sense to put the jointly operated relays into _both_ of the operators' families .) Why not just consider the shared set as an own family? -- Toralf OpenPGP_signature Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor not starting but log inconclusive
Hello friends, I see this problem for a long time, but only with some VPS providers from Eastern Europe, with others Tor starts without problems. As there is a discussion here if maybe some system components are not ready in time, it could also depend on the virtualizer used. Additionally, a slight improvement showed up when I upgraded from Debian 10 to Debian 11 Testing. That's just for information. It does not seem to be a problem of a single user. Olaf (some exit nodes) Am 14.12.21 um 15:52 schrieb Gary C. New via tor-relays: Are you able to start Tor manually without systemd? Anytime I encounter Tor start issues, I attempt to manually start Tor without the --quiet option to verify whether it's a torrc issue or something else. You might consider increasing the Tor logging level, too. Your existing Tor log shows a DNS timeout error. As I do not operate an exit relay, I don't know whether the DNS timeout error would cause Tor not to start. Respectfully, Gary— This Message Originated by the Sun. iBigBlue 63W Solar Array (~12 Hour Charge) + 2 x Charmast 26800mAh Power Banks = iPhone XS Max 512GB (~2 Weeks Charged) On Tuesday, December 14, 2021, 6:06:12 AM PST, yl wrote: Hello Roger, thanks for your helpful tip. On 12/14/21 12:14 PM, Roger Dingledine wrote: My first thought is that somehow during boot Tor fails to start. For example, if at that point in the boot process there is no network, maybe Tor aborts even before it gets to the point of writing anything in its logs. We've definitely had bugs like that over the years. this was the one really helpful tip. Any idea how to troubleshoot this and what to look for? Tor will write to stdout before it switches over to writing to the logs. So whatever init process is starting Tor can see that output. How exactly to get at it... sounds like an adventure diving into how systemd works.:) And then the tip that it writes to stdout and might be some other output besides from unit "tor". I see the problem now, and I think it is like you guessed the network is not ready at that time. Thanks, will check further. yl ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor not starting but log inconclusive
I ran a exit relay before and no DNS timeouts don't cause Tor to not start properly and DNS timeouts seem to happen randomly even if the DNS server is working properlyOn Dec 14, 2021 6:52 AM, "Gary C. New via tor-relays" wrote:Are you able to start Tor manually without systemd? Anytime I encounter Tor start issues, I attempt to manually start Tor without the --quiet option to verify whether it's a torrc issue or something else. You might consider increasing the Tor logging level, too. Your existing Tor log shows a DNS timeout error. As I do not operate an exit relay, I don't know whether the DNS timeout error would cause Tor not to start.Respectfully,Gary—This Message Originated by the Sun.iBigBlue 63W Solar Array (~12 Hour Charge)+ 2 x Charmast 26800mAh Power Banks= iPhone XS Max 512GB (~2 Weeks Charged) On Tuesday, December 14, 2021, 6:06:12 AM PST, yl wrote: Hello Roger,thanks for your helpful tip.On 12/14/21 12:14 PM, Roger Dingledine wrote:> My first thought is that somehow during boot Tor fails to start. For> example, if at that point in the boot process there is no network,> maybe Tor aborts even before it gets to the point of writing anything> in its logs. We've definitely had bugs like that over the years.this was the one really helpful tip.> >> Any idea how to troubleshoot this and what to look for?> Tor will write to stdout before it switches over to writing to the> logs. So whatever init process is starting Tor can see that output. How> exactly to get at it... sounds like an adventure diving into how systemd> works.:)And then the tip that it writes to stdout and might be some other output besides from unit "tor".I see the problem now, and I think it is like you guessed the network is not ready at that time.Thanks, will check further.yl___tor-relays mailing listtor-relays@lists.torproject.orghttps://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Introduction from lokodlare
Hi Roger, I've found the secret to effectively loadbalancing Tor Relay Nodes is as follows: 1. Use the same version of Tor on all Upstream Servers 2. Start/Stop all Upstream Tor Nodes at the same time to keep in sync 3. Loadbalance using IP Transparency Mode (This was discovered while tirelessly combing through mountains of Tor debug logs) and use Sticky Sessions based on Source IP Addresses 4. Configure Upstream Tor Nodes to deliver return packets to the Loadbalancer 5. Configure all Upstream Tor Nodes to use the same DirAuthority and FallbackDir (This is how centralization of statistics is addressed) This configuration has been working well for the past six months. The only dow downsides that I've seen are if an Upstream Tor Node goes down, I have to leave it down or restart all the Upstream Tor Nodes to keep in sync. Occasionally, if a medium-term key is updated, I can see circuits migrate to a single Upstream Tor Node; however, that can be easily discerned and addressed by reviewing centralized syslogs and copying the updated .tordb directory to the other Upstream Tor Nodes with a synced restart. In terms of metrics, the written/read bytes per second is only reported for a single Upstream Tor Node, but that's not a big deal. It would be helpful if metrics were pulled remotely instead pushed. Please provide your email address and I'll be happy to message you directly with the name of my Tor Meta Relay. Respectfully, Gary— This Message Originated by the Sun. iBigBlue 63W Solar Array (~12 Hour Charge) + 2 x Charmast 26800mAh Power Banks = iPhone XS Max 512GB (~2 Weeks Charged) On Tuesday, December 14, 2021, 3:39:44 AM PST, Roger Dingledine wrote: On Sun, Dec 12, 2021 at 03:42:12PM +, Gary C. New via tor-relays wrote: > I have a Single Tor Relay comprised of a number of Tor Nodes. I'm always > interested in knowledge sharing related to Tor Loadbalancing. > What are your thoughts on the Pros & Cons of dedicating resources to a > Single, Loadbalanced Tor Relay vs Many, Unloadbalanced Tor Relays by a Tor > Operator? Perhaps, a Hybrid approach? Hi Gary, One of the big downsides to trying to create one "meta" relay out of many independent relays is that each independent relay will make and maintain its own TLS connections with other relays. So while running a fast Tor relay the normal way might end up with roughly one connection to each other relay in the network (which could already be many thousands of connections), doing it the way you describe could result in many times that number of open connections. And even if your local router and systems can handle that many open connections, you're increasing the load on every other relay by forcing them to handle more connections. There will also be more bandwidth use, since each separate TLS connection will use its own keepalive packets to try to stay connected in the face of firewall and NAT timeouts, and also to try to foil rudimentary netflow-based traffic analysis attacks. And because circuits are spread out over many TLS connections, they won't get the privacy protections from being all bundled on a single TLS connection, i.e. a network observer will have an easier time distinguishing which circuit a given cell is for. Which relays are you running in this way? How do you aggregate all of the statistics/etc into a central Tor that publishes a unified relay descriptor? I would expect your meta-relay to have some kind of bizarre breakage, so we should check it out and see if that's true in practice. Thanks, --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [Looking for feedback] An easier way to declare families
On Sat, Nov 6, 2021 at 10:36 AM Nick Mathewson wrote: > Hello, relay operators! > > I'm hoping to get some feedback from relay operators, particularly > those who use the MyFamily option, about the best way to deploy > proposal 321. You can read the proposal at: > > > https://gitlab.torproject.org/tpo/core/torspec/-/blob/master/proposals/321-happy-families.md > > The main idea of this proposal is to provide an easier way for > relays to declare that they are in the same family. With proposal > 321, each relay in the same family uses a cryptographic certificate > to prove that it is in the same family as the others. > > (That's just a summary; see the full proposal at the link above for > a write up of how it works, an a description of backwards > compatibility issues.) > > Now, my question is, how can we make this approach as usable as possible? > There are several different ways that we could have it work in practice: > A relay operator has asked me, offline, if it is possible under this proposal for a relay to belong to more than one family. (For example, if there were two relay operators who each operated some relays on their own, but also operated some relays jointly, it might make sense to put the jointly operated relays into _both_ of the operators' families .) This is something that the proposal currently supports, but there are a couple of limitations I was wondering about: 1) The proposal currently limits each relay to no more than 3 families. Is that a reasonable upper bound? 2) We hadn't been planning to implement multi-family support right away, though I could if needed. Is that something that many operators would want? best wishes, -- Nick ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor not starting but log inconclusive
Are you able to start Tor manually without systemd? Anytime I encounter Tor start issues, I attempt to manually start Tor without the --quiet option to verify whether it's a torrc issue or something else. You might consider increasing the Tor logging level, too. Your existing Tor log shows a DNS timeout error. As I do not operate an exit relay, I don't know whether the DNS timeout error would cause Tor not to start. Respectfully, Gary— This Message Originated by the Sun. iBigBlue 63W Solar Array (~12 Hour Charge) + 2 x Charmast 26800mAh Power Banks = iPhone XS Max 512GB (~2 Weeks Charged) On Tuesday, December 14, 2021, 6:06:12 AM PST, yl wrote: Hello Roger, thanks for your helpful tip. On 12/14/21 12:14 PM, Roger Dingledine wrote: > My first thought is that somehow during boot Tor fails to start. For > example, if at that point in the boot process there is no network, > maybe Tor aborts even before it gets to the point of writing anything > in its logs. We've definitely had bugs like that over the years. this was the one really helpful tip. > >> Any idea how to troubleshoot this and what to look for? > Tor will write to stdout before it switches over to writing to the > logs. So whatever init process is starting Tor can see that output. How > exactly to get at it... sounds like an adventure diving into how systemd > works.:) And then the tip that it writes to stdout and might be some other output besides from unit "tor". I see the problem now, and I think it is like you guessed the network is not ready at that time. Thanks, will check further. yl ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor not starting but log inconclusive
Hello Roger, thanks for your helpful tip. On 12/14/21 12:14 PM, Roger Dingledine wrote: My first thought is that somehow during boot Tor fails to start. For example, if at that point in the boot process there is no network, maybe Tor aborts even before it gets to the point of writing anything in its logs. We've definitely had bugs like that over the years. this was the one really helpful tip. Any idea how to troubleshoot this and what to look for? Tor will write to stdout before it switches over to writing to the logs. So whatever init process is starting Tor can see that output. How exactly to get at it... sounds like an adventure diving into how systemd works.:) And then the tip that it writes to stdout and might be some other output besides from unit "tor". I see the problem now, and I think it is like you guessed the network is not ready at that time. Thanks, will check further. yl ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Introduction from lokodlare
On Sun, Dec 12, 2021 at 03:42:12PM +, Gary C. New via tor-relays wrote: > I have a Single Tor Relay comprised of a number of Tor Nodes. I'm always > interested in knowledge sharing related to Tor Loadbalancing. > What are your thoughts on the Pros & Cons of dedicating resources to a > Single, Loadbalanced Tor Relay vs Many, Unloadbalanced Tor Relays by a Tor > Operator? Perhaps, a Hybrid approach? Hi Gary, One of the big downsides to trying to create one "meta" relay out of many independent relays is that each independent relay will make and maintain its own TLS connections with other relays. So while running a fast Tor relay the normal way might end up with roughly one connection to each other relay in the network (which could already be many thousands of connections), doing it the way you describe could result in many times that number of open connections. And even if your local router and systems can handle that many open connections, you're increasing the load on every other relay by forcing them to handle more connections. There will also be more bandwidth use, since each separate TLS connection will use its own keepalive packets to try to stay connected in the face of firewall and NAT timeouts, and also to try to foil rudimentary netflow-based traffic analysis attacks. And because circuits are spread out over many TLS connections, they won't get the privacy protections from being all bundled on a single TLS connection, i.e. a network observer will have an easier time distinguishing which circuit a given cell is for. Which relays are you running in this way? How do you aggregate all of the statistics/etc into a central Tor that publishes a unified relay descriptor? I would expect your meta-relay to have some kind of bizarre breakage, so we should check it out and see if that's true in practice. Thanks, --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] bridge distribution mechanism
On Sun, Dec 12, 2021 at 10:52:42AM +0100, trinity pointard wrote: > There are multiple bridges distributions mechanism. One is chosen at random > when your bridge first come to life, each being perfectly fine : > - moat: distributed automatically to Tor Browser users > - https: distributed on bridge-db website after solving a captcha > https://bridges.torproject.org/ > - email: distributed when sending an email to brid...@torproject.org) > - reserved: distributed manually, mostly in-person I imagine > > The only distribution mechanism you might want to worry about is "none", it > either mean your bridge is really young and bridge-db is not distributing > it yet (it should only be in that state for about a few hours), or you > decided to distribute this bridge yourself (no bridge-db involved, by > setting `BridgeDistribution none` in your torrc), or your bridge is down. Right, exactly. Two more documentation resources that could be helpful: * The relay-search page makes each "Bridge distribution mechanism" into a link to its entry on https://bridges.torproject.org/info * You can read about the original design idea here: https://svn-archive.torproject.org/svn/projects/design-paper/blocking.html#tth_sEc7.4 And for those who enjoy reading even more, check out these blog posts which detail the open research areas: * https://blog.torproject.org/strategies-getting-more-bridge-addresses * https://blog.torproject.org/research-problems-ten-ways-discover-tor-bridges * https://blog.torproject.org/research-problem-five-ways-test-bridge-reachability --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor not starting but log inconclusive
On Tue, Dec 14, 2021 at 11:39:50AM +0100, yl wrote: > Hello all, > I have a problem with a Tor Exit. > > Tor will not start correctly, but there is nothing in the logs. Here is the > info I got. Is this the debian package? What OS? > You can see the start was at 04:28:59 but it only started when I did > "systemctl restart tor" at 10:12:01.103. My first thought is that somehow during boot Tor fails to start. For example, if at that point in the boot process there is no network, maybe Tor aborts even before it gets to the point of writing anything in its logs. We've definitely had bugs like that over the years. > Any idea how to troubleshoot this and what to look for? Tor will write to stdout before it switches over to writing to the logs. So whatever init process is starting Tor can see that output. How exactly to get at it... sounds like an adventure diving into how systemd works. :) --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Tor not starting but log inconclusive
Hello all, I have a problem with a Tor Exit. Tor will not start correctly, but there is nothing in the logs. Here is the info I got. tor --version Tor version 0.4.6.8. Tor is running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma 5.2.4, Libzstd 1.3.8 and Glibc 2.28 as libc. Tor compiled with GCC version 8.3.0 journalctl -u tor --since="14 hours ago" -- Logs begin at Tue 2021-12-14 04:28:56 CET, end at Tue 2021-12-14 10:19:59 CET. -- Dec 14 04:28:59 tor.piratenpartei-nrw.de systemd[1]: Starting Anonymizing overlay network for TCP (multi-instance-master)... Dec 14 04:28:59 tor.piratenpartei-nrw.de systemd[1]: Started Anonymizing overlay network for TCP (multi-instance-master). Dec 14 10:12:00 tor.piratenpartei-nrw.de systemd[1]: tor.service: Succeeded. Dec 14 10:12:00 tor.piratenpartei-nrw.de systemd[1]: Stopped Anonymizing overlay network for TCP (multi-instance-master). Dec 14 10:12:00 tor.piratenpartei-nrw.de systemd[1]: Stopping Anonymizing overlay network for TCP (multi-instance-master)... Dec 14 10:12:00 tor.piratenpartei-nrw.de systemd[1]: Starting Anonymizing overlay network for TCP (multi-instance-master)... Dec 14 10:12:00 tor.piratenpartei-nrw.de systemd[1]: Started Anonymizing overlay network for TCP (multi-instance-master). In the tor log I have: Dec 14 00:22:25.000 [notice] General overload -> DNS timeouts (162) fraction 1.0484% is above threshold of 1.% Dec 14 00:32:25.000 [notice] General overload -> DNS timeouts (154) fraction 1.0664% is above threshold of 1.% Dec 14 00:42:25.000 [notice] General overload -> DNS timeouts (140) fraction 1.0721% is above threshold of 1.% Dec 14 01:32:57.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Dec 14 01:32:58.000 [notice] Delaying directory fetches: We are hibernating or shutting down. Dec 14 01:33:27.000 [notice] Clean shutdown finished. Exiting. Dec 14 10:12:01.000 [notice] Tor 0.4.6.8 opening log file. Dec 14 10:12:01.103 [notice] We compiled with OpenSSL 1010104f: OpenSSL 1.1.1d 10 Sep 2019 and we are running with OpenSSL 1010104f: 1.1.1d. These two versions should be binary compatible. Dec 14 10:12:01.104 [notice] Tor 0.4.6.8 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma 5.2.4, Libzstd 1.3.8 and Glibc 2.28 as libc. Dec 14 10:12:01.104 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning You can see the start was at 04:28:59 but it only started when I did "systemctl restart tor" at 10:12:01.103. I have this issue for some weeks, maybe since the late summer. I do not restart the Exit that often, so just 3 restarts due to some updates of Debian. Any idea how to troubleshoot this and what to look for? Thanks yl ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Introduction from ellie (at) nicecock
Hello Ellie, a warm welcome and very happy to have you on board. Best Regards, Kristian Dec 13, 2021, 14:19 by el...@nicecock.eu: > > Dear relay operators, > > > > > > I would like to take this opportunity to also introduce myself. Online, I > most often go by the name Ellie. I have set up one relay so far, but plan to > host one or two more in the coming days/weeks with more planned down the > road. I am not even close to running the same number of nodes as some of you > guys do, but I am just doing my part. > > > > > > All my nodes should be hosted under the tor.nicecock.eu domain. The domain > originated as an acronym for a project I did with a couple of people. > Unfortunately, it could not continue under that name. > > > > > > My eventual goal is to run somewhere around five to ten nodes. My current > node is running on AS12876, which is quite a popular choice for nodes. I > recognize this is not that good, but I figure running a node despite that is > better than not running one at all. > > > > > > I am looking forward to talking and discussing with you in the future. > > > > > > Best regards in addition to a nice day, > > > Ellie > > > > > > P.S. I hope I am not needlessly spamming the mailing list, I just wanted to > introduce myself even as a small beginning operator. > >___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
