Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 29 Aug 2006 12:19:56 +1000
From:      Antony Mawer <fbsd-arch@mawer.org>
To:        Brooks Davis <brooks@one-eyed-alien.net>
Cc:        Max Laier <max@love2party.net>, "Marc G. Fournier" <scrappy@freebsd.org>, freebsd-arch@freebsd.org
Subject:   Re: BSDStats - What is involved ... ?
Message-ID:  <44F3A44C.8050401@mawer.org>
In-Reply-To: <20060829015306.GA6722@lor.one-eyed-alien.net>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44F3A44C.8050401>