3.5 mb data segment for clients and location hidden services was Re: tor and Daemantools-0.76

[tor <tor@xxxxxxxxxxxxxxx>]

Hi Roger,  

Tor was crashing as a simple client binary not as a server, it was 
providing location hidden services for a VPN and when it went down it 
was quite noticeable, thus using Daemontools was an obvious answer, the 
-d3500000 was from djbdns experiments under OpenBSD :).

             I did double check the 3.5mb data segment for client and 
location hidden services , and lastcom|grep tor returns no re 
invocations of the tor binary. I am working DB conversion and Video 
services this week so I wont get a chance to try servers settings till I 
get back to my lab next week(most machines are off pending move of 
machine room). Chris can you play with this on your servers and 
determine what is goodness for the data segment in terms of size for a 
server ?



I have managed to use video surveillance(www.zoneminder.com) via a 
location hidden service.

ssh port 22

Apache port 80 works

apache 443 works

apache/squid(httpd accelerator)   non-tested

webmin non-ssl  10000 works

webmin-SSL port 10000 doesnt work


usermin port 20000 untested



   a tor operator
ps chris I dont seem to be getting core dumps for tor failures.. is 
there a special switch beyond login.conf. coredumpsize to set this??

     

tor wrote:

> Hi all,
>       the -d3500000 is perfectly acceptable for running as a hidden 
> service or client... I did say you needed to tune for your usage.
> I did NOT post a server example...  unfortunately tor on openbsd 
> current seems to just disappear and I have found neither core or 
> assert messages. I am currently working on a systrace version of 
> Daemontools, tor and privoxy for use as a server with settings 
> appropriate for that scenario.
>
> AS I use hidden services as a VPN for certain ssh/http servers this 
> seems to work.
>
> Servers I have also been experimenting with are on FreeBSD5.3, 
> OSX(Tiger and Panther), Debian-unstable as well as miscellaneous others.
>
>
> and just for you Roger
> a 100 second delay on restart:)
> ---cut here ---
> #!/bin/sh
> SLEEP=100
> sleep $SLEEP
> exec 2>&1
> exec envuidgid tor  envdir ./env softlimit -d3500000 /usr/bin/su tor 
> -c /usr/local/bin/tor
> ---cut here-
>
>
>
>
>
>     a tor operator

ps chris I dont seem to be getting core dumps for tor failures.. is 
there a special switch beyond login.conf.

> Roger Dingledine wrote:
>
> > On Fri, Jul 01, 2005 at 11:48:11AM -0700, tor wrote:
> >  
> >
> > >   as the current tor Alphas are somewhat unstable under OpenBSD AND 
> > > I DONT have the time to track down the instability I have elected to 
> > > put tor under DJ Bernsteins Daemontools to restart as needed.
> > >   
> >
> >
> > Do you get cores? Do you get assert failures? Please spend a few moments
> > to provide a bug report if you have any hints.
> >
> > Also, please please please put a sleep(100) in your script somewhere.
> > We had a bug a while ago where people would start their Tor, it would
> > suck down a directory, kill itself, restart, suck down another 
> > directory,
> > repeat. This was not good for our volunteer's bandwidth. :)
> >
> >  
> >
> > > ---cut here ---
> > > #!/bin/sh
> > > exec 2>&1
> > > exec envuidgid tor  envdir ./env softlimit -d3500000 /usr/bin/su tor 
> > > -c /usr/local/bin/tor
> > > ---cut here---
> > >
> > > the -d3500000 should probably be tuned for your usage
> > >   
> >
> >
> > Is your instability based on the fact that a 3.5MB data segment is
> > incredibly too small to run a Tor server? You want another one or two
> > orders of magnitude more than this.
> >
> > Thanks,
> > --Roger
> >