bouncer_r/php index.php,1.5,1.6
David Farning (dfarning)
fedora-extras-commits at redhat.com
Tue Aug 2 05:20:27 UTC 2005
Author: dfarning
Update of /cvs/fedora/bouncer_r/php
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv28668/php
Modified Files:
index.php
Log Message:
Pull bouncer intro from mozilla --need to modify for fedora
Index: index.php
===================================================================
RCS file: /cvs/fedora/bouncer_r/php/index.php,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- index.php 2 Aug 2005 00:02:55 -0000 1.5
+++ index.php 2 Aug 2005 05:20:25 -0000 1.6
@@ -12,9 +12,193 @@
?>
<div id="page-main">
-<p>test paragraph
-</p>
+<h2> Abstract </h2>
+<p>Bouncer uses MySQL to organize the Mozilla mirror network. Its primary responsibility is to know what mirrors are supposed to contain what files and periodically query their availability. Based on this knowledge, accumulated by a "sentry" script, Bouncer redirects simple user requests to appropriate mirrors based on a random seed that is affected by the mirror's relative bandwidth capabilities.</p>
+<p>In short, Bouncer is a smarter way to use an extended mirror network to help users get what they need.</p>
+<p>It contains three main pieces:</p>
+<ul>
+ <li> Admin tools to manage the mirror network</li>
+ <li> Sentry; a daemon that queries mirrors for available files and updates their status in the Bouncer database</li>
+ <li> Bouncer; a singular file responsible for taking arguments and redirecting users to the appropriate location</li>
+</ul>
+
+<h2> History </h2>
+<p>Bouncer went live at 2pm, November 9th, 2004 and has been serving files since. It was originally developed as a backup plan, but was pushed to production when the demand for Firefox 1.0 overloaded the existing mirror network. Utilizing secondary mirrors through Bouncer helped keep downloads flowing in the wake of Mozilla's largest release to date.</p>
+<p>Bouncer was originally developed at Oregon State University by Scott Kveton and Mike Morgan. The intent was to help the Mozilla community meet its growing demands.</p><p>Additional development on Bouncer has continued into 2005. K Lars Lohn, a developer at the Oregon State University Open Source Lab, has made great contributions to the project by assisting with database improvements and the migration of Sentry from Perl to Python. He has helped make Sentry a multi-threaded daemon that will scale much better for an increased mirror network hosting a greater number of projects/files.</p>
+
+<h2> Status </h2>
+<p>Bouncer 1.0 is currently directing users to the latest Firefox and Thunderbird releases through the mirror network. Bouncer 2.0 is nearing the final stages of development and should be deployed before Firefox 1.0.1 is released.</p>
+
+<h2> Schedule </h2>
+<ul>
+ <li> November 9th, 2004 - Bouncer goes live as a Plan B for Firefox v1.0 release.</li>
+ <li> February 18th, 2005 - Tentative release date for Bouncer v2.0 in preparation for Firefox 1.0.1 release.</li>
+ <li> Spring, 2005 - Development of Bouncer v3.0, integration with build process.</li>
+</ul>
+
+<h2> Roadmap </h2>
+
+<h3> Bouncer 1.0 </h3>
+<ul>
+ <li> Basic administrative tools
+ <ul>
+ <li> OS</li>
+ <li> Products</li>
+ <li> Regions </li>
+ <li> Mirrors </li>
+ <li> Users </li>
+ <li> File Locations </li>
+ </ul>
+ </li>
+ <li> Sentry
+ <ul>
+ <li> Basic Perl script to query all locations on all mirrors</li>
+ <li> Failed requests would be flagged and would be removed from rotation</li>
+ </ul>
+ </li>
+ <li> Bouncer Script Parameters
+ <ul>
+ <li> OS </li>
+ <li> Product </li>
+ <li> Language </li>
+ </ul>
+ </li>
+ <li> Known Issues
+ <ul>
+ <li> Languages; offered as a pass-thru but there was no support for it on the database side of things because it was added post-development</li>
+ <li> Versions; 1.0 offers only the latest releases </li>
+ <li> Sentry; only queries HTTP mirrors </li>
+ <li> Sentry; does not check MD5 sums </li>
+ </ul>
+ </li>
+</ul>
+
+<p>Bouncer 1.0 was a great start, but lacked some functionality due to time constraints. Since 1.0 we have had improved communications, and developed a solid plan to fix known issues and secure the overall application.</p>
+<p>1.0 is a temporary solution to aid Mozilla in a time of growth. It will evolve with time and improve itself through the combined efforts of the community.</p>
+
+
+<h3> Bouncer 2.0 </h3>
+<ul>
+ <li> Administrative changes
+ <ul>
+ <li> MD5, SHA1 key storage</li>
+ <li> Mirror contact information added</li>
+ <li> Mirror policy reviewed and updated</li>
+ <li> Versions</li>
+ <li> Languages</li>
+ <li> Improved database structure (denormalized a bit)</li>
+ </ul>
+ </li>
+ <li> Sentry
+ <ul>
+ <li> Converted to Python</li>
+ <li> Multi-threaded</li>
+ <li> Scalability improved</li>
+ <li> Actually downloads file and checks MD5, SHA1</li>
+ </ul>
+ </li>
+ <li> Bouncer
+ <ul>
+ <li> Added optional Version parameter; defaults to latest version by date</li>
+ <li> Added full language support based on modified DB and admin capabilities</li>
+ </ul>
+ </li>
+ <li> Development Model
+ <ul>
+ <li> Integration with Mozilla CVS tree</li>
+ <li> Adoption of build process and other Mozilla standards</li>
+ </ul>
+ </li>
+</ul>
+
+<p>This first joint effort provides better overall security and granularity. It fixes Language and Version gaps and provides better assurance through improved file checking (MD5,SHA1).</p>
+<p>Second priorities were improved statistical tools for generating trend reporting. That was not completed, but will be addressed in 3.0.</p>
+
+<h3> Bouncer 3.0 </h3>
+<ul>
+ <li> Build Features
+ <ul>
+ <li> Possible automation with build process to streamline releases</li>
+ <li> Queue of upcoming releases for build engineers to manage availability of binaries on mirror network</li>
+ </ul>
+ </li>
+ <li> Improved reporting tools based on download counts and apache logs (stored in separate db)</li>
+ <li> UMO
+ <ul>
+ <li> Possible integration with AUS, PFS, or other update services to leverage mirror network capabilities</li>
+ <li> Advanced signing for improved security</li>
+ </ul>
+ </li>
+ <li> Download selector form based on database contents to let users choose what they want to download and where they can download it from</li>
+ <li> Updated mirrors page to give better recognition to mirror network contributors</li>
+ <li> Any other public tools to assist the community</li>
+</ul>
+
+<p>The future of Bouncer depends on the development of UMO and what role people see it playing in relation to Mozilla's update service. It will continue to distribute binaries through the mirror network, but how it can better fit into Mozilla's workflow has yet to be determined. We are working on figuring out how it can help automate and combine builds, updates, etc. The best is yet to come.</p>
+
+<h2> Bouncer Ideas </h2>
+<ul>
+ <li> Proactive mirroring
+ <ul>
+ <li> It occurs to me (Chase) that if bouncer has a list of mirror sites and then checks the sites for new file additions as we add them to dmo, we are nearly to the point of closing the loop and just signaling to the mirror sites that a new file is available for d/l and for them to grab it. From here, we could do other sorts of neat things:
+ <ul>
+ <li> Specify the exact set of files that have changed, to avoid having site-wide rsyncs that check the entire disk needlessly.</li>
+ <li> Schedule the initiation of the syncing so that the seed hosts aren't swamped by requests.</li>
+ </ul>
+ </li>
+ </ul>
+ </li>
+ <li> File Weighting
+ <ul>
+ <li> Right now requests are equal regardless of how large the file is.</li>
+ <li> We should take into account how "heavy" a file is based on size when considering redirects somehow.</li>
+ <li> Will this present a larger problem? How important is this? Thoughts?</li>
+ </ul>
+ </li>
+ <li> Filepath Exceptions
+ <ul>
+ <li> Bouncer needs to be able to handle products and files that do not fit the common schema for building URLs.
+ <ul>
+ <li> For example, if the OS is in the file name.</li>
+ <li> Or if there are no localization paths, etc.</li>
+ </ul>
+ </li>
+ <li> Essentially it should allow us to specify a larger chunk of the URL based on an option.</li>
+ </ul>
+ </li>
+</ul>
+
+<h2> Server Requirements </h2>
+
+<h3> v1.0 </h3>
+
+<ul>
+ <li> Perl (sentry.pl)
+ <ul>
+ <li> LWP (libwww-perl)</li>
+ </ul>
+ </li>
+ <li> PHP 4.3.x</li>
+ <li> Apache (any version)</li>
+ <li> MySQL ~ 4.0</li>
+</ul>
+
+<h3> v2.0 </h3>
+
+<ul>
+ <li> PHP 4.3.x</li>
+ <li> Apache (any version)</li>
+ <li> MySQL ~ 4.0</li>
+ <li> Python 2.3
+ <ul>
+ <li> mx.DateTime (<a href="http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Download-mxBASE" class='external' rel="nofollow">http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Download-mxBASE</a>)</li>
+ <li> MySQLdb (<a href="http://sourceforge.net/projects/mysql-python" class='external' rel="nofollow">http://sourceforge.net/projects/mysql-python</a>)</li>
+ <li> Crypto (<a href="http://www.amk.ca/python/code/crypto" class='external' rel="nofollow">http://www.amk.ca/python/code/crypto</a>)</li>
+ <li> cse utils (<a href="http://wiki.osuosl.org/display/howto/cse+utils" class='external' rel="nofollow">http://wiki.osuosl.org/display/howto/cse+utils</a>)</li>
+ </ul>
+ </li>
+</ul>
</div>
More information about the scm-commits
mailing list