Re: [tor-dev] Performance testing using chutney

2015-07-09 Thread Cory Pruce 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


>
> If you can read Python and shell script, then checking I haven't made
any obvious coding errors in my changes would help. But that might
require becoming familiar with the codebase - which may take some effort.
>
> The diffs are here, or you can use git diff:
>
https://github.com/teor2345/chutney/compare/feature14175-chutney-performance-v2
>
https://github.com/teor2345/tor/compare/feature14175-chutney-performance-v2
Awesome, yup I can read those languages. I'll hopefully wrap my head
around chutney's and tor's code in a reasonable amount of time. Gotta
start somewhere =-)


>
>
> When you make performance improvements, does the bandwidth increase?
> (Or, far more easily: when you deliberately slow down the code, does
the bandwidth tank?)

Sounds like a good idea to me!

Thanks again,

Cory

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJVn2xXAAoJEB7DuCIJauCg38cQAKWH+Ovs0Kko+dyXHaKyysnH
pvxViQqLSWvXGdz09U+hBlzH743PigD7l8ibUFbyWaDz62WcXQRw6oo6OqgTJjN5
x1C3aTcL/766wfTHqXWUUfqgWB+gemrBsW7W8bZHJzvHUcs6y69KX1gUVavyJQuj
aGM5JTkXftdJgkWZTGnIPAtcFPWV+nKY/k2bUo/jZQaLz6uUdklM1KYH/8u2ZqE/
f/Q/bPOyO2yG2Y9BJ9ZPAYjDB5ENMuSVUdk2/NJuEubBEEd2LvVLlufu3m5uuYn6
sW44pVbU2zk7NtbTeY+uVFacLjbMDXun39hL+PXM4SSfp+Tvtgbq28Z6L6qT6Bgu
+YKUvn4xmo4jScEYKItCP/JMhz2ssvcHvGSSOa7dP1rdFqeluQQUmp7bYDXGcz5d
fZszqX/0uRXYe3hf+ln7fxPoCsLZtg3W9EcfmSrutPLyifwXpKGMjRoDbe2BRvm9
OMmvTWCj0UiLzz2pHGblaFNpw1l+3uEvzXUca08eLCVLIZZE2awc1je+OBggoY7w
urVQXIc9vAl6kIirrQVOLssSZrjFbsDEpnEpr4IoONeW0M+WkEO92roOBIQp+C/O
eHp93NPoGdKlU1U3bFwaDKqXYbBoF0GzC+cI5UO5Jqyq59muQFxBeokW6vX/RNPj
3zblrb+9uqADwl4kRu39
=s11f
-END PGP SIGNATURE-


___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Performance testing using chutney

2015-07-09 Thread teor 

> On 10 Jul 2015, at 11:35 , teor  wrote:
> 
> 
>> On 10 Jul 2015, at 09:47 , Cory Pruce  wrote:
>> 
>> 
>> Signed PGP part
>> 
>>> 
>>> Well, you could test my latest branches for #14175:
>> 
>> Hey Tim, I got the branch of chutney and tor and made sure that the
>> commands you run in the comments of the issue exist. What do you think
>> would be a good way to start testing? Begin with a static analysis of
>> the code?
> 
> If you can read Python and shell script, then checking I haven't made any 
> obvious coding errors in my changes would help. But that might require 
> becoming familiar with the codebase - which may take some effort.
> 
> The diffs are here, or you can use git diff:
> https://github.com/teor2345/chutney/compare/feature14175-chutney-performance-v2
> https://github.com/teor2345/tor/compare/feature14175-chutney-performance-v2

This commit contains all the tor changes:
https://github.com/teor2345/tor/commit/128d4a68967fb2986965e9f8443f362a9dc20ecc

(The github comparison picked the wrong base branch, so it's huge and 
unhelpful.)

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
pgp ABFED1AC
https://gist.github.com/teor2345/d033b8ce0a99adbc89c5

teor at blah dot im
OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Performance testing using chutney

2015-07-09 Thread teor 

> On 10 Jul 2015, at 09:47 , Cory Pruce  wrote:
> 
> 
> Signed PGP part
> 
> >
> > Well, you could test my latest branches for #14175:
> 
> Hey Tim, I got the branch of chutney and tor and made sure that the
> commands you run in the comments of the issue exist. What do you think
> would be a good way to start testing? Begin with a static analysis of
> the code?

If you can read Python and shell script, then checking I haven't made any 
obvious coding errors in my changes would help. But that might require becoming 
familiar with the codebase - which may take some effort.

The diffs are here, or you can use git diff:
https://github.com/teor2345/chutney/compare/feature14175-chutney-performance-v2
https://github.com/teor2345/tor/compare/feature14175-chutney-performance-v2

Also, I was only using Python 2, so I might have accidentally introduced some 
incompatibilities with Python 3.

> Verify that the bandwidth is correct?

Since it's the localhost, CPU-limited, massively-parallel bandwidth, there's no 
"correct" value.
I'm not even sure what sane values are, but we'll get an idea once people start 
competing for the biggest numbers.

> Let me know what you
> think is important/feasible.

Does it run?
When you make performance improvements, does the bandwidth increase?
(Or, far more easily: when you deliberately slow down the code, does the 
bandwidth tank?)

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
pgp ABFED1AC
https://gist.github.com/teor2345/d033b8ce0a99adbc89c5

teor at blah dot im
OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Performance testing using chutney

2015-07-09 Thread Cory Pruce 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


>
> Well, you could test my latest branches for #14175:

Hey Tim, I got the branch of chutney and tor and made sure that the
commands you run in the comments of the issue exist. What do you think
would be a good way to start testing? Begin with a static analysis of
the code? Verify that the bandwidth is correct? Let me know what you
think is important/feasible.

- - Cory
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJVnwgeAAoJEB7DuCIJauCgPCQP+wb1uMbW3eo0ATq0aahxrwoK
Nc9H7p1vtYfLNeN1Kai4XDOetxNmPSYhhuYRpDuSeZ1OJjBqAJ/EI9gl0iDRzaP+
byFA8VrLQTrJ1j7lj0Dz/foIOlcsnKyufRtVwy/yWGkbBpG6u+UWvWVrNyU9iy3w
sNyMiniqiI4Z9SLhVtO/oV+Jb1UMSGaj2//nRoxhGY1uv1ExRcjXhMIaPeQFgRO7
BJhhjIo9RtV0pN/Z0ZrrU8xbA3XooRTBjXyoZxLLp7fi/YRLsUywn4qJ/jjh9NhG
6OeoYTdD2Na1HOX7oBNsDteoobE7LSnuc8RUNtu2wyvlyzL58RvHyADmuoJELZkf
9AXMIjxELmRLl0aYN2B+Ge/0/QhQTpa/fTKsj4WUG+KYMRbhDD2mfJo/K0noByao
bJsbnuucYu0ie/y608aiGwGxmSJIZy3GnCdu9dUzqassAGGkVGdgQ+fXkVVFxUrH
HwFUH2eLle3rkGO1a5q0GSOxzCJhD3sZoI2HIjjCPw+oaAgNMC5k7joAl/9DZ8rH
IFUshRDgjHLnIlACAOZjmc4hbelVApFtddVzBJHxaGkmKT60p8ZIRljifNRFYP2L
C186YksygXjDGfxOSoDVCP6TOlKN7J8HRxcepf+9Gi/+Vp7W6aLOIjc+S+bWOWMP
1YaAhNWDQR8Jiy5v+8eF
=wqKb
-END PGP SIGNATURE-

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] CollecTor data: mapping bridge-network-status to bridge-server-descriptor to bridge-extra-info

2015-07-09 Thread Roger Dingledine 
On Thu, Jul 09, 2015 at 12:04:52PM -0700, David Fifield wrote:
> On Wed, Jul 08, 2015 at 11:39:54PM -0400, Roger Dingledine wrote:
> > > It seems rare that the bridge-server-descriptor is missing. In the
> > > 2015-07 tarball, it happened for 5891/477496 relays (1.2%).
> > [snip]
> > > How do you handle cases like this? I had a browse through the Onionoo
> > > source code, but did not quickly understand it. Should I just always
> > > include the month preceding the earliest month I want to process?
> > 
> > How many of the 5891 cases does that resolve?
> 
> Peeking into 2015-06 resolves all 5891 cases of missing
> bridge-server-descriptor in the 2015-07 tarball. (There are still 4
> cases of missing bridge-extra-info.)

Awesome. Sounds like a great reason to peek into the previous month. :)

--Roger

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Update: Proposal 237 - All relays are directory servers

2015-07-09 Thread Nick Mathewson 
On Sat, Mar 21, 2015 at 7:33 PM, Matthew Finkel
 wrote:
>
> Hi All,
>
> Here's an updated version of prop 237. I rewrote some parts
> for clarity and brought it inline with the current implementation
> for #12538.
>
> Updated branch on prop237_update in my torspec repo.
>

Thanks!  Just merged to torspec.

(Sorry for the delay; I am cleaning out my inbox with shovel and tongs)

-- 
Nick
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] CollecTor data: mapping bridge-network-status to bridge-server-descriptor to bridge-extra-info

2015-07-09 Thread David Fifield 
On Wed, Jul 08, 2015 at 11:39:54PM -0400, Roger Dingledine wrote:
> > It seems rare that the bridge-server-descriptor is missing. In the
> > 2015-07 tarball, it happened for 5891/477496 relays (1.2%).
> [snip]
> > How do you handle cases like this? I had a browse through the Onionoo
> > source code, but did not quickly understand it. Should I just always
> > include the month preceding the earliest month I want to process?
> 
> How many of the 5891 cases does that resolve?

Peeking into 2015-06 resolves all 5891 cases of missing
bridge-server-descriptor in the 2015-07 tarball. (There are still 4
cases of missing bridge-extra-info.)
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] tor#16518: Read-Only Filesystem Error opening tor lockfile in 0.2.6.9 but not 0.2.5.12

2015-07-09 Thread aexlfowley 
> On 07/09/2015 03:24 PM, aexlfowley at web.de wrote:
>> Correct. I edited /lib/systemd/system/tor.service and added
>>   ReadWriteDirectories=-/media/cRAID/Tor
>> and now 0.2.6.9 is running.
>> I'm not entirely sure how to create my own
>> /etc/systemd/system/tor.service so I leave it at that.
>> (Trying out 'systemctl edit' I get "Unknown operation 'edit'." BTW.)
> 
> Just copy the /lib/systemd/system/tor.service file to
> /etc/systemd/system and edit it there -- it will take precedence over
> the one in /lib . You don't want to edit the one in /lib directly, since
> it is meant to be for distribution files that can/should be replaced on
> upgrades.

> Moritz Bartl wrote (09 Jul 2015 14:21:26 GMT) :
>> Just copy the /lib/systemd/system/tor.service file to
>> /etc/systemd/system and edit it there -- it will take precedence over
>> the one in /lib . You don't want to edit the one in /lib directly, since
>> it is meant to be for distribution files that can/should be replaced on
>> upgrades.
> 
> Right. And even better: using drop-in override files would avoid
> having to maintain a local forked copy of the unit file. Look for
> ".conf" in systemd.unit(5).
> 
> Cheers,
> --
> intrigeri

Okay, so I created /etc/systemd/system/tor.service.d/directory.conf
containing
  [Service]
  ReadWriteDirectories=/media/cRAID/Tor

Thanks again. And sorry for the noise.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] tor#16518: Read-Only Filesystem Error opening tor lockfile in 0.2.6.9 but not 0.2.5.12

2015-07-09 Thread Nick Mathewson 
On Thu, Jul 9, 2015 at 11:44 AM, intrigeri  wrote:
> Moritz Bartl wrote (09 Jul 2015 14:21:26 GMT) :
>> Just copy the /lib/systemd/system/tor.service file to
>> /etc/systemd/system and edit it there -- it will take precedence over
>> the one in /lib . You don't want to edit the one in /lib directly, since
>> it is meant to be for distribution files that can/should be replaced on
>> upgrades.
>
> Right. And even better: using drop-in override files would avoid
> having to maintain a local forked copy of the unit file. Look for
> ".conf" in systemd.unit(5).

If this one turned out to be NotABug, could somebody close the ticket
mentioned in the subject line?
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Tor Browser videos Automation

2015-07-09 Thread Arthur D. Edelstein 
Hi Sherief,

 Karsten insisted that I have to run a local copy of torproject.org
  using a web server while the automated script
 runs since we can't estimate or depend on the connection speed. The
 major blocker in this is that the browser redirects to
 https://torproject.org/ whenever I try to map 127.0.0.1 to
 torproject.org  (or www.torproject.org
 ) in my /etc/hosts file.

So you're trying to get http, but you get https, correct? Sounds like
it might be the HSTS Preload list. See
https://blog.mozilla.org/security/2012/11/01/preloading-hsts/
torproject.org is among the domains on Firefox's preload list:
https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/nsSTSPreloadList.inc

I think you can turn off HSTS Preloading by creating an integer pref
named "test.currentTimeOffsetSeconds", and setting it to 11491200.
(Under about:config, right-click and choose "New > Integer".)

Arthur
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Tor Browser videos Automation

2015-07-09 Thread Isabela 
+ tor-dev

Sorry for the noise, but thought of expanding the audience a little,
maybe someone the time to take look into this, or might know what is
going on.

Any help is appreciated, we are trying to finish this project and this
has been blocking us.

Thanks!


Sherief Alaa:
> On Mon, May 18, 2015 at 3:49 PM, Mark Smith  wrote:
>
>> On 5/17/15 6:54 AM, Sherief Alaa wrote:
>>
>>> Hi Georg/Mark,
>>>
>>> I am working on the new Tor Browser videos this month (or at least a
>>> process to produce them in an automated manner). I am contacting you
>>> because I am running into a problem that you may know how to solve
>>> because I think it's browser related.
>>>
>>> Karsten insisted that I have to run a local copy of torproject.org
>>>  using a web server while the automated script
>>> runs since we can't estimate or depend on the connection speed. The
>>> major blocker in this is that the browser redirects to
>>> https://torproject.org/ whenever I try to map 127.0.0.1 to
>>> torproject.org  (or www.torproject.org
>>> ) in my /etc/hosts file. Now I've tried
>>> everything that will come up to mind that may solve the problem, such
>>> as: flushing DNS cache, clearing history, disabling all addons and more
>>> but nothing worked.
>>>
>>> I also ran Wireshark to inspect DNS packets but the browser doesn't even
>>> try to query any DNS server.
>>>
>>> I've tested on OS X and Ubuntu and both produce the same results. I've
>>> also tested multiple browsers (Safari, Chrome and Firefox). Same results.
>>>
>>> Trivial note: During testing, I could map google.com
>>> , ign.com  and basically all .coms
>>> but never for .orgs like eff.org  or torproject.org
>>> 
>>>
>>> If you have any idea what's going on, please let me know as soon as
>>> possible as I am considering running a local nameserver but I am keeping
>>> that as a last resort.
>>>
>> I do not know what is going on.  Most likely it is a caching problem (both
>> the OS and browser cache DNS info, as you know).  But Kathy (CC'd on this
>> reply) and I experimented a little on Mac OS 10.9.5 and found like you did
>> that some hosts worked and some did not, even after doing dscacheutil
>> -flushcache and using Firefox with a new profile.  From the command line,
>> ping always seems to respect /etc/hosts but other things such as curl do
>> not.  Which I guess means it is an OS caching issue, or some applications
>> have their own DNS resolver that bypasses the OS libraries.
>>
>> -Mark
>>
> Ccing Isabela
>
>
> -- 
> PM at TorProject.org
> gpg fingerprint = 8F2A F9B6 D4A1 4D03 FDF1  B298 3224 4994 1506 4C7B
> @isa



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] tor#16518: Read-Only Filesystem Error opening tor lockfile in 0.2.6.9 but not 0.2.5.12

2015-07-09 Thread intrigeri 
Moritz Bartl wrote (09 Jul 2015 14:21:26 GMT) :
> Just copy the /lib/systemd/system/tor.service file to
> /etc/systemd/system and edit it there -- it will take precedence over
> the one in /lib . You don't want to edit the one in /lib directly, since
> it is meant to be for distribution files that can/should be replaced on
> upgrades.

Right. And even better: using drop-in override files would avoid
having to maintain a local forked copy of the unit file. Look for
".conf" in systemd.unit(5).

Cheers,
--
intrigeri
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] tor#16518: Read-Only Filesystem Error opening tor lockfile in 0.2.6.9 but not 0.2.5.12

2015-07-09 Thread Moritz Bartl 
On 07/09/2015 03:24 PM, aexlfow...@web.de wrote:
> Correct. I edited /lib/systemd/system/tor.service and added
>   ReadWriteDirectories=-/media/cRAID/Tor
> and now 0.2.6.9 is running.
> I'm not entirely sure how to create my own
> /etc/systemd/system/tor.service so I leave it at that.
> (Trying out 'systemctl edit' I get "Unknown operation 'edit'." BTW.)

Just copy the /lib/systemd/system/tor.service file to
/etc/systemd/system and edit it there -- it will take precedence over
the one in /lib . You don't want to edit the one in /lib directly, since
it is meant to be for distribution files that can/should be replaced on
upgrades.

-- 
Moritz Bartl
https://www.torservers.net/
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Today's openssl vulnerability; preliminary analysis wrt Tor

2015-07-09 Thread Nick Mathewson 
tl;dr: CVE-2015-1793 does not appear to affect Tor. Update your
OpenSSL anyway; other applications are certainly affected.



Hi, all!

Here's the announcement for today's major security issue in
OpenSSL1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o:

  https://www.openssl.org/news/secadv_20150709.txt

So far, I have only looked at the announcement itself, and the commit
messages--not yet  the code. But from what I can tell, it should only
affect programs that have trusted certificates in their store.  Tor
itself does not use trusted root certificates, so it is not affected.

(Similarly, TorBrowser should not be affected: it uses NSS, not OpenSSL.)

Still, you likely have lots of other programs that depend on OpenSSL
and trusted certificates to build certificate chains, and those
programs _will_ be  affected.  So, you should probably upgrade OpenSSL
as soon as feasible.

(I'll spend a little more time patches and reviewing Tor's code to
confirm my analysis above, and I invite others to do so as well. I'm
in recovery from my vacation today.)

best wishes,
-- 
Nick
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] 3rd status report for OnioNS

2015-07-09 Thread Jesse V 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello everyone,

I have been making significant progress on the Onion Name System project, and 
it's really coming down the home stretch here.

* I have been focusing on a four-party system: a hidden service operator, an 
authoritative server, a name server (mirror), and a client. Thus two servers 
are involved, so the responsibility is split.
* The mirror can now subscribe to the authoritative server for events, thus it 
receives new Records (claims on domain names) and new signatures on the data 
structures. The design now prevents the mirror from lying to the client.
* After some discussions with others at PETS, I have split my software into 
four separate repositories and four different packages: tor-onions-hs, 
tor-onions-client, tor-onions-server, and tor-onions-common. The first three 
now have a very focused responsibility and have dependencies on the -common 
package, a shared library that handles configuration parsing, talking to Tor, 
and other generic tasks. This also means that hidden service operators need 
only install the -hs package, which reduces the amount of code running on their 
protected server.
* I have organized all the tickets on Github into their respective repository 
and assigned most of them to milestones to indicate how soon I will be tackling 
them.
* I have also successfully integrated the software into the Tor Browser such 
that when the Tor Browser starts, Tor and the OnioNS software launch behind the 
scenes and in the correct order. My modification is a binary substitution 
rather than recompiling the Tor Launcher, but the result appears to be reliable 
and greatly simplifies the client end of things.
* In the last status report, I discussed work on logging. I have made 
significant progress on this task, which is now a critical item because the 
software now runs in the background when launched from the Tor Browser, so 
normal stdout is not seen. The software logs to /Browser/TorBrowser/Data/OnioNS/
* I saw DonnchaC's alpha release. I am really working on making a prototype 
that everyone can beta test. The packaging and integration into the Tor Browser 
should make this very straightforward, but I need to have all the 
configurations in place and a few more bugs worked out before then.

Jesse V.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBCAAGBQJVnnvTAAoJEK2XNk/CC+yATgQH/RSG1rNzUIF9pkyPQFl0YYHP
fbor9zzdRXeHIADrnnn4trg4epGW43SCLJ2bpFiI7/keYTe6FFABE8j0W0mB8RbQ
cIERbDmfGFBgrPrx0sPxMHj99637sF2j3igIxdln5rtqbvOuXLrgI3F+a6fWdCmr
6GFgTaurGexrCI5ybvqcaMz6p2/eRDuTl+k51gz6cWPzV7mzdCzzU9Gl1miqpS6M
UB/RsjMwgGJDpcS/b0hlIXU6Zcsc1Kk3pP+czj99JsychHEUHZFSNB5qsVsDDCHq
h/BS44O/v+x2aJg1ZwL6hn02ghn0HE9hapIglERQFLxZ/pQvTsVJzUL2gaL5L8I=
=BC+c
-END PGP SIGNATURE-


___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] tor#16518: Read-Only Filesystem Error opening tor lockfile in 0.2.6.9 but not 0.2.5.12

2015-07-09 Thread aexlfowley 
> On Tue, 07 Jul 2015, aexlfowley at web.de wrote:
> 
>> After upgrading from 0.2.5.12 (git-3731dd5c3071dcba) to 0.2.6.9
>> (git-145b2587d1269af4) an error occured.
>> I'm on Debian Jessie (stable) on an AMD Athlon 64 X2. Tor won't start
>> and these are the last lines in log:
>> [warn] Couldn't open "/media/cRAID/Tor/lock" for locking: Read-only file
>> system
> 
>> teor thinks that I "could be experiencing an issue with the tor sandbox
>> and not getting the right paths
>> or, tor is running with insufficient permissions"
> 
> I'd assume that's the protection settings enabled in Tor's service file.
> 
> See /lib/systemd/system/tor.service and the systemd.exec(5) manpage.
> You can override these by making your own
> /etc/systemd/system/tor.service file.
> 
> Cheers,
> -- 
>|  .''`.   ** Debian **
>   Peter Palfrader  | : :' :  The  universal
>  http://www.palfrader.org/ | `. `'  Operating System
>|   `-http://www.debian.org/

> aexlfowley at web.de wrote (08 Jul 2015 17:57:24 GMT) :
>> (Both packages for 0.2.5.12 and 0.2.6.9 contain an apparmor profile.
>> Only change and new line is
>>   /usr/bin/obfs4proxy PUx,
>> in /etc/apparmor.d/abstracions/tor)
> 
> FTR, the systemd unit file in Debian sid's 0.2.6.9-1 doesn't enable
> the AppArmor profile (yet), so I doubt AppArmor has anything to do
> with this problem (aa-status will tell you).
> 
> However, it has:
> 
>   PrivateTmp=yes
>   PrivateDevices=yes
>   ProtectHome=yes
>   ProtectSystem=full
>   ReadOnlyDirectories=/
>   ReadWriteDirectories=-/var/lib/tor
>   ReadWriteDirectories=-/var/log/tor
>   ReadWriteDirectories=-/var/run
> 
> ... which explains why /media/cRAID/Tor/lock isn't writable.
> 
> So you'll want to add what is called a "drop-in override file" in
> systemd's terminology (that can be created e.g. with `systemctl
> edit'), that adds a ReadWriteDirectories= directive pointing to the
> directory you want.
> 
> Cheers,
> --
> intrigeri

Correct. I edited /lib/systemd/system/tor.service and added
  ReadWriteDirectories=-/media/cRAID/Tor
and now 0.2.6.9 is running.
I'm not entirely sure how to create my own
/etc/systemd/system/tor.service so I leave it at that.
(Trying out 'systemctl edit' I get "Unknown operation 'edit'." BTW.)

Thank you all!
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] CollecTor data: mapping bridge-network-status to bridge-server-descriptor to bridge-extra-info

2015-07-09 Thread Karsten Loesing 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/07/15 05:39, Roger Dingledine wrote:
> On Wed, Jul 08, 2015 at 07:45:04PM -0700, David Fifield wrote:
>> I'm trying to use CollecTor data to find out how much bandwidth
>> is offered by different pluggable transports over time. I.e., I
>> want to be able to say something like, "On July 1, bridges with
>> obfs3 offered X MB/s, bridges with obfs4 offered Y MB/s," etc.
> 
> Great!
> 
>> I'm having trouble because sometimes, a router digest listed in
>> a bridge-network-status document is not found in the same
>> tarball.
> [snip]
>> Here's an example of where it goes wrong. 
>> bridge-descriptors-2015-07/statuses/01/20150701-060138-4A0CCD2DDC7995083D73F5D667100C8A5831F16D
>
>> 
> Yeah, I'm not surprised it goes wrong, since the descriptor from 
> 0701-06:01 was likely published in the previous month.
> 
>> However, I did find it in the previous month's tarball,
> 
> Yep.

I think you picked the wrong example for something going wrong,
because that descriptor is actually included in the 2015-07 tarball.

But there are indeed cases when a status published in 2015-07
references a server descriptor that was published in 2015-06, and that
server descriptor would be contained in the 2015-06 tarball.  Example
from the same status:

bridge-descriptors-2015-07/statuses/01/20150701-060138-4A0CCD2DDC7995083D73F5D667100C8A5831F16D

contains a line:

r Unnamed ABQ4ZADwj8WkfgApkhVTFalGweU GqjwHG/sFpFzY4sx9SWuzVTcHag
2015-06-30 12:59:03 10.135.171.161 443 0

which references the following server descriptor:

bridge-descriptors-2015-06/server-descriptors/1/a/1aa8f01c6fec169173638b31f525aecd54dc1da8

>> It seems rare that the bridge-server-descriptor is missing. In
>> the 2015-07 tarball, it happened for 5891/477496 relays (1.2%).
> [snip]
>> How do you handle cases like this? I had a browse through the
>> Onionoo source code, but did not quickly understand it.

Onionoo typically reads descriptors from CollecTor's recent/ directory
which have been published in the past 72 hours, not the tarballs in
the archive/ directory that are organized by publication month.

>> Should I just always include the month preceding the earliest
>> month I want to process?

Yes, you should do that.

> How many of the 5891 cases does that resolve?

If you happen to find cases which are not explained by that, please
let me know.

All the best,
Karsten

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJVnjBPAAoJEJD5dJfVqbCrfjYH/1kYG9hl10sekKpfhV7y3nAq
wjm/hhyz7bqz9uPJmXs9d8+rkgJBIhUGC+LWqdmmgU8VNRb4NpCq7vBO6MIRJQQG
a7C3XNYRw10+Bs+jfBiE5D6z4i2rLXGDqaFkmKCEbrh6To5pqo2ziJkWUP6Y/8gH
EHjsEINFB4doV2EAccAAAjN6L1cLQPLBEVVAPtN7Pm78hcNuZ9D+n8TA+XWfmOvV
JG26kerEMkA2XPj3nbPvBLTYM5AMvMr/lDQpAuaSZYHb0E8DiLcVlUcaX4Y/IpY8
SqwLmheZdrFItxCH3Fd8c3hxiZ/Qs6iVZ6EPFRuqbBSOu7VLvyo7N4aXrk2bt6c=
=OKle
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev