- tor-relays - lists.torproject.org

Is Media Temple a good VPS provider for Tor Exit Nodes
by marykate＠airmail.cc 03 Jun '16

03 Jun '16

Hi, I need a VPS for running a Tor Exit node, and am eyeing Media Temple, but am unsure if MT is good for running Tor nodes. Is anybody using MT for running Tor exits? If so, what's your experience? Are they Tor friendly, or are they hostile to Tor nodes and actively oppose them? Are there better VPS providers? Best, Mary Kate

3 2

[warn] Received http status code 504 ("Gateway Time-out") from server '154.35.175.225:80' while fetching "/tor/ ...
by Robin Kjeld 03 Jun '16

03 Jun '16

Tor version 0.2.7.6 Tor relay logged this a few times: Jun 02 07:24:40.000 [warn] Received http status code 504 ("Gateway Time- out") from server '154.35.175.225:80' while fetching "/tor/server/d/6D3- 3995A9D954195FCDB0385B6A26F0F71543161+6F7D97B389CBF5409D4011155047C70E9- FCB832C+70041AC73A4118691EA88E399BE781F4B7A4CD58+701EBDF7F377CAB09F9D99- F70AAEAAE8E82544EC+70900B72F73CBFF3E72DAC29A89474788CEF9004+70A0349B8DD- 808578B4CA4DBECFEF7F136F9218C+71CEB7849F84AB7C04F209FFA16124F08953D610+- 722A3CF1578EDE7FE430C5D1D67F321086BA0DF8+72D74B2BC453A4F8F23C54E3A7417F- 1C36681156+7383EE1D444867B8F9F8F051CFF4343BB795EE28+73B2899D83B8A0C2B5A- 7B6059A155B0BEFB5ADC4+759459609126827E352FAC6F6875F39132869291+75A196C0- E4A2805B8E22F83536C3A7DE7323A1AB+768F373C6F831EF48E303430C81198527ADADD- 65+76BFB344148FF57B070AAA145B8E1FF13F349BFA+76E170B620F90AD5DC42F47473B- 19671E64B24A3+76FCB5555446C6D467BB3C90074F5629807F4EC3+7732811259B3BB6B- 4EA9226FB9BAE1BBCD28E953+793C514D5EE5B344BEE851D0E1AC74A349FB2264+79AE1- 8E570C791493C7861D50C6727E2ACAAF9D9+7B3A243BC8D5D28C35BC2228E956CEC4A84- E2FD9+7B491188699BE315594674BCF220F646374D37FB+7B6B192F80DF97B77F154759- D52DCB36EDAA4C04+7B7646488C79B4B65E68377F031C8F311B5DA41C+7C3451A8B0815- 2D3F96D14C2A8FF7E7E9A7B35BA+7C760434848F269526B9106C1AF90ECB30C99233+7D- 71D536F0008C92359B90A562C9833F5F05FBAE+7E1C1950A7811EBE18C9A13786D368F5- EE6D1739+7E4D270E81E09F6FC04C2CB86EAF35EF2D1E17DC+7EFADD3DCBCFC177FE279- 2B04E56ACBD41738048+7F149EDEB7FC006E217999D41B7847EBC1367C84+8037A25D01- DFCE6B96C17B78263C9729B392BC13+80A970A07F05248443B6323179118DD60B6FE8AF- +80D5060536A2CB4824C4EAAA49DF564AB80F8817+8168C3A6E8F8376B23E4C9C323633- CB6A1ED311F+818B389B9692BB25405A1AC61F578B3D034D70D3+82956AA740B1BD8210- 52FF6EDC73FB2806E64472+82CE752961AA720E1762EF69C55E44CDD7DDE3A1+83629CD- 7509434E26020BC28D9F5AFBC3DF9EA5C+859280FD9FF7E586AA306B11E613BEA170B82- 44C+862921EEDF2EBDD44D546F3B05AB9AD815A128CF+86916AB2F07553D663B7F3B8A8- 1383296068D180+86A954EC560D8F73DA482F38CAF0617DCB91A816+86AD7F577807E21- B57816992190A1568E1731F62+87167BB849E55F842DD78A4377FDD7477AD9C819+875D- 3632780DEE3B9E89995F52BBAE2EF4AA6B8E+87FF43A30177FD9801F604B94C55FA8BD8- 76EECC+88952C1DD1D4E42E32876940AB2D03E2B5AB25AC+889BC7B97BA1D324D7509E9- FCD8D0601F6CE6E21+894DC5E08249EFF04EC49C3BCBFFCE3122E0CCCD+8A2B0EB6E654- D220AE549C8C09EBE8D64BD2B3AF+8A7A13ED1B836A7431626A92BCBBCE77BFFA379D+8- C199B1772784027F71C951462AC2E0ED796B1BD+8E8E22DE494E10707A8DDE6EF8A6EF8- 3810A009E+8F90BD2B1C5647DAA742BA25643F2617CDCEB383+903E82F24EE49BE72DFC- C60ED4C64D0918F8D3EA+91A539224B5620E65E6A36FFA27ED5E5F4DCE35D+926FD4182- E326F2F9AAC5E2DEF51016027EE6367+92FBF1C6B639D05273CB2181F19A46DA2AC968D- B+9307B09E1DE0DA6799A827D7A51DA62BD0F7D693+931453E4CBDC0D065AA639843B5C- 12CBCD1CF26C+94CA00B23F72666493399F3E4B6C50DCE9B5571B+95302D3629AC852AF- BEBEEF4A48C99FA096A09E8+9538D730B09FE41427ACBABCD82593EA85CA77E9+95AC53- CCFB1854AAFC3EAB2A193EB0283107E414+95BA05F40C786971DB8B6E866A31C60D5FCD- BEF1+968F2D92839F2D604041B3587AC0513FD983D194+96BB8D5DCA68BC49B3D4D9A7C- 53E9E76886B6997+96BD8E7BC2830968B08D67834895FE12DB07EF49+977886E5651552- 6B4F1210B460F2C0ADD7FD0D81+98E5C2870D9803E1CBE334B2EB2B718C834138B5+98F- 9E9696885D68C11AA5116A20750B98515F7AA+992A0AF2B05F9B64B4B038BF0E2FC0020- 7154492+9951D9A803C7388126FB0303DDA89031E8453F82+99DD7FC8F1C4DE68FECE2A- B36FE289B9E01CD53B+9A26CDB3BF3904B9FC7C6E3D846D596B15E9BA58+9A412922A40- E5239D1969BDF7CB509852CD4C38D+9B4E0AA9D3C36CD9DFFFA9E6CEE3FE62E97B5069+- 9B8B598D5D46A3BBC3B4D1AA603F98374B504804+9C3B40EEB6A12E833FD4C661440413- 9CAD02D223+9C9CF0DE4D877BDE43BAFE9E9B695BED1A29D057+9DB1718DCD5F679FA0A- 6D060679C31229B53647D+9DF89A5588542EEF76379376DA1C8D76B5AB5409+9E4F0417- C3FF859F3C12DC2FCD5534EFFBC67F0C+9E676DB8E98F5859F6C5BF96D8B67141A8E2FC- D3+9E6FECAA29FF31835098BF53D964C525AA8D94AE+9F0A9522F6FB6F1EE1318D2DEB9- 4E830377CE730+9F4E97792302B5CAAC3A302E8BA0F665C4488934+A059681F1A2C40FF- 54F6ADC79536140EF33BFE69+A0627FBE8951E2CA32D6DF511EC5EBB1DC2747F5+A13AC- CB7074E264E0F240156860365BCDAFC14E8+A18B9E8897F1C5E16A12329989A79FA87D8- BAC5E+A1E21DE9D05B134243F4210E5C7A1534E0F75CC9+A20EEB1C32CA85087E036275- 9F1B6820B15EFF38+A375B7FF8818FFDA4CCD1A9B0829A850494CD7DE+A3A7118B579EC- 83D2D685CFACCE72CAF0AC2D0D4.z". I'll try again soon. Best regards Robin

2 1

Questions on traffic differences between two Exit relays in two different locations
by pa011 02 Jun '16

02 Jun '16

I would like to understand the working of two exit relays, one is about 7 days old -the other worked as a middle relay before and is an exit now for about two weeks. The second one has a higher potential connection up to 250 Mbit/s while the first is supposed to be limited on 100 Mbit/s. They both run (Linux 3.16.0-4...), Tor 0.2.7.6, both use half or less of their CPU and Memory. So why does the second node in a different city in Eastern Europe not attract more traffic compared to the first one and thereby uses its full capacity, even when the second one is longer in the market? Could please somebody explain or send me some links to read ? Does this depend on the location of the node and in which way? Node 1: day rx | tx | total | avg. rate ------------------------+-------------+-------------+--------------- 26.05.2016 594,06 MiB | 121,20 MiB | 715,27 MiB | 67,82 kbit/s 27.05.2016 30,22 GiB | 30,20 GiB | 60,42 GiB | 5,87 Mbit/s 28.05.2016 188,73 GiB | 191,03 GiB | 379,76 GiB | 36,87 Mbit/s 29.05.2016 216,98 GiB | 220,23 GiB | 437,21 GiB | 42,45 Mbit/s 30.05.2016 280,10 GiB | 285,21 GiB | 565,31 GiB | 54,89 Mbit/s 31.05.2016 334,17 GiB | 338,36 GiB | 672,53 GiB | 65,30 Mbit/s 01.06.2016 678,74 GiB | 691,32 GiB | 1,34 TiB | 133,02 Mbit/s 02.06.2016 714,88 GiB | 726,10 GiB | 1,41 TiB | Node2: day rx | tx | total | avg. rate ------------------------+-------------+-------------+--------------- 05/12/16 24.68 GiB | 25.66 GiB | 50.34 GiB | 4.89 Mbit/s 05/13/16 64.18 GiB | 66.27 GiB | 130.45 GiB | 12.67 Mbit/s 05/14/16 68.34 GiB | 70.30 GiB | 138.63 GiB | 13.46 Mbit/s 05/15/16 66.34 GiB | 68.00 GiB | 134.34 GiB | 13.04 Mbit/s 05/16/16 72.87 GiB | 74.51 GiB | 147.38 GiB | 14.31 Mbit/s 05/17/16 73.32 GiB | 74.74 GiB | 148.06 GiB | 14.38 Mbit/s 05/18/16 81.14 GiB | 82.17 GiB | 163.30 GiB | 15.86 Mbit/s 05/19/16 72.22 GiB | 74.33 GiB | 146.55 GiB | 14.23 Mbit/s 05/20/16 74.62 GiB | 76.93 GiB | 151.55 GiB | 14.71 Mbit/s 05/21/16 96.44 GiB | 98.68 GiB | 195.12 GiB | 18.94 Mbit/s 05/22/16 227.48 GiB | 225.03 GiB | 452.50 GiB | 43.93 Mbit/s 05/23/16 216.46 GiB | 214.71 GiB | 431.17 GiB | 41.86 Mbit/s 05/24/16 231.87 GiB | 227.53 GiB | 459.41 GiB | 44.60 Mbit/s 05/25/16 302.77 GiB | 298.03 GiB | 600.80 GiB | 58.33 Mbit/s 05/26/16 280.37 GiB | 273.64 GiB | 554.01 GiB | 53.79 Mbit/s 05/27/16 318.75 GiB | 312.23 GiB | 630.98 GiB | 61.26 Mbit/s 05/28/16 317.57 GiB | 311.64 GiB | 629.21 GiB | 61.09 Mbit/s 05/29/16 271.41 GiB | 267.75 GiB | 539.16 GiB | 52.35 Mbit/s 05/30/16 290.85 GiB | 284.82 GiB | 575.67 GiB | 55.89 Mbit/s 05/31/16 323.61 GiB | 313.39 GiB | 637.00 GiB | 61.85 Mbit/s 06/01/16 279.34 GiB | 276.31 GiB | 555.65 GiB | 53.95 Mbit/s 06/02/16 259.17 GiB | 256.20 GiB | 515.38 GiB |

3 2

Tor Weather has been discontinued
by Karsten Loesing 02 Jun '16

02 Jun '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear relay operators, as of April 4, 2016, Tor Weather has been discontinued. Tor Weather [0] provided an email notification service to any user who wanted to monitor the status of a Tor node. Upon subscribing, they could specify what types of alerts they would like to receive. The main purpose of Tor Weather was to notify node operators via email if their node was down for longer than a specified period, but other notification types were available, including one where operators would be informed when their node was around long enough to qualify for a t-shirt. The main reason for discontinuing Tor Weather is the fact that software requires maintenance, and Tor Weather is no exception. Tor Weather was promising t-shirts for relays that have not been around long enough or that provided too little bandwidth to be useful to the network, and it was almost impossible to deny a t-shirt after Tor Weather has promised it. Apart from that, Tor Weather was likely not offering t-shirts to people who have long earned it, thereby confusing them. An unreliable notification system is worse than not having a system at all. Relay operators shouldn't rely on Tor Weather to notify them when their relay fails. They should rather set up their own system instead. We have tried to find a new maintainer for Tor Weather for years, but without success. We started rewriting Tor Weather [1] using Onionoo [2] as data back-end in 2014, and even though that project didn't produce working code, somebody could pick up this efforts and finish the rewrite. The Roster developers said that they're planning to include an email notification function in Roster [3]. And we developed a simple Python script that provides information about a relay operator's eligibility for acquiring a t-shirt [4]. None of these alternatives is a full replacement of Weather, though. We encourage you, the community of Tor relay operators, to step up to start your own notification systems and to share designs and code. Tor Weather is still a good idea, it just needs somebody to implement it. Tor Weather is discontinued in two steps. For now, new subscriptions are disabled, new welcome messages are not sent out anymore, and existing subscriptions continue working until June 30, 2016. From July 1, 2016 on, Tor Weather will not be sending out any emails. Sorry for any inconvenience caused by this. All the best, Karsten [0] https://weather.torproject.org/ [1] https://trac.torproject.org/projects/tor/wiki/doc/weather-in-2014 [2] https://onionoo.torproject.org/ [3] http://www.tor-roster.org/ [4] https://gitweb.torproject.org/metrics-tasks.git/tree/task-9889/tshirt.py -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJXAn7HAAoJEC3ESO/4X7XBmhEIAKxWEwex5pyp5RBHkE4+1IC2 WaKjcvIT0WiZJ8prZASNSxF7ART6r2trG50+Pd2GCdu0SOjIz3eeQNSkx251RaqF xF7dw2RVhExcYOar4FG5+KkXu6X3k0svMvNeMGzcRd51yaaVeW8OaAgV0NC+CHgE ZkA7bg26jCvG8EFrKCg4fuZ3JW3+O3mvcquea+aB4q6gbuQFjgoxzfH5+XkmpA5i gDZnsIRuBDYuUW8V1ior/7DG2wGlCjWZUotoTysfsFW2FSMUrTBZOlvhpHicMfER VpLxY8+b3ZGC6Olit50ISZql8l12yO3Hik32eKIcgK2fpx6vgKE+T83I8voIpOU= =LVj8 -----END PGP SIGNATURE-----

7 11

ansible-relayor 0.1.0 released
by nusenu 02 Jun '16

02 Jun '16

Hi, ansible-relayor is an ansible [1] role for tor relay operators. Whether you setup/operate a single or many relays, ansible-relayor can help you automate all steps including secure offline key [2] generation, multi-instance setup and MyFamily management. https://github.com/nusenu/ansible-relayor Main benefits for a tor relay operator ====================================== * security: Ed25519 master keys are kept offline * easy key renewal with a single command * security: every tor instance is run with a distinct user * automatically makes use of IPv6 IPs (if available) * automatic MyFamily management * automatic multi-instance setup (configurable) * easily restore/move a relay Supported Platforms =================== * FreeBSD 10.x * OpenBSD 5.9 * Debian 8 * Ubuntu 16.04 * CentOS 7 * Fedora 23 Installation ============ relayor is available via ansible-galaxy: ansible-galaxy install nusenu.relayor https://galaxy.ansible.com/nusenu/relayor/ Documentation ============== https://github.com/nusenu/ansible-relayor/blob/master/README.md https://github.com/nusenu/ansible-relayor/wiki playbook examples: https://github.com/nusenu/ansible-relayor/wiki/relayor-playbook-examples migration steps for existing relays https://github.com/nusenu/ansible-relayor/wiki/Migration-Steps git tags are signed with: pub 4096R/4D705DE9 2016-02-11 Key fingerprint = A7B5 DB91 CE04 C9E0 BE66 446B 8CBE 52BD 4D70 5DE9 uid ansible-relayor signing key (https://github.com/nusenu/ansible-relayor) regards, nusenu [1] https://docs.ansible.com/ansible/intro_getting_started.html [2] https://trac.torproject.org/projects/tor/wiki/doc/TorRelaySecurity/Offli neKeys

1 0

The Tor's non-discretionary model - Milica D. Djekic
by Milica Đekić 01 Jun '16

01 Jun '16

Would Tor use a non-discretionary model of data transfer between the relays that would be a part of non-centralized network? Is there any real encryption in sense of information flow or only a conversion from discrete to non-discrete signal? Which circuitry algorithm would get used for so? Sorry, for asking all of these - I am just reading the history of anonymity. Thank you so much! On Wed, Jun 1, 2016 at 2:00 PM, <tor-relays-request(a)lists.torproject.org> wrote: > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > > Today's Topics: > > 1. Re: [Fwd: Re: I'm Running A Tor Exit But Never Initiated It] > (Roger Dingledine) > 2. Re: [Fwd: Re: I'm Running A Tor Exit But Never Initiated It] > (Greg Moss) > 3. Re: [Fwd: Re: I'm Running A Tor Exit But Never Initiated It] > (JovianMallard) > 4. Re: I'm Running A Tor Exit But Never Initiated It > (Peter Palfrader) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 31 May 2016 19:21:38 -0400 > From: Roger Dingledine <arma(a)mit.edu> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] [Fwd: Re: I'm Running A Tor Exit But Never > Initiated It] > Message-ID: <20160531232138.GB55745(a)moria.seul.org> > Content-Type: text/plain; charset=us-ascii > > On Tue, May 31, 2016 at 07:05:23PM -0400, Percy Blakeney wrote: > > In addition I DO NOT have the full Xfinity package. > > Hi folks, > > I'm going to put an end to this thread now. Please be aware that 1700+ > people are on the tor-relays list, so we really need to keep things > concise and on-topic. > > Thanks! > --Roger > > > > ------------------------------ > > Message: 2 > Date: Tue, 31 May 2016 16:25:32 -0700 > From: Greg Moss <gmoss82(a)gmail.com> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] [Fwd: Re: I'm Running A Tor Exit But Never > Initiated It] > Message-ID: > <CALA4K1TTE11B21p7Vb3+K=GBiomzJT5o_kk= > EwUOn0Mbwo_v9A(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Thanks Mr dingledine- was a good laugh but enough is enough > On May 31, 2016 4:21 PM, "Roger Dingledine" <arma(a)mit.edu> wrote: > > On Tue, May 31, 2016 at 07:05:23PM -0400, Percy Blakeney wrote: > > In addition I DO NOT have the full Xfinity package. > > Hi folks, > > I'm going to put an end to this thread now. Please be aware that 1700+ > people are on the tor-relays list, so we really need to keep things > concise and on-topic. > > Thanks! > --Roger > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >

1 0

I'm Running A Tor Exit But Never Initiated It
by Percy Blakeney 01 Jun '16

01 Jun '16

According to files and folders I have on two separate computers in my house, I am running a Tor exit but I absolutely have nothing to do with it. I am only able to physically view certain files ie; var/log/tor, etc/tor/torrc, while other files like var/lib/tor/lock the content is invisible. I am MORE than willing to talk to anyone who may be able to help.

7 10

Re: [tor-relays] [Fwd: Re: I'm Running A Tor Exit But Never Initiated It]
by Greg Moss 31 May '16

31 May '16

Thanks Mr dingledine- was a good laugh but enough is enough On May 31, 2016 4:21 PM, "Roger Dingledine" <arma(a)mit.edu> wrote: On Tue, May 31, 2016 at 07:05:23PM -0400, Percy Blakeney wrote: > In addition I DO NOT have the full Xfinity package. Hi folks, I'm going to put an end to this thread now. Please be aware that 1700+ people are on the tor-relays list, so we really need to keep things concise and on-topic. Thanks! --Roger _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

[Fwd: Re: I'm Running A Tor Exit But Never Initiated It]
by Christian 31 May '16

31 May '16

-------- Weitergeleitete Nachricht -------- > Von: Christian Adam <hirnwurst(a)t-online.de> > An: tor-relays(a)lists.torproject.org > Betreff: Re: [tor-relays] I'm Running A Tor Exit But Never Initiated > It > Datum: Mon, 30 May 2016 22:14:51 +0200 > > Dear Percy, > > I read all of your messages very carefully and, please, believe me, I > don't mean to be rude, but just want to provide you a little bit of > relief. > > First of all, I have to share that I AM in fact a schizophrenic for 16 > years now, but fully therapied to the extent I do a job as a system > administrator and get certified for being a data security officer this > week. > This won't reveal any competence on my side, but gives a clue about my > functional level which is, after all, related to sanity. > > Why do I tell this? > Because you don't seem to know much about computers AND because 60% of > the population experience states during their lifetime resembling mine > while diagnosed, but nobody minds and it goes away and was just > triggered by external circumstances and internal attributions. > > I tell this, because my delusional system did not involve at all any > technical devices, but was completely interpersonal and cultural, which > is a little seldom in western countries. > > So, I learned that even if improbable, it helps keeping a harmless, > maybe also annoying, possibility in mind. > > Read Foster-Wallace, This Is Water? > > So, let's have a clue at the facts. > You moved to a new region. > So, you were not yet closely related to your new environment and the old > one you left might have been more and more distant, which makes people > sometimes do morally questionable things. > > You don't know anything about computers, so, someone must have installed > your linuxes. > > I also do that for people. My 73-year-old mom uses linux. And a former > friends mother. > I do remote administration via Teamviewer as I prefer users being > graphically informed I am on their box after their consent. > > Maybe the girl or guy who installed your linuxes has enabled SSH remote > access combined with a DynDNS name resolving to remotely administrate > (and spy) you (out). > > Maybe things got socially weird, not technically. > Maybe the computer shutdown at the library was just coincidence, as this > also happened to me at a university terminal which might have been > poorly maintained. > > In my educational company, the public PCs are the most poorly maintained > and I know that because I am in charge of that and not every library is > financially well off. > > The config you posted reveals two things: > 1. NOT an exit. > 2. You don't know that. > Let me explain. The hash symbol # comments out lines, i.e. these lines > don't contain config, but human readable remarks. > Of course, in a default config file, you can include commented out > options because the easily can be activated by removing the #. > Lines beginning with # are just nothing. > > The second thing is, that your "hard drive is partitioned". > Every hard drive is partitioned. > Operating systems don't use the raw physical devices, but the partitions > made up on them containing the file systems. > > On the most basic Windows installs, there's at least one partition which > you might know as device C:. > Personally, when I install linux, I separate system and user data which > results in two partitions at minimum, one containing /, the root > directory ("file system" in your file browser), and /home containing the > users' personal folders. > > Next thing is that /var/lib/tor contains among others sensitive > statistical data concerning the relays users and are therefore is only > accessible as root via a sudo command. > If you type "sudo -i" and "cd /var/lib/tor", you should be able to > access it as sudo provides you with administrator privileges which are > called root privileges on linux. > You cannot do "sudo cd /var/lib/tor". > > If this folder was normally accessible, someone could just use a > vulnerability in your firefox and learn from where your users originate > and if he knows your record of connections, he would know what the > people from region X do with your connection: accessing a relay or a > bridge, which sets users not only in other jurisdictions at risk of > uncontrolled data collection by whoever it is. > > I asked my mom whether she wants to run a bridge. > She didn't and so I did not install one. > I asked my CEO if he wants to run a bridge. > He didn't and so I did not install one. > I just got the job because I told everything an employer is not allowed > to ask here in Germany, because I told them that they first have to > decide whether to trust me as I will have highest privileges on the > entire network including their private PCs. > > What is true that remote administration is great for saving time and > miles to do people a quick favour. > But it can be used irresponsibly. > > Maybe the one providing you your installs decided you won't even notice > and you get that relay, period. > Not nice. Not responsible. Morally highly questionable. > But after all, quite probable, as every device has a partitioned hard > drive and real adversaries have a keen eye on you not noticing never > ever you have been compromised, except ransomware tricking you into > sending money via Western Union or Bitcoins. > > Criminals want to do criminal business, except ransomware tricking you > into sending money via Western Union or Bitcoins, and agencies want to > prosecute, but scaring you is not an aim of either if you're not an > agent yourself. > > In my house are 8 appartements. > Two of us are schizos. > We integrate well (public health system) and our neighbours like us, > but, of course, we use linux and of course, we have paranoid passwords > and of course... you understand, I guess. > > I have never ever been hacked. > But in my company, I can access every computer without prompting for > consent as everybody finds that comfortable cause they know about that. > I'm in the network at 3 a.m. and I can turn on half of the workstations > while laying in my bed. > > I know how that feels. > My diagnosis reads "paranoid-hallucinatoric schizophrenia" and I know > how it feels to have a perspective not even one of 7 billion people > share. > > Sensitivity is paranoia's beautiful sister. > I strongly suggest someone just wants to mock you. > > Given my experience with newbie users, paranoia and system > administration, what you wrote seemed quite normal and you didn't > provide (as far as I remember) any unusual technical details. > > Maybe what just happened was a lack of informed consent resulting in a > tasteless prank. > > I don't want to do injustice to you, but since Edward Snowden, we're all > used to question every system crash and honestly, our times seem to be > hysterical and violence-saturated. > > The rule is simple. When a user thinks he's infected, he's almost always > not. > If he's infected, he wouldn't notice. > > Hugs, I hope you find peace again soon. > > Please don't feel offended, I only told my story based on the facts you > gave. > > And kind regards, > > christian > > > Am Montag, den 30.05.2016, 13:25 +0200 schrieb Christian Pietsch: > > Hi GDR! > > > > On Mon, May 30, 2016 at 12:54:41PM +0200, GDR! wrote: > > > On Sun, 29 May 2016 15:23:24 +0000 "krutt(a)anche.no" <krutt(a)anche.no> wrote: > > > > > > > I can't image a single reason why Tor should be configured to run a > > > > relay without the system admins knowledge. > > > > > > Debian did this - I'm not sure if it does that any more. > > > > This bug is not present in current and recent versions of Debian. > > > > > `apt-get install tor` used to run an exit relay unless you uncomment > > > "ExitPolicy reject *:*" in torrc. I had the same problem a few years > > > ago, suddenly captchas started appearing everywhere after installing > > > tor. > > > > Do you mean this bug in Tor 0.1.0 which was fixed in 2005? > > > > -------------- begin quote from the Debian changelog -------------- > > > > tor (0.1.0.11-1) unstable; urgency=high > > > > * New upstream version (closes: #316753): > > - Fixes a serious bug: servers now honor their exit policies - > > In 0.1.0.x only clients enforced them so far. 0.0.9.x is > > not affected. > > * Build depend on libevent-dev >= 1.1. > > * Urgency high because 0.0.9.10-1 did not make it into testing after > > like 3 weeks because of an impending ftp-master move. So I might > > just as well upload this one. > > > > -- Peter Palfrader <weasel(a)debian.org> Mon, 4 Jul 2005 17:53:48 +0200 > > > > -------------- end quote from the Debian changelog -------------- > > > > > > Cheers, > > Christian > > > > _______________________________________________ > > tor-relays mailing list > > tor-relays(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > >

9 22

Re: [tor-relays] Question on warnings
by Tristan 30 May '16

30 May '16

Not sure where I found this, but I remember reading that Tor changed how it stored bandwidth information. Arm wasn't updated yet, so it throws an error. On May 30, 2016 4:32 PM, "Green Dream" <greendream848(a)gmail.com> wrote: Hi. Thanks for running a relay. These notice messages are from the monitoring tool Arm, and should not affect the Tor process. If you don't care about Arm and Tor seems to be working okay otherwise, you could safely ignore these messages. In case you want to look into them further, I'll share some thoughts below. It looks like you're running on a Unix or Linux system, I'll assume Debian or Ubuntu for the moment. > 20:42:57 [ARM_NOTICE] Unable to prepopulate bandwidth information > (unable to read the state file) This is normal in my experience. Arm is trying to read your node's bandwidth history to populate the graphs with data collected before you started Arm. I don't know why it fails, but you could squelch it by adding the following config line to ~/.arm/armrc: features.graph.bw.prepopulate false > 20:42:56 [ARM_WARN] Unable to read tor's log file: > /var/log/tor/log [1duplicate hidden] It looks like Arm doesn't have permission to read /var/log/tor/log. I normally start Arm with something like this, so it has the same permissions as the Tor daemon: sudo -u debian-tor arm > 20:42:56 [ARM_NOTICE] Tor is preventing system utilities like netstat > and lsof from working. This means that arm can't provide you with > connection information. You can change this by adding > 'DisableDebuggerAttachment 0' to your torrc and restarting tor. For > more information see... https://trac.torproject.org/3313 You need to add the following to /etc/tor/torrc if you want to utilize all the features of Arm: DisableDebuggerAttachment 0 It's disabled by default for security (with a value of '1'), so think carefully before doing this. It "reduces security by enabling debugger attachment to the Tor process. This can be used by an adversary to extract keys." (Quoting from https://trac.torproject.org/projects/tor/ticket/13880) If you do enable the deubgger attachment for Arm, make sure your control port is locked down (not reachable from the Internet or from other hosts you don't control, etc.) _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 1