[isf-wifidog] on radius and roaming

Mar 26 Mai 11:49:07 EDT 2009

switching in english for non-french speakers:

there is a need for a federation, so that my zapquebec userid can be
used in zapsherbrooke, zapParis or zapBarcelona or else.

well, with RADIUS, this is straight forward. this RADIUS functionality
is used by the ISPs to enable roaming of users between networks. It is
also used by the education networks: the project is known as eduroam
(I've been involved in setting up a eastern canada eduroam radius server
for the canadian universities).

a RADIUS federation is technically super simple to setup. ready for IPv6.

if one start implementing this from scratch, then you are on your own
and you don't benefit all the work and code already out there.

again, think the zap as an access router. then look at what the
community with access routers has been using for years. then you see
RADIUS as the main component for the AAA service (authentication,
authorization and accounting). all the components for radius are
opensource, but you can also use many commercial products if you want
to. there is a whole big community behind it.

with RADIUS/SNMP/openvpn, these are well-known, developed, used
standards. The wifidog will become very lightweight, simple to maintain,
and will gain all the features of the other. And with standards and
open-source, you have an evolution path if needed.

Marc (sorry for the stickyness of my thread: we have been involved
helping providers since early 90's. that is why I'm so convinced...)

Marc Blanchet a écrit :
> bremy at zapquebec.org a écrit :
>> ok.. je vias continuer en français... car je crois qu'on ne se comprends
>> pas ;-))
>>
>> Quand bien même on remplacerait l'authentification "hardcodée maison"
>> propriétaire de Wifidog par un processus d'authentification Radius, on
>> aurait toujours le même problème de redondance de base de données
>> Scenario:
>>
>> Si le serveur Radius ne tombe pas
>> ET
>> Si le serveur Wifidog Principal est tombé
>> ET
>> Le serveur radius accorde un droit d'accès à un utilisateur sur une ZAP,
>> le client Wifidog de cette ZAP va après cette authentification réussie
>> (et peu importe Wifidog, Radius, whatever....)"tenter" d'envoyer ses
>> données statistiques dans la base de données postgresql du serveur
>> Wifidog Principal...
> 
> pas nécessairement. les stats sont collectées via RADIUS.
> 
> bref, voir mon autre message envoyé à Hélène.
> 
> je ne suis même pas sûr qu'on ait besoin d'un BD dans wifidog. En tout
> cas, pas besoin pour le côté opérationel: i.e. authentification,
> service, usagers, etc...  tout devrait être géré par RADIUS.
> 
> bref, wifidog-auth server ne devient qu'un proxy web-radius... pour
> supporter les clients wifidog actuels. Les nouvelles zaps pourraient
> être clients RADIUS et demander directement l'authentification via RADIUS.
> 
> RADIUS te donne des millions de possibilités: pousser des filtres
> spécifiques pour des groupes d'usagers, pousser des configurations
> particulières, des adresses IPv6, des préfixes IPv6, etc...  RADIUS
> pourrait te permettre (même tout de suite si tu veux, mais je ne crois
> pas que c'est l'objectif) d'utiliser 802.1x. avec du développement
> home-maid wifidog, il faudrait tout programmer cela.
> 
> RADIUS t'évite de réinventer la roue que l'IETF, les fournisseurs
> Internet et les entreprises ont fait évoluer depuis 10 ans...
> 
> Marc.
> 
>> ... Le serveur Wifidog principal ne répondant pas... il finira tôt ou
>> tard par remplir la base de données postgresql du serveur Wifidog
>> Secondaire...
>>
>> Et c'est là qu'on est "pognés" avec les problèmes de répliques et de
>> synchro entre les 2 bases postgresql des 2 serveurs Wifidog (principal
>> et Secondaire)
>>
>> Et le coeur du problème est bien là (si j'ai bien compris tes propos et
>> ceux de Benoit Grégoire dans le passé..) c'est que c'est facile avec
>> MySQL mais presque impossible avec postgresql car il existe environ 2-3
>> outils pour faire cela mais aucun n'est vraiment fiable, mature,
>> user-friendly, efficace...
>>
>> On peut résumer ainsi?
>>
>> Bruno
>>
>>
>>
>> Message originalMarc Blanchet <marc.blanchet at viagenie.ca>:
>>
>>> bremy at zapquebec.org a écrit :
>>>> Message originalPierre-Luc Bacon <pierrelucbacon at aqra.ca>:
>>>>
>>>>> Their results were not as good as they would have liked. Also, he is
>>>>> pointing out that the need for database replication might not be
>>>>> existent if something like Radius were adopted.
>>>> I do not agree.
>>>> Wifidog's auth server has not for only role user's authentication, but
>>>> either feeding statistics database and also hotspot's monitoring
>>>> database. So, it seems to be evident that we nedd ALL THE database
>>>> availibility, in any way, and always.
>>>> Replace Wifidog's auth by radius auth is definitly not an issue to
>>>> Wifidog's replication.
>>> again it "depends".
>>>
>>> because, think of wifidog as an access server. Access servers do not
>>> have databases, they use RADIUS (or Tacacs) and all the stats, etc...
>>> are collected through the RADIUS infrastructure. Overall, we might need
>>> to define a few new definitions in RADIUS for the specifics of wifidog,
>>> but that remains to be seen, since RADIUS is used for wifi access...
>>>
>>> Therefore, it is possible, but would require more in depth work, that
>>> RADIUS would just be needed. What you really gain with RADIUS is a full
>>> integration with typical networking gear and then you get all the
>>> benefits of RADIUS infrastructures. It makes also load balancing,
>>> redundancy of the overall service simpler.
>>>
>>> therefore, "it depends".
>>>
>>> Marc.
>>>
>>>> Just my two cents....
>>>>
>>>> Bruno
>>>>
>>>>
>>>>
>>>>> Once again, the idea of a database abstraction was brought back to the
>>>>> discussion by Jimmy Godbout. Sylvain Carle finally pointed out that
>>>>> the deadline for a 2.0 release, which is due in September, makes that
>>>>> project unrealistic unless some people (organizations) can put some
>>>>> substantial efforts into it.
>>>>>
>>>>> This is a short summary of what is going on at the moment. I thought
>>>>> it would be relevant to post it on this list since this might a
>>>>> problem (if it is a problem at all !) that some of you have
>>>>> experienced. What solution have you chosen ? The everlasting question
>>>>> with wifidog-auth: Would that be a useful step to support MySQL as
>>>>> well ? Ans: probably yes. But now, how would that impact code
>>>>> complexity and how maintainable would that be ?
>>>>>
>>>>> Pierre-Luc Bacon
>>>>>
>>>>> ---------- Forwarded message ----------
>>>>> From: Marc Blanchet <marc.blanchet at viagenie.ca>
>>>>> Date: 2009/5/25
>>>>> Subject: Re: [AllianceCSF] Que pensez-vous de Slony-I
>>>>> To: Alliance des groupes sans-fil communautaires
>>>>> <alliancecsf at diffusion.zapquebec.org>
>>>>>
>>>>>
>>>>> Helene Gauthier a écrit :
>>>>>> On peut discuter longuement sur le sujet, comme le font ces derniers
>>>>>>
>>>>>> http://www.xaprb.com/blog/2008/05/18/why-is-mysql-more-popular-than-postgresql/
>>>>>>
>>>>>>
>>>>>> parfois, les discussions sont plus houleuses....
>>>>>>
>>>>>> http://www.developpez.net/forums/d26350/bases-donnees/postgresql/replication-postgresql-master-mysql-slave/
>>>>>>
>>>>>>
>>>>>> mais les réponses intéressantes
>>>>>>
>>>>>> Que pensez-vous de Slony-I
>>>>>>
>>>>>> http://www.slony.info/
>>>>> l'as-tu essayé?  (car, dans ce cas, comme souvent, il faut tester et
>>>>> essayer pour s'assurer que ça fait la route...)
>>>>>
>>>>> (contexte: pour zapquebec, on a fait une config de redondance des
>>>>> serveurs d'authentification. On a étudié toutes les solutions de
>>>>> redondance BD disponible sur postgres (slony, mammoth, warm standby,
>>>>> ...) et c'est super-pénible, pas toujours bien supporté, ne fait pas ce
>>>>> qu'on a besoin, ... ).
>>>>>
>>>>> slony:
>>>>> - ne réplique pas les changements de schéma (e.g. ALTER TABLE).
>>>>> - Les deux serveurs doivent être dans la même timezone.
>>>>> - Le master doit pouvoir se connecter au client, contrairement à MySQL.
>>>>> - Très complexe.
>>>>> - slony n'est pas intégré dans postgres, alors que c'est complètement
>>>>> intégré dans mysql.
>>>>> - Il faut spécifier une primary key pour chaque table. pas supporté
>>>>> dans
>>>>> wifidog actuel.
>>>>>
>>>>> si une réécriture de wifidog est considérée, certaines des limitations
>>>>> des solutions de réplication de postgres peuvent être "résolues".
>>>>>
>>>>> encore une fois: il y a de multiples façons de faire de la redondance
>>>>> pour le système au complet. S'attarder à la redondance uniquement de la
>>>>> BD n'est pas suffisant. On peut perdre de vue l'ensemble. Et il
>>>>> faudrait
>>>>> identifier quels sont les besoins réel de redondance dans la "nouvelle"
>>>>> architecture (surtout avec RADIUS dans le décor). Peut-être que le
>>>>> résultat est que nous n'avons pas besoin de redondance BD et que le
>>>>> point de comparaison Postgres/MySQL sur la redondance BD devient
>>>>> non-pertinent. Encore une fois, il faut regarder l'ensemble de la
>>>>> problématique.
>>>>>
>>>>> Je réécris mon point original: la réplication MySQL est beaucoup plus
>>>>> facile à implanter que postgres. (Je parle juste avec assez
>>>>> d'expérience
>>>>> de déploiement d'applications MySQL/postgres... en production. Et la
>>>>> réplication MySQL est un charme: pour une config async-write avec
>>>>> slaves, 3 lignes de config et c'est fonctionnel. vraiment.)
>>>>>
>>>>> Faudrait faire une "architecture" de la solution, après identifier les
>>>>> endroits nécessaires pour la redondance avec les exigences. Ensuite, on
>>>>> pourra mieux discuter des particularités des solutions.
>>>>>
>>>>> Marc.
>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : alliancecsf-bounces at diffusion.zapquebec.org
>>>>>> [mailto:alliancecsf-bounces at diffusion.zapquebec.org] De la part de
>>>>>> Marc Blanchet
>>>>>> Envoyé : 25 mai 2009 13:38
>>>>>> À : Alliance des groupes sans-fil communautaires
>>>>>> Objet : Re: [AllianceCSF] PHP ou PostGreSQL ?
>>>>>>
>>>>>> Jimmy Godbout a écrit :
>>>>>>> Pourquoi ne pas utiliser une couche d'abstraction ? De cette
>>>>>>> façon, le type de bd n'aura pas vraiment d'importance.
>>>>>>>
>>>>>> - bien sûr... mais la réalité te rattrape souvent:
>>>>>>  + tu veux utiliser telle ou telle fonctionalité disponible seulement
>>>>>> sur la BD que tu utilises.
>>>>>>  + un programmeur, plus tard, ajoute une toute petite fonctionalité
>>>>>> mais
>>>>>> qui, sans que le programmeur le sache, est spécifique à la BD
>>>>>> (genre un
>>>>>> énoncé SQL spécifique à la BD). un an plus tard, tu veux changer la BD
>>>>>> et tu te retrouves avec un paquet de code qui n'est pas transportable
>>>>>> facilement. Tu n'es jamais cuit, mais souvent, finalement, tu ne fais
>>>>>> pas le changement car moins prioritaire que d'autres besoins.
>>>>>> - bref, 100% d'accord avec toi, mais en même temps, se souvenir que
>>>>>> souvent, avec le temps, on devient coincé dans un seul "produit"
>>>>>> - une autre fois, tu installes une nouvelle version d'un produit pour
>>>>>> bénéficier d,une nouvelle fonctionalité (ex: redondance). Cela n'a pas
>>>>>> d'impact sur la programmation et sur la couche d'abstraction, mais ça
>>>>>> fait que tu restes pris avec le produit. Oui, la programmation reste
>>>>>> indépendante, mais le résultat est le même: c'est plus compliqué de
>>>>>> changer de BD.
>>>>>>
>>>>>> Il est aussi évident que la redondance, il faut bien identifier ce
>>>>>> qu'on
>>>>>> veut faire. Par exemple, si on prend RADIUS, la redondance pour
>>>>>> l'authentification/provisionning des users peut se faire par
>>>>>> l'infrastructure des serveurs RADIUS.
>>>>>>
>>>>>> bref, il y a de multiples facettes.
>>>>>>
>>>>>> Je voulais juste mentionner que MySQL devance largement postgres
>>>>>> pour la
>>>>>> fonctionalité de la réplication. Et donc à tenir compte dans le choix.
>>>>>>
>>>>>> Marc.
>>>>>>
>>>>>>> Jimmy
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: bremy at zapquebec.org
>>>>>>>> Sent: Mon, 25 May 2009 12:40:35 -0400
>>>>>>>> To: alliancecsf at diffusion.zapquebec.org
>>>>>>>> Subject: Re: [AllianceCSF] PHP ou PostGreSQL ?
>>>>>>>>
>>>>>>>> Merci Marc : c'est un argument qui (à mes yeux au moins...) à une
>>>>>>>> bien + grande importance que les tendances mondiales sur les
>>>>>>>> outils de
>>>>>>>> base de données. Car c'est "trés risqué" de bâtir une belle
>>>>>>>> infrastructure Wifidog 2.0 flambant-neuve, stable et user-friendly,
>>>>>>>> mais qui demande des efforts humains compliqués lors de redondance
>>>>>>>> d'un serveur à un autre :
>>>>>>>> Quand un serveur de PROD tombe... les minutes sont longues et
>>>>>>>> précieuses.... avant de basculer au serveur de relève :
>>>>>>>> pensez-y à deux fois ;0))))
>>>>>>>>
>>>>>>>> Bruno
>>>>>>>> PS : n'y voyez là aucune critique ...je ne suis pas programmeur..,
>>>>>>>> mais je m'occupe des opérations et la disponibilité du service est à
>>>>>>>> mes yeux + importante que l'architecture en-dessous ;)))
>>>>>>>>
>>>>>>>>
>>>>>>>> Message originalMarc Blanchet <marc.blanchet at viagenie.ca>:
>>>>>>>>
>>>>>>>>> pour votre information, assurer la redondance de la BD avec
>>>>>>>>> postgresql
>>>>>>>>> est 100 fois plus compliqué qu'avec MySQL. Avec MySQL, 3 lignes de
>>>>>>>>> configs, 5 min max et c'est réglé.
>>>>>>>>>
>>>>>>>>> Marc.
>>>>>>>>>
>>>>>>>>> Frédéric Sheedy a écrit :
>>>>>>>>>> Bonjour,
>>>>>>>>>>
>>>>>>>>>> Je suis plutôt du même avis que Hélène, postgreSQL semble de
>>>>>>>>>> plus en
>>>>>>>>>> plus populaire, surtout à cause des performances et des standards
>>>>>>>>>> respectés par postgreSQL.
>>>>>>>>>>
>>>>>>>>>> Le seul problème, c'est que Wordpress n'a pas encore pris en
>>>>>>>>>> charge
>>>>>>>>>> postgreSQL, et cela risque de prendre du temps, beaucoup de temps.
>>>>>>>>>>
>>>>>>>>>> -- 
>>>>>>>>>> Frédéric Sheedy
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Le 24 mai 2009 09:03, Helene Gauthier
>>>>>>>>>> <webmaster at zapbas-saint-laurent.org> a écrit :
>>>>>>>>>>> Bonjour,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Lors des derniers échanges, j?ai cru comprendre qu?il y a des
>>>>>>>>>>> discussions
>>>>>>>>>>> entre conserver PostGreSQL pour Wifidog ou Migrer vers MySQL
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> En ce qui me concerne, cela ne fait pas de différence
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> par contre si on pense à un avenir sur une durée de 5 ans, il
>>>>>>>>>>> faut
>>>>>>>>>>> tenir
>>>>>>>>>>> compte de l?avenir des deux bases en fonction des éventuels
>>>>>>>>>>> utilisateurs (de
>>>>>>>>>>> nouvelles zaps)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Difficile de dire lequel l?emportera !
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> MySQL est évidemment la base la plus utilisée dans le monde
>>>>>>>>>>> actuellement
>>>>>>>>>>> mais depuis l?acquisition de Sun par Oracle, il règne une
>>>>>>>>>>> certaine
>>>>>>>>>>> incertitude
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> http://www.zdnet.fr/actualites/informatique/0,39040745,39393180,00.htm
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> pgFoundry a développé tous les outils de migration de MySQL à
>>>>>>>>>>> PostGreSQL
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> http://pgfoundry.org/
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> PHPPgMyadmin est l?équivalent de PhpMyAdmin
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> http://phppgadmin.sourceforge.net/index.php
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> La documentation française est de plus en plus abondante
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> http://postgresql.fr/
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> WordPress envisage de gérer multiples bases de données dont
>>>>>>>>>>> PostGreSQL
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> « Puis-je Utiliser une Autre Base de Données que MySQL ?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Les autres bases de données ne sont pas supportées pour le
>>>>>>>>>>> moment.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Il existe de nombreux autres excellents gestionnaires de base de
>>>>>>>>>>> données,
>>>>>>>>>>> tels que PostgreSQL ou SQLite auquel WordPress s'intéresse
>>>>>>>>>>> pour les
>>>>>>>>>>> supporter dans le futur. Prendre en charge plusieurs bases de
>>>>>>>>>>> données
>>>>>>>>>>> est
>>>>>>>>>>> plus compliqué qu'il n'y paraît et ne fait pas partie des
>>>>>>>>>>> développements
>>>>>>>>>>> actuels, bien que de nombreuses discussions aient été engagées
>>>>>>>>>>> sur la
>>>>>>>>>>> meilleure approche à envisager. Ces approches pour augmenter
>>>>>>>>>>> le nombre
>>>>>>>>>>> de
>>>>>>>>>>> bases de données prises en charge sont étudiées dans l'article
>>>>>>>>>>> Utiliser des
>>>>>>>>>>> Bases de Données Alternatives (en anglais). Il existe un
>>>>>>>>>>> portage de
>>>>>>>>>>> WordPress pour PostgreSQL appelé WordPress-Pg (en anglais). »
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> MediaWiki fonctionne déjà avec PostGreSQL
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> GForge qui intègre MailMan est un outil plus convivial que
>>>>>>>>>>> TRAC et
>>>>>>>>>>> offre
>>>>>>>>>>> gratuitement un espace de 75 M
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> http://gforgegroup.com/
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Il offre un espace gratuit de 75Mg avec 5 développeurs
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ?GForge Group is providing a free, 75MB GForge AS project space
>>>>>>>>>>> with up to 5
>>>>>>>>>>> developers and a subversion tree at http://gforge.com/. When you
>>>>>>>>>>> register an
>>>>>>>>>>> account, you can set up your project and be set as an
>>>>>>>>>>> administrator.
>>>>>>>>>>> Need
>>>>>>>>>>> more storage or project members? Add them at the Online Store.?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Joomla l?utilise
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> http://joomlacode.org/
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> et quelques autres?.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> http://gforgegroup.com/customerlist.php
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Je vois donc plus davantage à conserver PostGreSQL en fonction
>>>>>>>>>>> de la
>>>>>>>>>>> convivialité et de la gratuité d?un espace de développement de
>>>>>>>>>>> version
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Helene Gauthier
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Liste de diffusion «AllianceCSF»
>>>>>>>>>>> AllianceCSF at diffusion.zapquebec.org
>>>>>>>>>>> http://zapquebec.org/cgi-bin/mailman/listinfo/alliancecsf
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Liste de diffusion «AllianceCSF»
>>>>>>>>>> AllianceCSF at diffusion.zapquebec.org
>>>>>>>>>> http://zapquebec.org/cgi-bin/mailman/listinfo/alliancecsf
>>>>>>>>> -- 
>>>>>>>>> =========
>>>>>>>>> IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
>>>>>>>>> Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
>>>>>>>>> DTN news service: http://reeves.viagenie.ca
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Liste de diffusion «AllianceCSF»
>>>>>>>>> AllianceCSF at diffusion.zapquebec.org
>>>>>>>>> http://zapquebec.org/cgi-bin/mailman/listinfo/alliancecsf
>>>>>>>>>
>>>>>>>> -- 
>>>>>>>> Bruno Remy
>>>>>>>> ZAP Québec
>>>>>>>> _______________________________________________
>>>>>>>> Liste de diffusion «AllianceCSF»
>>>>>>>> AllianceCSF at diffusion.zapquebec.org
>>>>>>>> http://zapquebec.org/cgi-bin/mailman/listinfo/alliancecsf
>>>>>>> ____________________________________________________________
>>>>>>> FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
>>>>>>> Check it out at http://www.inbox.com/earth
>>>>>>> _______________________________________________
>>>>>>> Liste de diffusion «AllianceCSF»
>>>>>>> AllianceCSF at diffusion.zapquebec.org
>>>>>>> http://zapquebec.org/cgi-bin/mailman/listinfo/alliancecsf
>>>>> -- 
>>>>> =========
>>>>> IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
>>>>> Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
>>>>> DTN news service: http://reeves.viagenie.ca
>>>>>
>>>>> _______________________________________________
>>>>> Liste de diffusion «AllianceCSF»
>>>>> AllianceCSF at diffusion.zapquebec.org
>>>>> http://zapquebec.org/cgi-bin/mailman/listinfo/alliancecsf
>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Pierre-Luc Bacon
>>>>> http://pierreluc.aqra.ca
>>>>> _______________________________________________
>>>>> Liste de diffusion «AllianceCSF»
>>>>> AllianceCSF at diffusion.zapquebec.org
>>>>> http://zapquebec.org/cgi-bin/mailman/listinfo/alliancecsf
>>>>>
>>>>
>>>>
>>>
>>> -- 
>>> =========
>>> IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
>>> Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
>>> DTN news service: http://reeves.viagenie.ca
>>>
>>> _______________________________________________
>>> Liste de diffusion «AllianceCSF»
>>> AllianceCSF at diffusion.zapquebec.org
>>> http://zapquebec.org/cgi-bin/mailman/listinfo/alliancecsf
>>>
>>
>>
> 
> 

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca