tor-ramdisk 20101011 released for i686 only

Damian Johnson atagar1 at gmail.com
Tue Oct 12 15:04:57 UTC 2010


One option for providing feedback on the health of the relay would be arm (
www.atagar.com/arm) with the following config changes to keep with the aims
of tor-ramdisk:
# would prevent any connection related information from being queried
startup.blindModeEnabled true

# crops log messages after a day
features.log.entryDuration 1

This would provide the user with:
- ps information (cpu/mem usage, uptime)
- basic relay information (fingerprint, flags held, version, etc)
- config (currently loaded torrc)
- the last day's worth of logs
- graph of the bandwidth usage

The last two give a very good indication for if the relay's working right or
not. If this is too much information then I'd be happy to augment arm to
meet your needs. Cheers! -Damian

On Mon, Oct 11, 2010 at 8:25 PM, Anders Andersson <pipatron at gmail.com>wrote:

> On Mon, Oct 11, 2010 at 11:16 PM, Jacob Appelbaum <jacob at appelbaum.net>
> wrote:
> > On 10/11/2010 10:52 AM, Anthony G. Basile wrote:
> >>
> >> Hi everyone
> >>
> >> I want to announce to the list that a new release of tor-ramdisk is out.
> >> Tor-ramdisk is an i686, x86_64 or MIPS uClibc-based micro Linux
> >> distribution whose only purpose is to host a Tor server in an
> >> environment that maximizes security and privacy. Security is enhenced by
> >> hardening the kernel and binaries, and privacy is enhanced by forcing
> >> logging to be off at all levels so that even the Tor operator only has
> >> access to minimal information. Finally, since everything runs in
> >> ephemeral memory, no information survives a reboot, except for the Tor
> >> configuration file and the private RSA key, which may be
> >> exported/imported by FTP.
> >>
> >
> > Via FTP? It's probably not a good idea to export a private key without
> > using encryption...
> >
> > All the best,
> > Jake
>
> My first thought as well. Pretty much every protocol invented is
> better than FTP, in this case and most other cases.
>
> Another question regarding the logging: I hope you include enough to
> know if the node is working correctly or not. The logs that are
> generated could also be deleted after a couple of minutes or an hour
> as well, which might make it possible to log some more information if
> necessary to verify functionality.
>
> Great project though, a lot of people request this.
> ***********************************************************************
> To unsubscribe, send an e-mail to majordomo at torproject.org with
> unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20101012/13482f84/attachment.htm>


More information about the tor-talk mailing list