From owner-freebsd-ports-bugs@FreeBSD.ORG Wed Mar 22 21:10:22 2006 Return-Path: X-Original-To: freebsd-ports-bugs@hub.freebsd.org Delivered-To: freebsd-ports-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F3E816A41F for ; Wed, 22 Mar 2006 21:10:22 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06CF843D5F for ; Wed, 22 Mar 2006 21:10:22 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k2MLAL9r033843 for ; Wed, 22 Mar 2006 21:10:21 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k2MLALkV033842; Wed, 22 Mar 2006 21:10:21 GMT (envelope-from gnats) Date: Wed, 22 Mar 2006 21:10:21 GMT Message-Id: <200603222110.k2MLALkV033842@freefall.freebsd.org> To: freebsd-ports-bugs@FreeBSD.org From: Peter Thoenen Cc: Subject: Re: ports/94621: security/tor-devel defaults data directory to non-persistent X-BeenThere: freebsd-ports-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Peter Thoenen List-Id: Ports bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2006 21:10:22 -0000 The following reply was made to PR ports/94621; it has been noted by GNATS. From: Peter Thoenen To: bug-followup@FreeBSD.org Cc: wes@bogon.net Subject: Re: ports/94621: security/tor-devel defaults data directory to non-persistent Date: Wed, 22 Mar 2006 13:02:18 -0800 (PST) Well 1.1.16-blah came way faster than I expected but here is what I did after a rather lengthy (and disagreable) talk with the tor developers. 1) Documented tor_datadir in the rc.subr file as suggested by Wes. 2) Moved tor from /var/run to /var/db* * I really really don't like this solution though Arma beat it into my head the current solution is wrong also. The prob is, unlike lets say squid or postgres, they do not split their cache directory (nor any directive to do so) from their static content directory. This presents a problem in my eyes with hier(7). I don't like %%LOCALBASE%%/share as this should NOT be for temporary volatile files (e.g. tor's cache files). var/run is wrong as it is cleared on reboot and not only is the fingerprint file needed (and no way to move it) its best also not to wipe your server descriptors though not show stopper (just longer initial startup time). var/tmp is proper but I believe a lot of people "ln -s /tmp /var/tmp" and clear_tmp_enable would then cause the same prob as var/run in this case. I don't believe var/db is the correct place for this either but gets around the var/run and var/tmp issues while in theory satisfying hier(7). Another problem though is placing it ANYWHERE in var is problematic as some folk out there are really excited about putting /var on MFS and rebuilding after each reboot for some odd reason clearning everything as far as I can tell. The new solution works and should address this PR .. I just personally don't like it. I also don't have a better solution so would prefer to make it work (tm) than leave it broke while stonewalling over basically terminology and an intelligentsia problem. Thanks again Wes for pointing this out. NOTE See: http://www.freebsd.org/cgi/query-pr.cgi?pr=93692