From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on finch.gentoo.org X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=DMARC_NONE,FREEMAIL_FROM, MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=4.0.0 Received: from hotmail.com (f165.law14.hotmail.com [64.4.21.165]) by chiba.3jane.net (Postfix) with ESMTP id D6D14AC45B; Mon, 17 Jun 2002 10:37:00 -0500 (CDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 17 Jun 2002 08:37:00 -0700 Received: from 24.202.234.238 by lw14fd.law14.hotmail.msn.com with HTTP; Mon, 17 Jun 2002 15:36:59 GMT X-Originating-IP: [24.202.234.238] From: "Faust Tanasescu" To: gentoo-dev@gentoo.org Cc: george@gentoo.org Date: Mon, 17 Jun 2002 11:36:59 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Jun 2002 15:37:00.0177 (UTC) FILETIME=[D236F810:01C21614] Subject: [gentoo-dev] gentoo popularity contest system Sender: gentoo-dev-admin@gentoo.org Errors-To: gentoo-dev-admin@gentoo.org X-BeenThere: gentoo-dev@gentoo.org X-Mailman-Version: 2.0.6 Precedence: bulk Reply-To: gentoo-dev@gentoo.org List-Help: List-Post: List-Subscribe: , List-Id: Gentoo Linux developer list List-Unsubscribe: , List-Archive: X-Archives-Salt: 27407ea1-3a5e-4d95-bad1-d6f368fd9eb0 X-Archives-Hash: 6bc62e6b63d2a700bc2fa3b57d599708 Gentoo's popularity contest package ----------------------------------- by davoid and rufiao ABSTRACT: The purpose of this system is to guide the developers of gentoo as to what they should be concentrating on based on what gentoo's users have installed on their system for example. The setup is a client-server system. The server should be stored on gentoo.org It's mainly php and CGI scripts with access to a database. The client is composed of a first-time setup utility and a deamon whose job is to collect data on the system it runs on and to upload this package for analyze to the gentoo.org webserver. The server is composed of a php page that checks if the user can upload to it (so to as limit abuse), and some back-end that would analyze the transferred data and merge it into the table if it is correct. I. Server-side setup 1. New user authentication 2. Normal package information upload II. Client-side setup 1. Contents of tarball 2. first-time configuration of deamon I. 1. New user authentication ============================== o php server accepts new user's e-mail address in URL form. Server then records into newUsersPendingTable user's IP address, request time and any other relevant information such as browser maybe. The mysql fields filled in by the php server should be filly configurable on the server side using forms. o server sends an email to user with a initial session ID generated using /dev/urandom maybe, or whatever medium php is given. it also saves a record with email/cookie pair in mysql table. (user is required to copy-paste the 128-bit cookie from server that he received at the e-mail address he specified upon initial connection and to put it into a configuration file that deamon will read.) Note here that user is not required to answer to any e-mail. He just has to set up his system. This could be as well implemented in the client's user interface as a box that will hold the initial magic cookie, removing the need of editing an external file. o when client comes online for the first transaction, it provides initial cookie and e-mail associated with that cookie. Server detects it is the first time his client would upload his information o client uploads file to client using POST method. server gives client new session ID as soon as transfer is done. server merges information about packages used, version, system into infoTable adds lastMerged in user's record. I. 2. Normal package information upload ======================================= o client connects to server, gives in email address and cookie, starts transfer. o server gives client new session ID by some means (either redirecting user to a new page for which in the URL there is the magic cookie that client has to parse), records lastMerged, starts merging package into infoTable using some CGI script ... Problem: what if client deleted its cookie and wants to upload? cookie invalid? Answer: We could deny access to the database for the user in the future. Problem2: where and how do clients upload their home-made tarball Answer: Clients use the POST method to upload files Problem3: how do we check if the tarball hasn't been modified by the user with bogus information, badly formed data that hog up tables? Answer: the php script should be smart enough to detect this. If script becomes too heavy, there's also CGI and a good perl script. Problem4: table size limited in mysql. Answer: merging into a better database such as postgresql should be condidered. II. Client-side setup ====================== II.1. Contents of the tarball uploaded by client deamon to server =============================================================== In the final version, the user who wants to can control what information is colected from his system. - architecture - ram - installed packages - connection to net etc (whatever that the gentoo developers would need to know about their users) _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com