Mmm, la solution présentée sur la page que tu indiques utilise EAP-PEAP avec MSCHAPv2.
La plupart des institution de la fédération eduroam utilisent une base d'authentification où les mots de passe sont conservés sous forme chiffrée non réversible (afin d'assurer à leurs utilisateur que ce mot de passe ne sera pas utilisé à leur insu).
Pour ces institutions l'authentification ne peut se faire avec MSCHAPv2 .... il leur faut EAP-TTLS PAP, ce que n'implémente pas Nokia jusqu'à présent ....
Si j'ai bien tout compris : le choix de nokia est d'autant plus incompréhensible que la programmation d'un client EAP-TTLS PAP semble bien plus simple que celle d'un client MSCHAPv2.
Je ne connais (Centreon / Nagios) que de nom, il m'est donc impossible de comparer. Olivier semble en savoir plus que moi la dessus.
Mais après avoir fait un tour sur le site de Centreon qui ajoute (si j'ai bien compris) des possibilités de collecte et de graphe de données (par exemple nombre d'octets reçus ou envoyés par une interface réseau) à Nagios ..... je peux assurer que je ne perdrai pas 1:10.000 de seconde à tenter de les comparer ... même à l'apéro du café du commerce.
Centreon semble être un joli cas de logiciel opencore (ou fauxpensource, ou neo propriétaire, ...) : un noyau de base libre et des fonctionnalités supplémentaires propriétaires ......
Je suis utilisateur et non marketeur ... comparer opennms/(nagios+centreon) reviendrait à comparer HP openview ou CA unicenter à OpenNMS... en pire puisque dans ces derniers cas on sait qu'on a affaire à des solutions propriétaires alors que dans le premier on allèche avec le coeur libre pour pouvoir capturer avec les fonctions supplémentaires...
Cela dit le plus simple et d'installer les deux solutions et de comparer le résultat .... tout en gardant à l'esprit que les philosophies des projets sont différentes ......
Si l'on veut un peu sortir de l'antagonisme microdaube -- openoffice (TeX rules !) :
Il eut été sans doute intéressant de creuser SMTP : le suivi des RFCs par les divers serveurs et clients en contact avec les MX de l'administration laisse souvent à désirer ....
Une transcription précise des MUST, SHOULD et autre MAY utilisés dans les RFCs me permettrait (en tant qu'administrateur d'un tel MX administratif) de justifier officiellement les rejets de messages que j'impose parfois à mes interlocuteurs : obligation de présence de l'entête Msg-Id par exemple ....
[^] # Re: Enfin !
Posté par bofhjr . En réponse à la dépêche Symbian bouge enfin !. Évalué à 1.
La plupart des institution de la fédération eduroam utilisent une base d'authentification où les mots de passe sont conservés sous forme chiffrée non réversible (afin d'assurer à leurs utilisateur que ce mot de passe ne sera pas utilisé à leur insu).
Pour ces institutions l'authentification ne peut se faire avec MSCHAPv2 .... il leur faut EAP-TTLS PAP, ce que n'implémente pas Nokia jusqu'à présent ....
Si j'ai bien tout compris : le choix de nokia est d'autant plus incompréhensible que la programmation d'un client EAP-TTLS PAP semble bien plus simple que celle d'un client MSCHAPv2.
[^] # Re: À part microdaube ... quelle lutte d'interop ?
Posté par bofhjr . En réponse à la dépêche Le Référentiel Général d'Interopérabilité enfin publié, mais.... Évalué à 1.
[^] # Re: Nagios vs OpenNMS
Posté par bofhjr . En réponse à la dépêche OpenNMS passe en version 1.7.4. Évalué à 0.
Mais après avoir fait un tour sur le site de Centreon qui ajoute (si j'ai bien compris) des possibilités de collecte et de graphe de données (par exemple nombre d'octets reçus ou envoyés par une interface réseau) à Nagios ..... je peux assurer que je ne perdrai pas 1:10.000 de seconde à tenter de les comparer ... même à l'apéro du café du commerce.
Centreon semble être un joli cas de logiciel opencore (ou fauxpensource, ou neo propriétaire, ...) : un noyau de base libre et des fonctionnalités supplémentaires propriétaires ......
Je suis utilisateur et non marketeur ... comparer opennms/(nagios+centreon) reviendrait à comparer HP openview ou CA unicenter à OpenNMS... en pire puisque dans ces derniers cas on sait qu'on a affaire à des solutions propriétaires alors que dans le premier on allèche avec le coeur libre pour pouvoir capturer avec les fonctions supplémentaires...
Cela dit le plus simple et d'installer les deux solutions et de comparer le résultat .... tout en gardant à l'esprit que les philosophies des projets sont différentes ......
[^] # Re: À part microdaube ... quelle lutte d'interop ?
Posté par bofhjr . En réponse à la dépêche Le Référentiel Général d'Interopérabilité enfin publié, mais.... Évalué à 2.
[^] # Re: jrb ?
Posté par bofhjr . En réponse à la dépêche OpenNMS passe en version 1.7.4. Évalué à 2.
# À part microdaube ... quelle lutte d'interop ?
Posté par bofhjr . En réponse à la dépêche Le Référentiel Général d'Interopérabilité enfin publié, mais.... Évalué à 2.
Il eut été sans doute intéressant de creuser SMTP : le suivi des RFCs par les divers serveurs et clients en contact avec les MX de l'administration laisse souvent à désirer ....
Une transcription précise des MUST, SHOULD et autre MAY utilisés dans les RFCs me permettrait (en tant qu'administrateur d'un tel MX administratif) de justifier officiellement les rejets de messages que j'impose parfois à mes interlocuteurs : obligation de présence de l'entête Msg-Id par exemple ....
[^] # Re: Enfin !
Posté par bofhjr . En réponse à la dépêche Symbian bouge enfin !. Évalué à 2.