Date: Mon, 28 Aug 2006 21:44:20 -0500 From: Brooks Davis <brooks@one-eyed-alien.net> To: Antony Mawer <fbsd-arch@mawer.org> Cc: Max Laier <max@love2party.net>, "Marc G. Fournier" <scrappy@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: BSDStats - What is involved ... ? Message-ID: <20060829024420.GA7169@lor.one-eyed-alien.net> In-Reply-To: <44F3A44C.8050401@mawer.org> 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> <44F3A44C.8050401@mawer.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On Tue, Aug 29, 2006 at 12:19:56PM +1000, Antony Mawer wrote: > 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... That wouldn't be a big deal. We've got lots of B(L)AMP applications running and plenty of FreeBSD servers to run them on. That might be an option for me. -- Brooks [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE86oEXY6L6fI4GtQRAi9bAJsE1hZEBzSY1MLNUgcDd+z1+RdXugCfQp3y PozKKAs2KbEguKw9+Uk2aPk= =W2Rs -----END PGP SIGNATURE-----help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060829024420.GA7169>