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>
next in thread | previous in thread | raw e-mail | index | archive | help
--sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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= =20 > >>mechanism... > >> > >>Other thoughts would be having a local stats aggregation server that=20 > >>pushes summaries up to the master server... the aggregation server keep= s=20 > >>the individual details, and some sort of challenge mechanism could be= =20 > >>randomly selected by the master server to reduce the ease with which th= e=20 > >>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. >=20 > The version 3 update did away with the storing of hostnames and IP=20 > addresses on the server side, as well as the submission of them by the=20 > client. So you're only exposing the public Internet address of the=20 > system during the submission of data, which is not stored in the database. >=20 > The client "push" mechanism would have to know how to handle any=20 > challenges it received from the server and submit the appropriate respons= e. >=20 > Perhaps a new port, sysutils/bsdstats-relay/, could allow easy=20 > installation of some sort of aggregation server... but then you have the= =20 > issue of requiring things like a web server, some form of database, etc= =20 > -- vs the simple nature of the client itself that is just a shell script.= =2E. 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 --sdtB3X0nJg68CQEu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE86oEXY6L6fI4GtQRAi9bAJsE1hZEBzSY1MLNUgcDd+z1+RdXugCfQp3y PozKKAs2KbEguKw9+Uk2aPk= =W2Rs -----END PGP SIGNATURE----- --sdtB3X0nJg68CQEu--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060829024420.GA7169>