Date: Wed, 02 Aug 2006 22:30:45 -0400 From: Xiao-Yong Jin <xj2106@columbia.edu> To: freebsd-questions@freebsd.org Subject: Re: Gotta start somewhere ... how many of us are really out there? Message-ID: <87wt9qzh2i.fsf@photon.homelinux.org> In-Reply-To: <44D153D0.9000304@webanoide.org> (Mikhail Goriachev's message of "Thu, 03 Aug 2006 11:39:28 %2B1000") References: <20060728164526.E27679@ganymede.hub.org> <17615.30414.314802.792740@jerusalem.litteratus.org> <ef10de9a0608011037w3609b5a6k1709aea61d43ed0f@mail.gmail.com> <20060801223754.U27679@ganymede.hub.org> <ef10de9a0608011859q45bdd636o757fb4aba2d3404d@mail.gmail.com> <20060801230301.Q27679@ganymede.hub.org> <df9ac37c0608012122q196a6434jf849cc7bd8c1156@mail.gmail.com> <44D09F46.6020300@dial.pipex.com> <ef10de9a0608021047u553a812fpbcf09c8c26df09b6@mail.gmail.com> <44D0F2FE.9020507@dial.pipex.com> <ef10de9a0608021216u455099a9yf66ea2d1698f4d19@mail.gmail.com> <20060802203604.A6529@ganymede.hub.org> <44D153D0.9000304@webanoide.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Mikhail Goriachev <mikhailg@webanoide.org> writes: > User Freebsd wrote: >> On Wed, 2 Aug 2006, Nikolas Britton wrote: >> >>> This may sound dumb but why don't we just put a registration link on the >>> FreeBSD main page... or "registration" in sysinstall. Isn't this how >>> everyone else handles the problem? >> >> User A installs FreeBSD, registers, works with it for a week, finds he >> isn't getting anything done with it, wipes the drive and goes to something >> else ... >> >> User B installs FreeBSD 5.x, registers, works with it for a while and >> decides to CVSup to -CURRENT, so now we have an artificially high # of 6.x >> installs, and an artificially low # of 7.x installs ... nobody looks to be >> moving to 7.x, therefore why support it from a vendors perspective ... > > > Right, I've been following this thread from the start but didn't want to > get involved, even though I felt this is important and necessary. I've > come up with this token-based registration idea: > > Agent: Knock, knock... > Server: Hi, give us your last 2 tokens... > Agent: I don't have them... I'm a newborn. > Server: Ok. Here's one for you $token1 and come back in 7 days. > > 7 days later (or more if it's a laptop) > > Agent: Knock, knock... > Server: Hi, give us your last 2 tokens... > Agent: I only have 1 token. > Server: Ok. There you go $token2. Get back in 7 days. > > 7 days later (or more if it's a laptop) > > Agent: Knock, knock... > Server: Hi, give us your last 2 tokens... > Agent: Take them, $token1 and $token2. > Server (compares tokens): Thanks, now give us some info about yourself. > Agent: Ok, sending $information. > Server: Thanks, this is another $token3 for you. Come back in 7 days. > > ... beyond this point the agent is officially registered but must > maintain its rego by reporting every 7 days and keep providing latest 2 > tokens ... > > > In short, an agent must earn the registration. In this case it takes 2 > weeks. Once it registers, it becomes a real number in the stats. If that > agent stops reporting for a few months then it gets removed from the > stats. If agent's computer upgrades, then it doesn't matter because it > still sends $information (with updates) every time it reports. > > If another agent steals the tokens then it isn't an issue. The victim > gets rejected until it collects new tokens. This is because stolen > tokens already got registered. The burglar, in the other hand, stays > with that stolen registration and resubmits its own $information (uname, > dmesg, whatever), which overwrites victim's data. To strengthen the > system and avoid token high-jacks we could increment the number and > complexity of tokens. > >>From users' point of view, there are no registration or scary > configurations. The system takes over and does everything behind the > scenes. For sure, the only necessary thing would be an enable_rego=YES > or similar line in /etc/rc.conf. > > In order to cater for the demand, I reckon there would be enough people > willing to donate servers and bandwidth (I'd be one of them). Agents > also could detect the closest server on their own and report to it > (fastest_cvsup[1] style)... > > Ok, I'll stop here for now. > > > Cheers, > Mikhail. > > > [1] - > http://www.freebsd.org/cgi/url.cgi?ports/sysutils/fastest_cvsup/pkg-descr > You still can't avoid fakeries. In fact, I guess that unless one uses some kinds of Genuine Advantage things, you can not tell if the data is true. However, acquiring a unique id from the server is a good idea to prevent from duplication, if the bandwidth permits. Therefore, why not simplify it? 1. Require an ID from the server after installation if permitted by the user. 2. Provide the ID and `uname -mr` periodically or in a randomized time interval between one to two months. Or simply let the user decide when to run it. But states clearly that it'll overload the server if all the clients connect simultaneously. Let me say it again. There are three problems we are trying to solve. a. Bandwidth. b. Duplicates. c. Fakery. By randomizing the time interval, bandwidth can no longer be a problem. And the uniqueness is assured by the ID generated in the server. Finally, I can't see any open source solution could prevent some people from generating fake boxes, even with some serial number of the hardwares. Can we do some checks of the hardware serial numbers? Okay, even if we do, we are going to touch too much privacy. So just forget about it. -- Xiao-Yong
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87wt9qzh2i.fsf>