Re: [tor-relays] experiences with debian tor 0.2.8.6 package from deb.torproject.org

[tor relay]

> 
> On August 4, 2016 at 10:23 AM Peter Palfrader  
> wrote:
> 
> On Thu, 04 Aug 2016, tor relay wrote:
> 
> > > 
> > > > > 
> > > On August 3, 2016 at 11:51 PM Green Dream 
> > >  wrote:
> > > 
> > > Sorry, I didn't understand that your daemon didn't restart 
> > > after the upgrade. I ran through the upgrade on 2 relays, and apt started 
> > > the service post-upgrade on both.
> > > 
> > > > > 
> > Since it is reproducible in my case as well I assume you do _not_ 
> > have the following constellation:
> > 
> > tor.service is disabled and stopped (I don't use the default 
> > instance)
> > 
> > > 
> You should not disable tor.service.
> 
> tor.service is what controls all tor instances. The default service is
> tor@default.service. If you don't want it to start, one option is to
> move away /etc/tor/torrc.
> 

It is even more uncomfortable than I thought since logrotate daily reload 
causes all tor instances to stop if tor.service is disabled, this has certainly 
not been the case with 0.2.7.6.


Why this hack (disable a service by moving away its config) and not the more 
clean approach like the one take by the RPM maintainer?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] experiences with debian tor 0.2.8.6 package from deb.torproject.org

[tor relay]

> 
> Why this hack (disable a service by moving away its config) and not the 
> more clean approach like the one take by the RPM maintainer?
> 

 ..that allows one to manage (start/stop/enable/disable) each service 
separately using standard tools and methodologies (and not service specific 
ways like "if you want to disable it you have to move away its configuration 
file).

Simply moving away its configuration file will cause unnecessary logs since 
systemd will attempt to start tor.service every time:

Unable to open configuration file "/etc/tor/torrc".

[err] Reading config failed--see warnings above.

tor@default.service: control process exited, code=exited status=1
Failed to start Anonymizing overlay network for TCP.
Unit tor@default.service entered failed state.
tor@default.service start request repeated too quickly, refusing to start.
Failed to start Anonymizing overlay network for TCP.
Unit tor@default.service entered failed state.


If one monitors log for [err] log level events this isn't nice.


Also: you can not start/stop/restart tor.service separately without leaving all 
other tor instances untouched.


Please consider the RPM maintainer's approach, thank you!
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] experiences with debian tor 0.2.8.6 package from deb.torproject.org

[Peter Palfrader]

On Fri, 05 Aug 2016, tor relay wrote:

> Also: you can not start/stop/restart tor.service separately without leaving 
> all other tor instances untouched.

tor.service is *not* the default service.  tor.service is the collection
of all service instances.

HAND.
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] experiences with debian tor 0.2.8.6 package from deb.torproject.org

[Peter Palfrader]

On Fri, 05 Aug 2016, tor relay wrote:

> this has certainly not been the case with 0.2.7.6.

You are mistaken.  Nothing in that regard has changed for 0.2.8.x

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] experiences with debian tor 0.2.8.6 package from deb.torproject.org

[tor relay]

> On August 5, 2016 at 1:24 PM Peter Palfrader  wrote:
> 
> 
> On Fri, 05 Aug 2016, tor relay wrote:
> 
> > Also: you can not start/stop/restart tor.service separately without leaving 
> > all other tor instances untouched.
> 
> tor.service is *not* the default service.  tor.service is the collection
> of all service instances.


Gosh, you are right there is tor@default.service, so you are actually already 
doing what is being done in RPMs and there is no need to move away 
/etc/tor/torrc at all :)
(why didn't you mention that ;).
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] experiences with debian tor 0.2.8.6 package from deb.torproject.org

[Peter Palfrader]

On Fri, 05 Aug 2016, tor relay wrote:

> 
> > On August 5, 2016 at 1:24 PM Peter Palfrader  wrote:
> > 
> > 
> > On Fri, 05 Aug 2016, tor relay wrote:
> > 
> > > Also: you can not start/stop/restart tor.service separately without 
> > > leaving all other tor instances untouched.
> > 
> > tor.service is *not* the default service.  tor.service is the collection
> > of all service instances.
> 
> 
> Gosh, you are right there is tor@default.service, so you are actually already 
> doing what is being done in RPMs and there is no need to move away 
> /etc/tor/torrc at all :)
> (why didn't you mention that ;).

I said moving it away is *one* option.

The generator will then not cause tor.service to start the default
instance, so after a daemon-reload, systemd should not even attempt to
start the default instance.

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] tor-relays Digest, Vol 67, Issue 12

[Flipchan]

I would recommend port knocking if u run ssh

tor-relays-requ...@lists.torproject.org skrev: (4 augusti 2016 19:30:11 CEST)
>Send tor-relays mailing list submissions to
>   tor-relays@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-requ...@lists.torproject.org
>
>You can reach the person managing the list at
>   tor-relays-ow...@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: tor-relays Digest, Vol 67, Issue 11 (Flipchan)
>   2. Re: Exit relay funding (I)
>   3. Re: Exit relay funding (Petrusko)
>   4. Re: Any security tips on running a TOR relay? (Green Dream)
>   5. Re: Any security tips on running a TOR relay? (Tristan)
>
>
>--
>
>Message: 1
>Date: Thu, 04 Aug 2016 14:51:35 +0200
>From: Flipchan 
>To: tor-relays@lists.torproject.org
>Subject: Re: [tor-relays] tor-relays Digest, Vol 67, Issue 11
>Message-ID: 
>Content-Type: text/plain; charset="utf-8"
>
>Auto update with cron, audit it like a normal server
>
>tor-relays-requ...@lists.torproject.org skrev: (4 augusti 2016 14:00:07
>CEST)
>>Send tor-relays mailing list submissions to
>>  tor-relays@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-requ...@lists.torproject.org
>>
>>You can reach the person managing the list at
>>  tor-relays-ow...@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: experiences with debian tor 0.2.8.6 package from
>>  deb.torproject.org (tor relay)
>>   2. Any  security tips on running a TOR relay? (Andrew)
>>   3. Re: Exit relay funding (Petrusko)
>>   4. Re: experiences with debian tor 0.2.8.6 package from
>>  deb.torproject.org (Peter Palfrader)
>>
>>
>>--
>>
>>Message: 1
>>Date: Thu, 4 Aug 2016 08:01:32 +0200 (CEST)
>>From: tor relay 
>>To: tor-relays@lists.torproject.org
>>Subject: Re: [tor-relays] experiences with debian tor 0.2.8.6 package
>>  from deb.torproject.org
>>Message-ID: <249633305.6901.1470290492...@office.mailbox.org>
>>Content-Type: text/plain; charset="utf-8"
>>
>>https://trac.torproject.org/projects/tor/ticket/19825
>>-- next part --
>>An HTML attachment was scrubbed...
>>URL:
>>
>>
>>--
>>
>>Message: 2
>>Date: Thu, 4 Aug 2016 16:00:30 +1000
>>From: "Andrew" 
>>To: 
>>Subject: [tor-relays] Any  security tips on running a TOR relay?
>>Message-ID: <021f01d1ee15$831ee920$895cbb60$@ab49k.net>
>>Content-Type: text/plain; charset="utf-8"
>>
>>Hi,
>>
>>I've got a spare server for two (freebsd) and I'd like to start
>running
>>TOR
>>relays on them.
>>
>>Is there any security concerns I need to deal with, or is the ports
>>compile
>>+ updates good enough to keep my systems decently secure.
>>
>>I actively monitor the machines, but as you know, the game is
>>prevention,
>>not reaction to security incedents :)
>>
>> 
>>
>>Thanks,
>>
>>AB49K
>>
>> 
>>
>> 
>>
>>-- next part --
>>An HTML attachment was scrubbed...
>>URL:
>>
>>
>>--
>>
>>Message: 3
>>Date: Thu, 4 Aug 2016 09:10:08 +0200
>>From: Petrusko 
>>To: tor-relays@lists.torproject.org
>>Subject: Re: [tor-relays] Exit relay funding
>>Message-ID: <62c913f4-3df8-8622-42a0-1881c4849...@riseup.net>
>>Content-Type: text/plain; charset="windows-1252"
>>
>>And I think a lot of users doesn't know what is there "behind". As
>>always in computer's world...
>>
>>Now I'm able to explain quickly (what I've understood) this network to
>>some friends/family, who were using Tor a long time ago before I've
>>started to have fun with contributing a little to the network.
>>
>>How many people around us know how 'it's working", how many are
>>thinking
>>about that, are interested to know ?
>>They are connecting the smartphone to Mc Do's wifi, and are happy to
>>read Facebook... receive emails... etc. But how it's possible to make
>>it
>>work ? They don't care about that, /"it's working and it's cool !"/
>>They don't know what is a NAS at their work, what is an IP, what is
>>domain with AD, why those IT guys are sooo boring with those passwords
>>(they don't love our pet's name as password... rah!!).
>>Now 

Re: [tor-relays] Syslog: Kernel TCP: Too many orphaned sockets

[Christian Pietsch]

The exit relay we (Digitalcourage) run gets this warning a lot, but it started 
only recently. I guess it is related to the DDoS attacks (syn flood) we get 
lately.

Debian seems to set /proc/sys/net/ipv4/tcp_max_orphans automatically so that up 
to a quarter of the installed amount of RAM is used for this.
(“Let me remind you again: each orphan eats up to 64K of unswappable memory” – 
https://serverfault.com/questions/624911/what-does-tcp-too-many-orphaned-sockets-mean)

So 262,144 value in Torservers' config will eat up to 16 GiB. I am not sure if 
overriding Debian's setting is a good idea. Any advice? Is this warning more 
than an annoyance?

Cheers,
Christian


On Mon, Aug 01, 2016 at 09:12:12PM -0500, Tristan wrote:
> My default setting was 2048. I changed it to 200,000 for now. I haven't
> really played with sysctl at all. The only change I've ever made in there
> was for swappiness.
> 
> On Mon, Aug 1, 2016 at 8:04 PM, Green Dream  wrote:
> 
> > It's related to /proc/sys/net/ipv4/tcp_max_orphans
> >
> > "Maximal number of TCP sockets not attached to any user file handle, held
> > by system. If this number is exceeded orphaned connections are reset
> > immediately and warning is printed."
> >
> > So, I'd start by checking the value of tcp_max_orphans (with "cat
> > /proc/sys/net/ipv4/tcp_max_orphans"). The widely distributed sysctl.conf
> > tweaks for Linux relays suggests a value of 262144. I think the default in
> > many distros may be 4096, perhaps too low for an Exit.
> >
> > Some references:
> >
> >
> > https://serverfault.com/questions/624911/what-does-tcp-too-many-orphaned-sockets-mean
> >
> > https://raw.githubusercontent.com/torservers/server-config-templates/master/sysctl.conf
> >
> > If you need help making the sysctl tweaks let me know.
> >
> >
> > ___
> > tor-relays mailing list
> > tor-relays@lists.torproject.org
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> >
> >
> 
> 


-- 
  Digitalcourage e.V., Marktstr. 18, D-33602 Bielefeld, Germany
  Tel: +49-521-1639 1639 | Fax: +49-521-61172 | m...@digitalcourage.de
  https://digitalcourage.de | https://bigbrotherawards.de

Vorratsdatenspeicherung? Nicht schon wieder! Unterstützen Sie
unsere Verfassungsbeschwerde: https://digitalcourage.de/weg-mit-vds


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

Re: [tor-relays] Syslog: Kernel TCP: Too many orphaned sockets

[Tristan]

Well, since changing the setting from 2048 to 200,000, my exit is still
running fine, and I'm not seeing a drastic increase in RAM usage.

You said each orphan can use up to 64K of memory. Maybe "up to" is the
magic phrase?

On Aug 5, 2016 10:42 AM, "Christian Pietsch" <
christian.piet...@digitalcourage.de> wrote:

> The exit relay we (Digitalcourage) run gets this warning a lot, but it
> started only recently. I guess it is related to the DDoS attacks (syn
> flood) we get lately.
>
> Debian seems to set /proc/sys/net/ipv4/tcp_max_orphans automatically so
> that up to a quarter of the installed amount of RAM is used for this.
> (“Let me remind you again: each orphan eats up to 64K of unswappable
> memory” – https://serverfault.com/questions/624911/what-does-
> tcp-too-many-orphaned-sockets-mean)
>
> So 262,144 value in Torservers' config will eat up to 16 GiB. I am not
> sure if overriding Debian's setting is a good idea. Any advice? Is this
> warning more than an annoyance?
>
> Cheers,
> Christian
>
>
> On Mon, Aug 01, 2016 at 09:12:12PM -0500, Tristan wrote:
> > My default setting was 2048. I changed it to 200,000 for now. I haven't
> > really played with sysctl at all. The only change I've ever made in there
> > was for swappiness.
> >
> > On Mon, Aug 1, 2016 at 8:04 PM, Green Dream 
> wrote:
> >
> > > It's related to /proc/sys/net/ipv4/tcp_max_orphans
> > >
> > > "Maximal number of TCP sockets not attached to any user file handle,
> held
> > > by system. If this number is exceeded orphaned connections are reset
> > > immediately and warning is printed."
> > >
> > > So, I'd start by checking the value of tcp_max_orphans (with "cat
> > > /proc/sys/net/ipv4/tcp_max_orphans"). The widely distributed
> sysctl.conf
> > > tweaks for Linux relays suggests a value of 262144. I think the
> default in
> > > many distros may be 4096, perhaps too low for an Exit.
> > >
> > > Some references:
> > >
> > >
> > > https://serverfault.com/questions/624911/what-does-
> tcp-too-many-orphaned-sockets-mean
> > >
> > > https://raw.githubusercontent.com/torservers/server-config-
> templates/master/sysctl.conf
> > >
> > > If you need help making the sysctl tweaks let me know.
> > >
> > >
> > > ___
> > > tor-relays mailing list
> > > tor-relays@lists.torproject.org
> > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> > >
> > >
> >
> >
>
>
> --
>   Digitalcourage e.V., Marktstr. 18, D-33602 Bielefeld, Germany
>   Tel: +49-521-1639 1639 | Fax: +49-521-61172 | m...@digitalcourage.de
>   https://digitalcourage.de | https://bigbrotherawards.de
>
> Vorratsdatenspeicherung? Nicht schon wieder! Unterstützen Sie
> unsere Verfassungsbeschwerde: https://digitalcourage.de/weg-mit-vds
>
> ___
> 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] Got a visit from the police this morning..

[Cristian Consonni]

2016-08-01 8:15 GMT+02:00 stig atle steffensen :
> I decided today to turn the node into a non-exit node this morning.
> The stress of not knowing if something will happen again is too much for me
> to go around thinking about.
>
> I will rather donate some to torproject or other exit operators.

2016-08-01 8:49 GMT+02:00 Marco Predicatori :
> Too bad when a Tor node operator is intimidated out of his activity.
> I understand your position, thank you for your efforts.

+1.
Even if it seems to me that they handled the situation in a civilised
manner, I can understand it is still a very stressful situation.

Thanks again for running an exit node and continuing with a relay.

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

Re: [tor-relays] experiences with debian tor 0.2.8.6 package from deb.torproject.org

[tor relay]

> > > > Also: you can not start/stop/restart tor.service separately without 
> > > > leaving all other tor instances untouched.
> > > 
> > > tor.service is *not* the default service.  tor.service is the collection
> > > of all service instances.
> > 
> > 
> > Gosh, you are right there is tor@default.service, so you are actually 
> > already doing what is being done in RPMs and there is no need to move away 
> > /etc/tor/torrc at all :)
> > (why didn't you mention that ;).

Ok, I wrote that before actually trying to disable the default instance via
systemctl disable tor@default

This does not work. I fail to disable tor@default without disabling tor.service.
After a reboot it is back and running. 

I noticed that this service is special since it says "static" instead of 
"enabled" or "disabled" on other services:

systemctl status tor@default
● tor@default.service - Anonymizing overlay network for TCP
   Loaded: loaded (/lib/systemd/system/tor@default.service; static)

So there is no way to disable the default instance using systemctl after all?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] experiences with debian tor 0.2.8.6 package from deb.torproject.org

[Michael Armbruster]

Am 05.08.2016 um 18:27 schrieb tor relay:
> Also: you can not start/stop/restart tor.service separately without 
> leaving all other tor instances untouched.

 tor.service is *not* the default service.  tor.service is the collection
 of all service instances.
>>>
>>>
>>> Gosh, you are right there is tor@default.service, so you are actually 
>>> already doing what is being done in RPMs and there is no need to move away 
>>> /etc/tor/torrc at all :)
>>> (why didn't you mention that ;).
> 
> Ok, I wrote that before actually trying to disable the default instance via
> systemctl disable tor@default
> 
> This does not work. I fail to disable tor@default without disabling 
> tor.service.
> After a reboot it is back and running. 
> 
> I noticed that this service is special since it says "static" instead of 
> "enabled" or "disabled" on other services:
> 
> systemctl status tor@default
> ● tor@default.service - Anonymizing overlay network for TCP
>Loaded: loaded (/lib/systemd/system/tor@default.service; static)
> 
> So there is no way to disable the default instance using systemctl after all?
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 

I really don't understand the problem here... Why don't you just move
one of your multi-instances to the default instance?
Then you have the tor@default.service and the tor@whatever.service and
you are good to go with whatever you wanted to achieve.

Best,
Michael



signature.asc
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] experiences with debian tor 0.2.8.6 package from deb.torproject.org

[tor relay]

> So there is no way to disable the default instance using systemctl after all?

To answer my own question:
systemctl mask tor@default
disables the default instance for real.

..but I'm still curious why tor@default is a static unit (without [Install] 
section)
https://bbs.archlinux.org/viewtopic.php?id=147964
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] experiences with debian tor 0.2.8.6 package from deb.torproject.org

[tor relay]

made a ticket:
https://trac.torproject.org/projects/tor/ticket/19847
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] debian: log messages when upgrading tor package

[tor relay]

When upgrading the tor package on debian I get the following syslog messages:


systemd[1]: Failed to reset devices.list on /system.slice: Invalid argument
systemd[1]: Failed to reset devices.list on /system.slice/system-tor.slice: 
Invalid argument


Should I be concerned?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] running a relay on a pi/pi2 and it stopped working after upgrading to 0.2.8.6/0.2.8.6-2 ? read this (bugfix)

[Hack-Tic]

Hi,

I ran into some tor restart loop issues after upgrading to 0.2.8.6 on my 
pi2 relay.


In short, it takes too long to read router_parse_list_from_string and 
hits the systemd start timeout limit causing a restart (and loop)


Full story in the ticket here:
https://trac.torproject.org/projects/tor/ticket/19819

quick fix:

edit /lib/systemd/system/tor@default.service and change TimeoutStartSec= 
from 120 to 300


Hope i'm not "spamming" the list, just trying to help.

Have a good one.


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

Re: [tor-relays] running a relay on a pi/pi2 and it stopped working after upgrading to 0.2.8.6/0.2.8.6-2 ? read this (bugfix)

[Jens Kubieziel]

* Hack-Tic schrieb am 2016-08-05 um 21:19 Uhr:
> edit /lib/systemd/system/tor@default.service and change TimeoutStartSec=

Please don't write in /lib. Better create a new file 
/etc/systemd/system/tor@default@default.service.d/override.conf
and add your change there. When you update Tor at some point, your
settings won't be overwritten with this method.

-- 
Jens Kubieziel   http://www.kubieziel.de
Bei den kurzen Erfahrungen, die ich mit Linux gemacht habe, ist mir immer
aufgefallen, dass Linux relativ bunt ist. Ich ziehe allerdings den gräulich/
schlichten Stil von Windows 2000 vor...lässt sich sowas machen, oder muss man
mit dem bunten Linux leben?  Pascal König in <37u3spf5g8ht...@individual.net>


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

Re: [tor-relays] running a relay on a pi/pi2 and it stopped working after upgrading to 0.2.8.6/0.2.8.6-2 ? read this (bugfix)

[Peter Palfrader]

On Fri, 05 Aug 2016, Jens Kubieziel wrote:

> * Hack-Tic schrieb am 2016-08-05 um 21:19 Uhr:
> > edit /lib/systemd/system/tor@default.service and change TimeoutStartSec=
> 
> Please don't write in /lib. Better create a new file 
> /etc/systemd/system/tor@default@default.service.d/override.conf
> and add your change there. When you update Tor at some point, your
> settings won't be overwritten with this method.

I just changed git to raise it to 300 too.  So maybe this once changing
/lib was actually ok :)

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays