Ludovic Marcotte a écrit 34 commentaires

Les spécifications techniques de ces deux plateformes ne permettent probablement pas à PacketFence de fonctionner convenablement. Un minimum de 8Go de mémoire est requis, mais 12Go est préférable. De plus, il faudrait compiler les binaires que nous générons (en Golang) pour l'architecture ARM - chose que nous ne faisons pas.

PacketFence n'a pas pour objectif de remplacer un routeur ou un coupe-feu, il étend plutôt ces fonctionnalités.

Finalement, PacketFence utilise Netdata pour la visualisation des données - mais il serait possible d'envoyer ces données vers InfluxDB/Grafana.

Oui!

Bonjour! Je serais ouvert à faire une interview.

Si le matériel réseau (filaire et sans fil) est solide, la solution est facile à administrer et va très bien fonctionner. Le niveau d'attention que la solution va demander sera très faible.

Bonjour,

Cela varie selon la technologie VPN utilisée. Si le serveur VPN peut faire du "WebAuth" - comme les Cisco ASA, oui c'est possible. Par contre, plusieurs VPN n'offrent pas cette fonctionnalité - comme les Fortigate par exemple.

Il est aussi possible d'utiliser un réseau "inline" dans PacketFence et faire passer le traffic VPN par PacketFence. Ceci va très bien fonctionner en niveau 2 et 3 et si surtout PacketFence est le serveur DHCP pour les clients VPN. Si les clients VPN ont des IPs statiques, il faudra utiliser la fonctionnalité de génération de "fake MACs" par PacketFence en fonction d'une IP statique.

Au plaisir,

Bonjour,

Nous venons tout juste de sortir la version 3.0.1 qui contient plusieurs petits correctifs.

Le tout est bien entendu disponible sur http://sogo.nu

Merci!

C'est codé en Objective-C (partie serveur) + JavaScript (partie client).

Au plaisir,

Merci pour vos commentaires positifs, c'est très apprécié.

Pour un réseau domestique, je crois que c'est trop comme solution. C'est comme vouloir utiliser un ERP pour gérer ses finances personnelles - quoique certaines personnes pourraient en avoir besoin ;-)

PacketFence propose plusieurs processus d'enregistrement d'appareils sur le réseau. Comme par exemple, en utilisant un simple compte Active Directory, une adresse courriel, un numéro de téléphone cellulaire (pour SMS), un parrain, un compte Facebook/G+ (pour OAuth2) et plus encore. Le tout permet ensuite de déterminer le bon rôle à fournir à l'appareil et son utilisateur - ce qui est fondamental pour établir une bonne politique BYOD.

Exactement!

En fait les "branches" v1.3 et 2.0 sont identiques :-)

SOGo v2 c'est vraiment v1.3.18 avec quelques améliorations mais surtout, avec la compatibilité Outlook officiellement supportée. Donc une personne qui n'utilise que SOGo peut très facilement passer à la version 2.0 et verra quelques améliorations cosmétiques, correctifs et autres.

Par contre, celui qui veut utiliser Outlook peut maintenant le faire de façon "finale", en suivant bien entendu notre documentation.

Merci!

C'est enfin prêt!

Voir: http://sourceforge.net/mailarchive/forum.php?thread_name=4F995E27.5040409%40inverse.ca&forum_name=packetfence-users

Oui, ils sont prêts! Nous allons annoncer le tout probablement aujourd'hui, dans la liste de diffusion de PacketFence (packetfence-users). Merci,

C'est indiqué sur la page principale de sogo.nu, l'annonce officielle de 2.0.0beta1, la section Overview et la section Features.

Notre objectif est de sortir des paquets pour Debian/Ubuntu pour la prochaine version.

Bonjour,

Nous venons tout juste de rendre disponible la version 2.0 de PacketFence sous forme de "ZEN" - donc une image virtuelle (VMWare) préinstallée / préconfigurée.

Vous pouvez récupérer le tout du lien suivant :

http://www.packetfence.org/download/vmware_appliance_zen.htm(...)

La documentation sur la ZEN peut être téléchargée à partir du lien suivant :

http://www.packetfence.org/documentation/guides.html

Vous pouvez utiliser cela ou du 802.1X avec PEAP, certificats, etc.

C'est vous qui décidez après tout - PacketFence supporte parfaitement tous ces mécanismes.

Par exemple, l'authentifcation par adresse MAC peut être très pratique pour réseau sans fil pour invités. Ces derniers, après authentification sur le portail captif (avec code utilisateur / mot de passe pour invité, valide par exemple pour 4 heures), pourront avoir accès à un VLAN avec accès restreints (Internet seulement, avec limitation de la bande passante).

Ca l'évite de devoir configurer une connexion WPA/WPA2 et fournir une multitude de paramètres de configuration à un utilisateur qui ne veut, après tout, avoir un accès Internet pour un laps de temps.

Si un seul serveur avait de la difficulté à gérer un petit réseau, c'est que sa configuration n'était pas optimale. Un seul serveur PacketFence peut gérer des milliers d'ordinateurs en même temps. Inverse a fait plusieurs déploiements où un seul serveur actif gère près de 10 000 ordinateurs actifs.

Quant au portail captif, c'est normal qu'il soit de base dans la solution livrée, de base car c'est l'une des parties qui doit être le plus personnalisé dans tout déploiement. Le chainage des méthodes d'authentification est aussi tout à fait possible dans la personnalisation de la solution. De plus, tout le traffic de la socitété n'a bien entendu pas besoin de passer par PacketFence. PacketFence fonctionne parfaitement en monde "out of band".

Un NAC n'est PAS une solution triviale à deployer (car elle touche au coeur du réseau) et elle ne s'adresse pas aux très petites sociétés (sous 100-150 ordinateurs, ca veut rarement l'effort).

La version 2.0 apporte beaucoup d'améliorations, surtout au processus de déploiement et la version "ZEN" pour 2.0 devrait être disponible aujourd'hui.

Les identifiants dans la base de données sont justement pour permettre à SOGo d'aller se connecter à d'autres base de données pour son fonctionnement.

Par exemple, vous pourriez avoir 10 000 utilisateurs sur une base de données et 10 000 autres sur une autre. Ceci est pratique dans des grands déploiements où il y a une base de données par emplacement géographique et que les liens interconnectant le tout ne sont pas très rapides...

Pour la structure des tables, elle est très simple en fait. Il y a une table "quick" où l'on conserve certains éléments extraits des événements / tâches / contacts. Cette table est réservée aux consultations "rapides" - comme l'afficage des vues calendriers, la liste des événements, etc. Associée à la table "quick", il y a une table de contenu où l'on conserve la l'événement / tâche / contact _original_ - tel que reçu par SOGo donc nous évitons toutes transformations qui pourraient causer une perte d'informations.

Au niveau du nombre de tables, des systèmes comme PostgreSQL, Oracle et même MySQL n'ont aucun problème à en gérer plusieurs milliers, en autant bien entendu que la configuration soit bien adaptée au déploiement.

On corrigera le tir les prochaines fois - merci.

Le tout est sous GPL / LGPL / MPL.

L'offre de services d'Inverse est documenté dans les pages suivantes: http://www.inverse.ca/francais/services.html (voir les liens sécurité / portail / collecticiel / autres services).

Nous offrons aussi du support pour nos solutions SOGo et PacketFence (voir http://www.inverse.ca/francais/support.html)

Oui, la prochaine version supportera toutefois Thunderbird 3.

Pour ceux et celles qui suivent le développement de SOGo (http://www.scalableogo.org) et son intégration avec Thunderbird / Lightning, n'ayez craintes. Les extensions (Lightning, SOGo Connector et SOGo Integrator) seront disponibles très bientôt pour Thunderbird 3. Merci!

La prochaine version devrait permettre le DnD dans le module calendrier :-)