headers
SK | 4 Feb 2005 14:40
Picon

Re: And nirvana is back

mysticmayhem is also back (for now) with 0.0.9.4 version and reject
for everything except 80 and 443.

On Thu, 3 Feb 2005 17:21:17 -0500, Michael Laccetti [c]
<michael <at> s2g-limited.com> wrote:
> Well, new month, newly compiled 1.0-alpha version, and some handy new rejection
> policies.  :)  Let's see how things go from here.
Permalink | Reply | 0 comments |
headers
Aaron Cannon | 4 Feb 2005 18:23

RE: questions of morality


Thanks again to everyone who answered my concerns.  My server (blackbox) is 
now up and running.

Sincerely
Aaron Cannon

--
E-mail: cannona <at> fireantproductions.com
Skype: cannona
MSN Messenger: cannona <at> hotmail.com (Do not send E-mail to the hotmail address.)
Permalink | Reply | 6 comments |
headers
admin | 4 Feb 2005 19:56

Tor service monitoring util available?

Having run a tor server for a short while, I find myself in
want of a simple monitoring/stats utility that would show me
the status of the service at my local node. Ideally it would:

- Monitor the service and report problems via email a/o beeper
- Give local statistics: Connections, bandwidth, exit requests,
	tunnel requests, etc, etc. Including ports (to see for
	example, who hogs the service and such).
- Total bandwidth, cpu, memory usage versus other local usage.
- Bandwidth and latency for nodes entering a/o exiting through
	the local node.
- Have a web access so all monitoring and control can be used
	from a remote location.

I am sure there must be other relevant stats. As tor, at the end
of the day, behaves as a virtual net maybe it would be possible
to add snmp service to it so traditional (and available) net
monitoring tools could be used. 

Does such a thing exist?
Permalink | Reply | 5 comments |
headers
Andre Eisenbach | 4 Feb 2005 20:57

Re: Tor service monitoring util available?


On Fri, 4 Feb 2005, admin wrote:

>
> Does such a thing exist?
>

Most of the things you've described can be done with existing tools like 
MRTG, or RRDTOOL. Especially the Tor unrelated things (CPU usage etc) can 
be done with existing monitoring tools. Tor can be easily integrated into 
MRTG etc. to add the Tor specific information.

Having said that, I did write a small windows application which uses the 
Tor control protocol to monitor the bandwith on the Tor server, and it 
could be easily expanded to provide more information. I just need to 
find the time :D.

I've also toyed with the idea of providing a PHP interface which can be 
used to make a server monitoring web site.

I'll post stuff as I get around to it...

Cheers,
    Andre
Permalink | Reply | 4 comments |
headers
ssc | 4 Feb 2005 23:11

systrace policy

Hi folks.

I've written a basic systrace(1) policy for tor nodes logging to syslog.
It was tested under OpenBSD 3.8/x86 with tor .9.2 and .9.4.

http://www.thinknerd.org/~ssc/wiki/doku.php?id=systrace_tor

I'm looking forward to get comments, suggestions and uh flames :)

--

-- 
Ewige Blumenkraft!         )|( ssc                    www.unix-geek.info
                               Stephan Schmieder             ssc <at> h07.org

safeguard this letter, it may be an IMPORTANT DOCUMENT
Permalink | Reply | 1 comment |
headers
Matthias Fischmann | 4 Feb 2005 23:48
Picon
Favicon

bug report


hei all,

(this is a repost of an earlier note from or-dev.  nice people just
took my hand and helped me to find the core on my machine, so here is
the complete bug report.)

i am using the 0.0.9.4 debian package, i am running on a pretty old
but sufficient one-cpu x86 pc and have a jap mix running on the same
box which connects to apache/mod_proxy (does anybody know, btw, a good
lean web proxy that scares one less than squid?), which in turn
connects to tor.

a few hours after the first start, the logfile reads:

Feb 04 15:56:41.397 [err] assert_cpath_layer_ok(): Unexpected state 191
Feb 04 15:56:41.397 [err] circuitlist.c:426: assert_cpath_layer_ok: Assertion 0 failed; aborting.

gdb/bt:

#0  0x40148741 in kill () from /lib/libc.so.6
#1  0x401484c5 in raise () from /lib/libc.so.6
#2  0x40149a08 in abort () from /lib/libc.so.6
#3  0x08051ffd in assert_cpath_layer_ok (cp=0x8492578) at circuitlist.c:426
#4  0x0805ca01 in assert_connection_ok (conn=0x8cd2f98, now=1107529001) at connection.c:1484
#5  0x0806cd74 in conn_close_if_marked (i=265) at main.c:332
#6  0x0806dc8c in do_main_loop () at main.c:926
#7  0x0806e535 in tor_main (argc=1, argv=0xbffffe34) at main.c:1426
#8  0x0807e4f4 in main (argc=1, argv=0xbffffe34) at tor_main.c:18
(Continue reading)

Permalink | Reply | 0 comments |
headers
ssc | 5 Feb 2005 00:11

another policy, privoxy this time

Hello again.

I was bored and so I've just written another basic systrace policy.
This one is for privoxy and was tested with privoxy v3.0.3 on OpenBSD 3.6/x86.
Others may work too.

http://www.thinknerd.org/~ssc/wiki/doku.php?id=systrace_privoxy

Comments, questions and flames ware welcome.

--

-- 
Ewige Blumenkraft!         )|( ssc                    www.unix-geek.info
                               Stephan Schmieder             ssc <at> h07.org

safeguard this letter, it may be an IMPORTANT DOCUMENT
Permalink | Reply | 0 comments |
headers
admin | 5 Feb 2005 05:53

RE: Tor service monitoring util available?

Right you are, they CAN be done. But, having done such a thing
before myself, it surprises they are not part of the TOR package.
Splicing, bit by bit, the different routines/scripts/etc can be
a pain for such things as tunneling software. Tor is a net of
its own, the nodes are just routers. The problem is the monitoring
tools we have behave at a different layer. Like trying to track
web stats with a packet counter. I believe that this should be part
of the Tor effort. I shudder when I say things like this on an
open-source-related forum, I see someone saying "so,... write them
yourself!" Sorry, no skill, no time; mind rusting on all edges.
Just experience talking.

So, is there such a thing??? Hey, TOR folk! You must have some
gamma, beta, utils out there to see how your brainchild is doing.
Something better than a birds eye, macro, view. If nothing else,
for curiosity's sake.

> -----Original Message-----
> From: owner-or-talk <at> freehaven.net 
> [mailto:owner-or-talk <at> freehaven.net] On Behalf Of Andre Eisenbach
> Sent: Friday, February 04, 2005 11:57
> To: or-talk <at> freehaven.net
> Subject: Re: Tor service monitoring util available?
> 
> 
> 
> 
> On Fri, 4 Feb 2005, admin wrote:
> 
> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
admin | 5 Feb 2005 06:00

Solution to bandwidth prob...

So bandwidth hogging is really becoming a problem? The bandwidth
parameters do help, as does hibernation. But, many are willing to
give ALL the available bandwidth as long as it is not needed by
the local users. So why not do a iptables QOS example part of the
package. If we know the receiving (proxy) port and the process
owning the outgoing packets, this can be done. This would encourage
all to donate all available bandwidth to the tor net. Maybe it
should be re-baptized as a tor <at> home and join the seti crowd.

Can anyone share such a setup w me? Regards, -Manuel
Permalink | Reply | 1 comment |
headers
Valient Gough | 5 Feb 2005 10:15
Picon
Favicon

Re: Tor service monitoring util available?


Andre Eisenbach wrote:
>
>
> On Fri, 4 Feb 2005, admin wrote:
>
>>
>> Does such a thing exist?
>>
>
> Most of the things you've described can be done with existing tools 
> like MRTG, or RRDTOOL. Especially the Tor unrelated things (CPU usage 
> etc) can be done with existing monitoring tools. Tor can be easily 
> integrated into MRTG etc. to add the Tor specific information.
>
Munin (http://www.linpro.no/projects/munin/) is easy to extend to 
monitor all sorts of variables.  I monitor Tor bandwidth by having munin 
poll and summarize iptables output, as each server has its own iptable 
entry. 

For example, if you happened to be using firehol to setup firewall rules 
(http://firehol.sourceforge.net/), the following script could be placed 
in your munin plugin's directory in order to get a pretty graph of tor 
bandwidth.

regards,
Valient


(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  

  


  





    



Gmane