[isf-wifidog] Matière à réflexion...
Marc Blanchet
marc.blanchet at viagenie.ca
Mar 26 Mai 10:39:10 EDT 2009
Helene Gauthier a écrit :
> 3 - Réplication PostgreSQL "difficile" mais réalisée par ZAP Québec et opérationnel
on ne fait aucune réplication PostGreSQL présentement. On a un serveur
de redondance qui reçoit périodiquement une copie (complète) de la BD
via un transfert de fichier. C'est le mieux qu'on pouvait faire et ce
n'est définitivement pas acceptable pour un nouveau développement.
>
> Les CMS
moi, je crois que wifidog, lui-même, ne devrait pas contenir de CMS. le
CMS devrait être complètement à part, séparé, indépendant. La partie
wifidog qui roule sur les zaps ne devrait qu'être un routeur qui:
- intercepte la communication initiale
- montre une/des page web qui vient d'un autre serveur (lui-même géré
par le CMS que tu veux, ou même pas de CMS du tout);
- tant que tu n'es pas authentifié, tu peux juste accéder à ce serveur web.
- après entrée du username/password de l'usager via la page web, la zap
fait une requête RADIUS à un serveur RADIUS qui authentifie le client.
- si authentifié, les règles de sécurité sont relâchées pour cet usager,
pour qu'il puisse accéder à Internet.
- on a un client openvpn sur les zaps, pour accéder à distance.
- on a un agent SNMP sur les zaps avec un polling sur une station snmp
avec toutes les stats possibles et imaginables, graphiques, etc...
ça fait que:
- wifidog client est super super simple, encore plus simple que celui
actuel.
- que wifidog-auth n'est presque qu'un proxy web-radius. 100 fois plus
simple que le code actuel de wifidog-auth.
- et que toute la logique authentification est faite dans radius. Tu
peux même avoir des clés securid si tu veux! Tu peux assigner un préfixe
IPv6 si tu veux avec RADIUS!
- la redondance et tout le backend est basé sur RADIUS, avec de
multiples options
- le protocole RADIUS est standard, alors tu peux utiliser plusieurs
implémentations open-source ou commerciales.
- on utilise des patentes (radius, snmp, openvpn) qui sont utilisées
dans l'industrie, prouvées fonctionelles et stables, avec de multiples
implémentations, ...
- le côté portail est en dehors de wifidog et donc tout le monde peut
utiliser son CMS, sa BD, son wiki qu'il veut. Et si tout le monde veut
normaliser sur quelque chose, alors c'est possible, mais pas obligatoire.
- on arrête les débats sur quel CMS, quelle BD, quel wiki, quel ...
Bon, j'arrête-là.
Marc.
>
> WordPress souligne qu'ils veulent gérer plusieurs base de données
>
> Est-il plus facile de migrer WordPress vers PostGreSQL que l'inverse ?
>
> Travailler sur un tel projet rendrait wifidog plus populaire encore en étant les instigateurs de cette migration
>
> Les CMS ayant PostGreSQL
>
> Joomla
> Drupal
> Post-Nuke
>
> Les Wiki supportant PostGreSQL
>
> MediaWiki
> PhpWiki
>
> Forums
>
> PhpBB
>
> Serait-il possible d'utiliser Joomla ou Drupal au lieu de WordPress pour l'intégration ?
>
>
> -----Message d'origine-----
> De : wifidog-bounces at listes.ilesansfil.org [mailto:wifidog-bounces at listes.ilesansfil.org] De la part de Marc Blanchet
> Envoyé : 26 mai 2009 08:55
> À : Alliance des groupes sans-fil communautaires
> Cc : WiFiDog Captive Portal
> Objet : Re: [isf-wifidog] [AllianceCSF] postgresql vs mysql, get into the flamebait
>
> 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
Plus d'informations sur la liste de diffusion WiFiDog