<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=utf-8">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:Verdana;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0cm;
        mso-margin-bottom-alt:auto;
        margin-left:0cm;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page Section1
        {size:612.0pt 792.0pt;
        margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
        {page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=FR-CA link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Bonjour,<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>De l’avis général, MySQL est la meilleure alternative<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>La majorité des intervenants s’entende pour dire que c’est
difficile … voire même impossible de faire de la réplication avec PostGreSQL<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Québec n’a pas réussi à mettre la réplication en place malgré de
nombreux tests<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Je te proposerais de tester préalablement PostgreSQL… que tu
arrives ou non à une impasse, tu testeras ensuite avec MySQL<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Tu pourras ainsi donner ton avis sur&nbsp;:<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>quelle base de données est la plus conviviale ? et pourquoi ?<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>est-il réalisable de penser faire la réplication d’ici septembre
2009 sur l’ensemble des CSF avec PostgreSQL et pourquoi ? avec  MySQL et
pourquoi ?<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Helene Gauthier<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>

<p class=MsoNormal><b><span lang=FR style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>De&nbsp;:</span></b><span
lang=FR style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
wifidog-bounces@listes.ilesansfil.org
[mailto:wifidog-bounces@listes.ilesansfil.org] <b>De la part de</b> Jimmy
Godbout<br>
<b>Envoyé&nbsp;:</b> 28 mai 2009 12:54<br>
<b>À&nbsp;:</b> WiFiDog Captive Portal<br>
<b>Objet&nbsp;:</b> Re: [isf-wifidog] Ok, the real message: RADIUS, MySQL,
Postgres, reimplementations &amp; the Sherbrooke meeting and other things<o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>Benoit,<o:p></o:p></p>

<div>

<p class=MsoNormal><br>
Quel serait la database idéale ? Je vais faire des tests avec différentes
versions de BD.<o:p></o:p></p>

</div>

<p class=MsoNormal><br>
Merci<br>
<br>
Jimmy<o:p></o:p></p>

<div>

<p class=MsoNormal style='margin-bottom:12.0pt'>-----Original Message-----<br>
<b>From:</b> benoitg@coeus.ca<br>
<b>Sent:</b> Tue, 26 May 2009 19:51:53 -0400<br>
<b>To:</b> wifidog@listes.ilesansfil.org<br>
<b>Subject:</b> [isf-wifidog] Ok, the real message: RADIUS, MySQL, Postgres,
reimplementations &amp; the Sherbrooke meeting and other things<o:p></o:p></p>

</div>

<div>

<div>

<p class=MsoNormal>On May 26, 2009, Marc Blanchet wrote:<br>
&gt; wlanmac a écrit :<br>
&gt; &gt; The question becomes, where should it be optional?<br>
&gt; &gt;<br>
&gt; &gt; Optional in the way it is now where it is used by the portal to be<br>
&gt; &gt; compatible on the roaming side,<br>
&gt; &gt;<br>
&gt; &gt; AP/WiFiDog ---&gt; &lt;wifidog protocol&gt; ---&gt; WiFiDog Portal
---&gt; RADIUS<br>
&gt; &gt;<br>
&gt; &gt; or optional for access provisioning to the router, for device /
access<br>
&gt; &gt; controller compatibility?<br>
&gt; &gt;<br>
&gt; &gt; AP/NAS ---&gt; &lt;RADIUS&gt; ---&gt; &lt;something?&gt; ---&gt;
WiFiDog Portal<br>
&gt; &gt;<br>
&gt; &gt; (Note: &quot;NAS&quot; for Network Access Server is a more generic
term for access<br>
&gt; &gt; controller in RADIUS documentation).<br>
&gt; &gt;<br>
&gt; &gt; A concept I have been thinking of would be something along the lines
of<br>
&gt; &gt; what Marc suggested. A proxy to map the AAA features of a NAS with
the<br>
&gt; &gt; WiFiDog HTTP protocol.<br>
&gt; &gt;<br>
&gt; &gt; Such that you might have:<br>
&gt; &gt;<br>
&gt; &gt; AP/NAS/Proxy ---&gt; &lt;wifidog&gt; ---&gt; WiFiDog Portal (to
support old-school<br>
&gt; &gt; sites)<br>
&gt; &gt;<br>
&gt; &gt; AP/NAS ---&gt; &lt;RADIUS&gt; ---&gt; Proxy/WiFiDog Portal (to
support standard<br>
&gt; &gt; access controllers)<br>
&gt; &gt;<br>
&gt; &gt; AP/NAS ---&gt; &lt;RADIUS&gt; ---&gt; &lt;FreeRADIUS/SuperProxy&gt;
---&gt; Multiple WiFiDog<br>
&gt; &gt; Portals based on Realm (the future)<br>
&gt; &gt;<br>
&gt; &gt; It's just an idea... but, could be a way of achieving the best of all<br>
&gt; &gt; worlds, RADIUS-wise.<br>
&gt;<br>
&gt; you were just 5 minutes faster than me to write almost exact same<br>
&gt; drawings... a few minor edits below:<br>
&gt;<br>
&gt; this is my view of v2:<br>
&gt;<br>
&gt; &quot;v1&quot; AP -&gt; wifidog-http -&gt; v2 wifidog portal -&gt; radius
backend<br>
&gt; &quot;v2&quot; AP -&gt; radius -&gt; radius backend<br>
<br>
You just essentially described CoovaChilli, but even with Coova there is still
a piece of software to run on the leaf node, and a piece of software other than
the RADIUS server to run on the server for full full functionnality. But if
this is what you want, continuing with wifidog is just plain silly (assuming
you use it) Coova is really good at what it does, and I believe it's main
developer has exactly the same RADIUS-centric vision as you do.<br>
<br>
It is funny however to see people suggest using RADIUS would make everything <br>
simpler to understand and implement. Unless someone spends most of his <br>
workdays working with RADIUS and writing FreeRADIUS plugins, I find that well
beyond hard to believe. The mere LIST of distinct RFCs specific to RADIUS <br>
(http://en.wikipedia.org/wiki/RADIUS#RFCs) is half as long as the current
wifidog protocol documentation:
http://dev.wifidog.org/wiki/doc/developer/WiFiDogProtocol_V1<br>
<br>
&quot;Using RADIUS&quot; is just about as precise in the wifidog project
context as &quot;Using http&quot;. There is the RADIUS UDP transport protocol
then there are the various extensions, the RADIUS servers themselves, and all
the modules and backends to get them to help you manage networks.<br>
<br>
But when people say &quot;let's use RADIUS&quot; they probably have a much more
precise meaning in mind. I think the reasoning goes like this: <br>
1- RADIUS is designed to manage users<br>
2- RADIUS databases are frequently replicated<br>
3- RADIUS has provisions for roaming between servers<br>
4- Several switches and access points have built-in RADIUS support<br>
5- RADIUS is used to manage large networks, including wireless ones.<br>
Therefore, RADIUS probably does everything wifidog does, and does it better.<br>
<br>
The reasoning is logical. But indicates either a misunderstanding of what
wifidog is, or of what RADIUS provides.<br>
<br>
1- User login handling is a relatively minor aspect of WiFiDog. It's central to
RADIUS. Minor for wifidog but with a rather unique twist: the focus managing hundreds
of thousand users that are allowed to self-subscribe and freely use the
network, and then manage abuse of any single user without human intervention.
Furthermore, the system has to track displaying content taking while taking
into account which content the user has previously seen and where. Basically
manage users as a big set, not individually (for the longest time, there wasn't
even a facility to delete them, because in general it's undesirable to do so).
If user's can't self-subscribe WiFiDog just plain doesn't care where the
username-password pairs come from. RADIUS, LDAP, whatever. But even if we did
rely entirely on a mandatory RADIUS backend, we would have had to write a user
management backend for said RADIUS server to provide all these services.
Relying on a RADIUS server and the use it as a dumb user/password store just
doesn't make sense.<br>
2- Quite true. However (unlike LDAP) database replication isn't part of the
scope of the RADIUS specs. A typical radius server with a MySQL backend will use
the mysql replication facilities to replicate. A radius server with a LDAP
backend will use LDAP facilities to replicate. A RADIUS server with a file
backend will use rsync. You get the idea. In any event, one cannot replicate
two radius servers running different RADIUS software together simply because
they are RADIUS servers.<br>
3- It does, but it doesn't make figuring out the realm automatically (which is
the real UI problem) any simpler or harder. That being said, using RADIUS for
inter-auth server communication would make perfect sense, if it didn't suddenly
add the dependency of an operational freeradius server, and of writing a
freeradius module to authenticate against the wifidog database (although this
would potentially make WPA encryption available at the same time)<br>
4- They do, but that doesn't make them support dynamic walled garden, equitable
bandwidth share between users, centralizing gateway configuration and firewall
settings automatic or even any easier. If they did, there would hardly be any need
for CoovaChili or the wifidog gateway either. <br>
5- That's a valid point. I personally believe the techniques applied by the
ISPs (which are the main force behind RADIUS) are frequently insufficient and
conter-productive. But that is very much open for debate.<br>
<br>
The RADIUS protocol is a UDP protocol designed to transmit network credentials
and usage statistics between an authentication source (typically a database of
some kind) and a network access controler (a modem, a switch, these days a wifi
router). As such it's applicability may seem obvious. Various extentions define
additional attributes (but have very uneven level of support between
implementations). <br>
<br>
------- The gateway ------<br>
<br>
Indeed at the genesis of the wifidog project (End of 2003), Using the RADIUS
protocol for gw-auth server communication was considered, and rejected. The
protocol is simple (more so than http in many ways). But It clashed with points
1 and 4 of the original gateway requirements which were:<br>
<br>
1- Be embeddable in even the smallest systems. Indeed we got the gateway down
to 16kB.<br>
2- Work behind any proxy or firewall, and be completely unaffected by NAT<br>
3- Offload as much intelligence and processing to the auth server.<br>
4- Only require a web server to implement an auth server.<br>
5- No dependencies on crypto libs if at all possible.<br>
<br>
Indeed the several alternate auth server implementations for specific needs
have been written for the WiFiDog 1.0 protocol.<br>
<br>
While this is not the focus of the current sprints by the Quebec wireless
groups that agreed to put their efforts in common a few weeks ago, there is a
clear need to have a WiFiDog 2.0 protocol, to support the following features:<br>
<br>
1- Have all the nodes run identical images, INCLUDING configuration<br>
2- Dynamic walled garden (For OpenID support, mesh backhaul nodes whitelisting,
allowing web mashups on the login page)<br>
3- Allow storing static and dynamic node-specific firewall rules on the auth
server if for no other reason than to finally get rid of the TrustedMacList
gateway config parameter)<br>
4- Dynamic bandwidth management (as pecentage of available bandwidth, not just
an absolute number of bytes/sec for a class of user)<br>
5- Allow the auth server to tell the gateway when to contact it next.<br>
<br>
This COULD all be implemented as RADIUS protocol extensions, but once again
RADIUS wouldn't make it any simpler. <br>
<br>
------------ The auth server ---------------<br>
<br>
Now what was the original focus of the auth server?<br>
1- Allow people to self-subscribe, and self-verify their email address<br>
2- Present location specific content to the user, using content stored OUTSIDE
the auth server as much as possible.<br>
3- Be fully multilingual<br>
4- Manage abuse<br>
<br>
Since then it's grown in scope, and we didn't fill these four original goals to
anyone's complete satisfaction. Explaining exactly what we were trying to build
in early 2004, and the successes and failures we had could fill a book. Yet it
can be illustrated simply with today's technology:<br>
<br>
We were trying to build a fully location and view history aware Liferay.<br>
<br>
<o:p></o:p></p>

<p><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>But even in 2009 we haven't yet consolidated on a
standardized, language neutral portlet specifications with widely available
open server implementations. But it is (excruciatingly) slowly getting there.<br>
<br>
There was a decision in Sherbrooke to write a specification and API to
completely decouple the content serving from the auth server. This will be
very, very interesting work. It will also be very, very difficult work to make
it a reality. I've done standard writing work before. Avoiding groupthink and
allowing implementations that are so lowest common denominator as to make using
the standard pointless, while making it easy to implement and popular is never
easy. <br>
<br>
<o:p></o:p></p>

<p><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>It will not make the auth server simpler either (on the
contrary). But it must be done if we are to have any kind of meaningful l
impact on helping making delivering truly location specific content to end
users a reality. It's the only MAJOR technical undertaking agreed on in
Sherbrooke, but it's an important one to the future of the project.<br>
<br>
----- PostGres vs MySql ------<br>
<br>
As for PostGres vs MySql, I won't get into that debate again. It's pointless.<br>
<br>
<o:p></o:p></p>

<p><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>I just give some usefull information for anyone who intends
to revisit the issue:<br>
-MySql used to be supported, but support for it was dropped because we couldn't
find ANY developer to maintain it.<br>
- http://bugs.mysql.com/bug.php?id=2364 would make automatic schema upgrade of
live servers like we have now excruciatingly slow once you have a fairly large
connetion history. Not to mention that database modification statements are not
transactional in MySql, so we'd have to do a lot more testing, so we couldn't
do schema updates as often as we do now.<br>
- The inability to determine which row is kept in in GROUP BY statements in
mysql will require architecting the statistics subsystem very differently if
one wants to maintain comparable performance. <br>
- If I were to start from scratch today, I'd probably investigate the
feasibility of basing the authserver on something like CouchDB (real support
for asynchronous multi-master replication, map-reduce, keep real ACID support
at the cost of being non-relational). <br>
<br>
In any event I'm very much open to a project to re-add MySql support IF it
brings new developers along (i know it WILL bring new users along, but it's a
disservice to everyone if we can't support them like last time we supported
MySql). <br>
<br>
Teaching both PostGres ans MySql classes and doing data-mining on both, I must
say that if someone manages to make all the database queries MySql and Postgres
compliant while keeping dynamic schema upgrade and near realtime stats on a 1gb
+ wifidog dataset I'll be quite favorably impressed ;) But it IS doable, with
some compromises.<br>
<br>
------ Why not start over ------<br>
<br>
I've said most of this while in Sherbrooke, and a consensus was reached. <br>
<br>
<o:p></o:p></p>

<p><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>Yes, the wifidog auth server is very big.<br>
<br>
Writing a basic auth server that displays a different web age to every user is
a &lt; 1week project in a modern dynamic language (Python, Ruby and even PHP)
for a competent programmer. In fact that's the time it took one person to write
the original implementation of the auth server.<br>
<br>
Writing a generic auth server that is easy to install, and meets the needs of
disparate communities and is structured to accept outside contributions is
something completely different.<br>
<br>
Most of the complexity in wifidog isn't in user management, or gateway
interaction, or any of the things I see people debate when they say that it
would be easier to start from scratch. Most of the complexity is in:<br>
<br>
-Location-aware and history-aware content delivery and management<br>
-User permissions<br>
-Web based installer, dependency install and automatic schema upgrade<br>
-The statistics subsystem<br>
-Pervasive multilingual support<br>
-Making everything generic enough that we don't end up with spaghetti code.<br>
<br>
<o:p></o:p></p>

<p><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>Off course, wifidog support many, many other features, but
code-wise they are comparably very small.<br>
<br>
If you have specific needs, ask how we think they could be integrated in
wifidog without causing problems to anyone else. If you can't do it, by all
means do roll your own. With any luck, we'll have some good ideas to steal from
;) <br>
<br>
------ What will happen in the next few months -----<br>
<br>
<o:p></o:p></p>

<p><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>In the meantime, I expect very good things to come from the
meeting in Sherbrooke. I've seen open minded people with actual resources to
commit who agreed on cooperation and realistic and achievable goals. The
patches are already rolling in. <br>
<br>
<o:p></o:p></p>

<p><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>I'll do my best to help the new contributors, and integrate
the patches. But very soon, other people will do most of that job as well.<br>
<br>
<o:p></o:p></p>

<p><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>If I become &quot;just another contributor&quot; I'll
consider that a major victory for the project. <br>
<br>
<o:p></o:p></p>

<p><o:p>&nbsp;</o:p></p>

<p><o:p>&nbsp;</o:p></p>

<p class=MsoNormal style='margin-bottom:12.0pt'>-- <br>
Benoit Grégoire<br>
<br>
<o:p></o:p></p>

</div>

</div>

<div class=MsoNormal align=center style='margin-top:7.5pt;text-align:center'>

<hr size=1 width="100%" noshade style='color:#A0A0A0' align=center>

</div>

<div>

<p class=MsoNormal style='margin-top:7.5pt;line-height:15.6pt;background:white'><b><span
style='font-size:9.0pt;font-family:"Verdana","sans-serif";color:black'>Free
Online Photosharing</span></b><span style='font-size:9.0pt;font-family:"Verdana","sans-serif";
color:black'> - Share your photos online with your friends and family!<br>
Visit <a href="http://www.inbox.com/photosharing">http://www.inbox.com/photosharing</a>
to find out more!<o:p></o:p></span></p>

</div>

</div>

</body>

</html>