BSDStats - What is involved ... ?

Antony Mawer fbsd-arch at mawer.org
Tue Aug 29 02:20:57 UTC 2006


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.


More information about the freebsd-arch mailing list