[Wifidog] Version 1.0

[Benoit Grégoire]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 22 April 2004 10:10 am, Philippe April wrote:
> Okay I believe me and Pascal (correct me if I'm wrong) have talked with
> Daniel before and got different answers regarding that, we thought we were
> aiming more for a centralized architecture. That way we don't need to
> build a web interface for configuring complex Wifidog's config rules,
> while still taking into account the rules from the central server, etc.
>
> Pascal, Daniel? Est-ce moi ou est-ce qu'on a eu 2 différentes idées sur la
> facon dont ce doit etre fait?

Je ne sais pas ce que Daniel a dit hier, mais ce sont les même idées qui 
circulent depuis le début.  Déjà lors de la journée de travail chez Daniel, 
ce dernier avait proposé un modèle où le serveur central est responsable de 
déterminer droits d'accès.  Ce à quoi je m'étais farouchement opposé étant 
donné que l'on tomberais dans un réseau ou la confiance de l'usager dans les 
politiques du serveur central doit être quasi-absolue, et que ça oublie les 
besoins de l'usager résidentiel, par lequel selon moi passera une bonne 
partie de l'avenir d'ISF comme mouvement social.

À la réunion chez Philippe, on a rediscuté de la chose, et bien que ma 
position avait été bien acceptée, on a fait valoir, avec raison, qu'il serait 
très utile pour la gestion des hotspots directmenet sous le contrôle d'ISF 
que le auth server puisse suggérer certaines politiques par défaut pour les 
différentes classes d'usager.  Quelque chose de simple, genre ports ouverts, 
ports fermés, pourcentage maximal de la bande passante alloué aux usager 
wireless.  Relativement simple à exprimer, et ça laisse la majeure partie de 
la configuration réseau chez le gateway (largeur de bande totale, interfaces, 
politiques pour l'interface(s) LAN, adresses MAC requérant un traitement 
différent, usager "owner", etc. 

De ce que je comprends (et je ne suis pas sûr que c'est ce que Daniel a 
réellement suggéré), on parle maintenant de centraliser l'ensemble de la 
configuration et des règles du firewall au auth server, faisant en sorte que 
désormais le auth server, de facto, protège l'ensemble des réseaux internes 
et qu'on est donc "responsable", ou à tout le moins qu'on devient l'opérateur 
d'un réseau, pas seulement d'un service d'authentification.

Si on va dans cette direction, ça complexifie énormément de choses.  Tout 
d'abord l'intégrité des messages entre avec le serveur central devra être 
vérifiée à l'aide de certificats.  Ensuite, il faudra se créer un language 
permettant d'exprimer de façon abstraite les politiques de firewall, sans 
connaître les nom d'interfaces interne/externe/lan du gateway, sa 
plate-forme, ses adresses IP, ou son système de firewall.

Et malgré tout, wifidog doit savoir quoi faire s'il n'arrive pas à contacter 
le auth server, il doit dont pouvoir avoir une configuration par 
défaut...configurable.  Alors je ne vois pas très bien ce que ça simplifie.

> I believe we all have different views of how things should get done. Now
> we just need to know, who gets to decide? do we just present the different
> ways and vote? It seems clear in everybody's head, but we haven't agreed
> on a design altogether.

Well, in theory Mina would probably get the final call.  In practice, probably 
we reach a concensus, and failing that the first who writes the code get's 
it's way for now.

> I would really suggest to take off all userclasses code for 1.0, even just
> to have something clean since we won't be using it now. That's just my
> personal opinion.

I don't really care, but remember that the 1.0 branch will be short lived, so 
the benefits of "cleaning up" the code are very relative.  Now should we 
agree that we indeed won't be using classes ever, that's a different story.
  
> So for 1.0,
>
> Can we all agree that we remove the unneeded code from the source tree,
> have users authenticated (yes or no returned from auth server), and be
> granted internet access, with a general timeout from the config file, so
> if there's no traffic for like 5 minutes, they get denied access?

Yes.

> Later on, we will return a status code regarding authentication and more
> complicated rules.

I see no reason not to return a status code, even if we (currently) do nothing 
with it.  But again since 1.0 will be short lived, I don't really care.

> Now I'd love to ship out version 1.0 very soon with limited
> functionalities, while still aim in the right direction for the future,
> it'd be great if we could all agree on something so we can code and start
> the testing phase soon.

Let's just do it like you said.  Just keep in mind that branching requires a 
lot of effort (all patches AND COMMITS in the stable branch need to be 
manually applied to two places, separate ChangeLogs, etc.) and that the 
further apart they drift before we "kill off" 1.0, the more it will slowdown 
future development.

- -- 
Benoit Grégoire, http://step.polymtl.ca/~bock/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAh/qnmZ6zzPlLuwMRAo6fAJoDPeuQVf9ZYI+Gc9imAv7EA4gJLwCfSACi
cgmS1wsECv1bInxcJ0A+Bdc=
=MiEz
-----END PGP SIGNATURE-----

_______________________________________________
Wifidog mailing list
Wifidog at isf.waglo.com
http://isf.waglo.com/mailman/listinfo/wifidog_isf.waglo.com