From owner-freebsd-arch@FreeBSD.ORG Tue Aug 29 02:20:57 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98DCC16A4DF; Tue, 29 Aug 2006 02:20:57 +0000 (UTC) (envelope-from fbsd-arch@mawer.org) Received: from mail-ihug.icp-qv1-irony4.iinet.net.au (ihug-mail.icp-qv1-irony4.iinet.net.au [203.59.1.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB46743D76; Tue, 29 Aug 2006 02:20:52 +0000 (GMT) (envelope-from fbsd-arch@mawer.org) Received: from 203-206-173-235.perm.iinet.net.au (HELO [127.0.0.1]) ([203.206.173.235]) by mail-ihug.icp-qv1-irony4.iinet.net.au with ESMTP; 29 Aug 2006 10:20:51 +0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,177,1154880000"; d="scan'208"; a="871623152:sNHT87786908" Message-ID: <44F3A44C.8050401@mawer.org> Date: Tue, 29 Aug 2006 12:19:56 +1000 From: Antony Mawer User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Brooks Davis References: <20060825233420.V82634@hub.org> <20060826112115.GG16768@turion.vk2pj.dyndns.org> <20060826132138.H82634@hub.org> <200608261848.16513.max@love2party.net> <20060826165209.V82634@hub.org> <20060828130247.GA77702@lor.one-eyed-alien.net> <20060828170450.M82634@hub.org> <44F39ACB.6090703@mawer.org> <20060829015306.GA6722@lor.one-eyed-alien.net> In-Reply-To: <20060829015306.GA6722@lor.one-eyed-alien.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Max Laier , "Marc G. Fournier" , freebsd-arch@freebsd.org Subject: Re: BSDStats - What is involved ... ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2006 02:20:57 -0000 On 29/08/2006 11:53 AM, Brooks Davis wrote: > On Tue, Aug 29, 2006 at 11:39:23AM +1000, Antony Mawer wrote: >> Perhaps aggregate submissions could be conducted using a registration >> mechanism... >> >> Other thoughts would be having a local stats aggregation server that >> pushes summaries up to the master server... the aggregation server keeps >> the individual details, and some sort of challenge mechanism could be >> randomly selected by the master server to reduce the ease with which the >> numbers can be 'faked'? > > I'd prefer not to expose host names or IP addresses, hardware > information and OS version aren't really a problem if they can't be > traced to a host name. The requirement to register an aggregation > server would be fine with me. A challenge mechanism would be tricky > because it would have to occur during a push to the central server since > connects back are not really possible. The version 3 update did away with the storing of hostnames and IP addresses on the server side, as well as the submission of them by the client. So you're only exposing the public Internet address of the system during the submission of data, which is not stored in the database. The client "push" mechanism would have to know how to handle any challenges it received from the server and submit the appropriate response. Perhaps a new port, sysutils/bsdstats-relay/, could allow easy installation of some sort of aggregation server... but then you have the issue of requiring things like a web server, some form of database, etc -- vs the simple nature of the client itself that is just a shell script... Marc -- I just noticed the client script still retrieves the hostname and stores it in a local variable, although it is never transmitted.