Oui ce serait possible, mais dans ce cas il faudra interfacer Z-Eye différement. Il faut savoir que Z-Eye enregistre ses données en base, et n'écrit pas les templates (qui ne sont qu'à titre informatifs dans cette version 1.0) dans la configuration Icinga.
Si la syntaxe est identique, il suffira simplement d'écrire les fichiers dans le répertoire qui va bien et d'inclure le fichier écrit par Z-Eye (pour Icinga, 4 fichiers seulements sont écrit, séparant les hôtes, services et commandes notamment, et ces fichiers sont inclus par la configuration principale Icinga, qui elle n'est pas réécrite). Si elle diffère eh bien il faudra voir si les attributs sont cohérents avec FAM, et garder/supprimer ceux qui ne sont pas nécessaires puis aller écrire les fichiers de la manière qui va bien. Je ne connais pas FAM, mais à mon avis il faudra réécrire le module de monitoring et le réinterfacer avec les quelques modules concernés (cartes, système d'affichage d'alertes et administration d'Icinga).
Pourquoi vouloir remplacer Icinga par autre chose ? Quel est ton besoin ? Utiliser un élément de monitoring existant ? Si c'est le cas, j'envisagerais peut être pour une version future un import de configuration si c'est viable, histoire de faciliter les choses à chacun.
La cartographie réseau que tu vois sur la présentation LinuxFr est générée via graphviz et un fichier .dot écrit par Z-Eye.
Je suis en train de basculer sur la librairie JS sigma pour réaliser une carte interactive qui affiche la carte réseau et la carte icinga en combiné, avec de la colorisation pour la charge des liens et le statut icinga de chaque équipement, mais pour l'instant je suis bloqué sur l'algorithme qui me permet de génerer proprement les coordonnées X et Y. (donc j'ai juste un superbe brouillons de points à coordonnées aléatoires dans l'immédiat :p)
Pour l'import shinken, c'est une bonne idée que tu évoques que de proposer l'import de commutateurs vers le système de monitoring. Je vais y penser pour Icinga, en rajoutant un import automatique des équipements existants. Pour la parenté depuis les données Netdisco j'émets une réserve dans le sens où elle peut faire des graphes Icinga étranges si tu as des liens multiples et croisés entre équipements.
Merci pour le lien IPAM, je m'inspirerai de quelques données administratives intéressantes et promis j'intègre ca d'ici 1 ou 2 mois
Je ne te cache pas que le point faible de Z-Eye est la partie IDS. Même s'il est présent et fonctionne très bien, je ne peux pas fournir de sondes SNORT, la plupart sont soumises à des droits particuliers qui m'empêchent de les redistribuer. De ce fait il s'agit d'un éventail de sondes assez larges mais peut être pas suffisament précis pour des besoins de DC ? (ca je ne sais pas). De plus l'interface qui gère l'IDS est vraiment restreinte, cela n'a pas été ma priorité. Dans l'immédiat elle permet de modifier rapidement les variables qui définissent les différents protocoles courants (HTTP,SMTP,SNMP,SSH…) et serveurs associés.
De plus les algorithmes qui vont de la collecte jusqu'à l'affiche sont assez lourds (SNORT => Barnyard => PG => ACID => PG => Z-Eye => PG). J'aimerais pouvoir les simplifier en me passant de base mais pour le moment je suis plus sur la partie réseau.
En ce qui concerne l'administration de commutateurs, comme je l'ai dit pour le moment il s'agit de commutateurs CISCO, mais mon API permet d'utiliser SSH et de créer un module pour chaque constructeur, ce qui te permet d'utiliser des fonctions "standards" qui lanceront des commandes plus spécifiques sur chaque commutateurs (tu peux faire de l'hybride SNMP/SSH d'ailleurs). Cette spécificité CISCO n'impacte pas la collecte de données qui elle se fait avec des outils de collecte plus complets (Netdisco/MRTG).
Concernant la gestion DHCP/DNS pour le moment il s'agit juste de collecte, mais promis je vais voir pour interfacer ca une fois la 1.1 stabilisée, validée et publiée. Il te faudra peut être attendre 1 à 2 mois le temps que je développe ca comme il faut et que je sois certain de la stabilité/sécurité du code. (donc mai/juin). Ceci ne t'empêche pas de pouvoir l'utiliser dès maintenant et d'upgrader plus tard quand de nouvelles fonctions apparaîtront. (l'ensemble est très facile à upgrader et je donne toujours des instructions exactes de mises à jour de DB, fichiers).
J'avoue comme toi que ce qui pèche c'est effectivement la partie réseau où l'on trouve beaucoup de proprio, c'est à cause de ce besoin aussi que j'ai décidé d'agrandir Z-Eye et d'en faire une application "publique", au lieu de la garder au chaud dans mon institution CNRS.
Solarwinds est un peu plus poussé, peut être plus réservé pour une entreprise multinationale (surtout pour la partie réseau). Je ne sais pas l'échelle de ton entreprise mais pour une petite ou moyenne structure Z-Eye est actuellement très bien adapté (nous avons 45 serveurs, 75 commutateurs (~2500 ports) et 1 coeur de réseau). Les performances de Z-Eye dépendront essentiellement du disque (qui va subir énormément d'écritures pendant les différentes collectes, surtout SNORT). Dans mon cas cela tourne sur un Dell R210 sur le Raid système et ca tourne comme un charme.
Pour la partie IPAM, ce n'est pas encore intégré, pour le moment la distrib se contente de collecte, mais si le besoin s'en fait ressentir je la prévois pour la 1.2 (elle m'est également demandée par mon chef qui aimerait que nos techniciens puissent modifier adresses dans le DHCP).
Pour les performances réseau, Z-Eye utilise MRTG, les données sont collectées de manière active sur les différents équipements. La partie Netflow n'est pas interfacée, mais cela pourrait être une amélioration pour l'avenir, il suffirait de trouver le logiciel qui va bien (peut être est-il déjà présent dans la distrib) et de l'interfacer.
L'avantage certain de Z-Eye c'est qu'il est totalement en web et qu'il est possibilie de définir des droits (avec une granularité illimitée, il suffit juste de rajouter la notion de droit au bon endroit avec le bout d'interface pour pouvoir le gérer). La plupart des outils que tu cites utilisent des clients lourds et forcément Windows.
As tu des fonctions spécifiques en tête qui te seraient essentielles et présentes dans ces produits ?
Effectivement, Z-Eye a pour but à la fois de monitorer le réseau et d'offrir de la sécurité par la visibilité d'évènements (systèmes => icinga, sécurité => SNORT), mais également de pouvoir gérer le réseau et ses éléments fondateurs.
Elle est très bien la syntaxe de PF. De plus si tu es dans un écosystème BSD c'est toujours bien de retrouver la même façon de procéder pour le filtrage (cd OpenBGPD qui utilise le même type de syntaxe pour la distribution des routes).
malheureusement wine reste encore de la bidouille pour le gamer commun, même avec play on linux. Et steam ne peut pas être le seul, les autres éditeurs (EA, Activision et j'en passe) doivent aussi faire le pas.
Intel n'est pas un gros constructeur de cartes graphiques, malheureusement.
Crusaders kings déconne sur ma 5450M (et le catalyst ne marche pas avec…), j'ai une sorte de brouillage vert étrange sur toutes les textures et du lag. Sur ma 7970 avec les drivers proprio aucun problème.
Je valide sous Archlinux, j'ai acheté Serious Sam 3 (on ne peut pas dire que CSS est gourmant) histoire de faire fonctionner à fond la carte graphique (catalyst) , ca tourne comme un charme
Je félicite les designer du projet pour la qualité visuelle du produit, c'est vraiment joli.
Reste à voir ensuite comment ce genre d'outil pourrait proliférer sur la toile, là où le centralisé domine et les gens n'ont pas la notion de "garder ses données chez soi"
Le freeze de l'interface lors de la recherche DNS ? J'ai effectivement entendu parler de ce problème, mais je ne l'ai jamais rencontré au boulot. Ca arrive lors de connexions lentes ?
La plupart des professionnels de santé s'en servent pour ~~crypter~~ **chiffrer** des échanges de documents médicaux ou pour signer les feuilles de soin électroniques.
Attention on dit chiffrer et non crypter :(
Chapeau bas pour l'insertion du logiciel libre de manière aussi approfondie en médecine, je ne savais pas qu'il y en avait autant :)
Bonsoir Martin, je tiens à te féliciter, il est rare de voir de jeunes étudiants Français aussi motivés. J'espère que tu sauras amener avec toi d'autres étudiants pour les développements dans le monde du logiciel libre, surtout avec ce qui se prépare sur Bordeaux en ce moment ! Merci pour tes contributions, qui serviront sur le moyen terme à tous.
Roundcude (0.7 et 0.8) intégré à Owncloud fonctionne parfaitement, il faut utiliser un système d'autologin roundcube. Je n'ai plus les informations mais c'est ce qui permet que roundcube authentifie l'utilisateur directement et qu'il aie accès à l'interface.
6.0 suit 5.9 tout comme pour OpenBSD, et cela semble logique vu que c'est la même personne à sa tête, la version suivant 4.9 est 5.0, logique différente.
On aurait pu s'appeler SSH release 60 qui suit le release 59. Chez OpenBSD et donc OpenSSH, on ne privilégie pas le chiffre ni la quantité mais la qualité du release
oui c'est sûr que ca fait doublons, je pense que c'est pour montrer l'évolution au fur et à mesure des packages qu'ils ont choisi. Enfin c'est la politique OpenBSD, la communication n'est pas leur fort, ce sont leurs idées :)
si tu trouve ca léger, je te suggère de lire ce changelog (ca m'a pris environ 40 minutes le jour de la sortie, surtout vu que c'est trié par ordre chronologique je présume)
très bonne conférence des jres, merci Patrick, je l'avais vue en live stream depuis mon bureau, cela m'a vraiment motivé à faire avancer le réseau que j'administre sur IPv6 (par ailleurs je suis en train d'étudier la migration de mes dual routeurs Debian + Squid NTLM + UCARP sur OpenBSD 5.1, et c'est très bien parti, surtout vu les packages du repo 5.1 qui sont pile dans les versions que j'attendais)
systemd est plus puissant dans sa gestion des services.
Il gère les services en target et non plus en runlevel. De plus il gère des dépendances entre service alors que sur systemV et upstart c'est le chiffre qui définit qui démarre en premier. Avec systemD tu as également la parallélisation du démarrage et de l'extinction des services suivant cette dépendances.
Par exemple admettons que tu as l'arbre de dépendances suivant:
En bien systemD va démarrer syslog, car ne dépendant de rien, puis le démon réseau, ensuite les 3 services apache mysql et OpenLDAP en parallèle. Freeradius démarrera quand ton MySQL et ton LDAP seront UP
Ca c'est pour le démarrage, mais sinon en terme de gestion systemD se rapproche beaucoup des cgroups et c'est très puissant. En revanche pas pour le commun des mortels, mais dans un environnement de production fort sollicité oui.
Tout à fait, le comble c'est notre bâtiment à Palaiseau. A environ 100m tu le vois comme maintenant et si tu zoome, à 50m tu le vois en construction (il y a le trou pour les fondations xD)
La différence entre les noyaux est effectivement la compatilibilité matérielle et le changement dans le code de certains sous systèmes du noyau, notamment. Un Noyau LTS sera patché pour combler des failles de sécurité et/ou stabiliser certains éléments. Si tu souhaite supporter des devices plus récents tu devras forcément passer à un noyau supérieur.
Pour passer au patchset suivant, tu peux recompiler le noyau, effectivement, en le patchant dans un premier temps, puis en recompilant celui-ci ainsi le userland.
La plupart du temps les patchsets sont appliqués en majorité sur le userland, tout du moins sur 8.2 c'est ce que j'ai pu observer.
Si tu ne compiles pas ton noyau, ce qui est fortement envisageable et conseillé dans un environnement de production ne nécessitant pas l'optimisation des appels système, il suffit simplement de taper freebsd-update fetch install ce qui aura pour effet d'inspecter et passer ton système de 8.2-p4 à 8.2-p6 par exemple. Il faudra en revanche rebooter pour que le nouveau noyau soit pris en compte, tout comme sous Linux.
[^] # Re: Produits solarwinds
Posté par Loïc Blot (site web personnel) . En réponse à la dépêche Z-Eye, gestion réseau et monitoring unifié. Évalué à 2.
Oui ce serait possible, mais dans ce cas il faudra interfacer Z-Eye différement. Il faut savoir que Z-Eye enregistre ses données en base, et n'écrit pas les templates (qui ne sont qu'à titre informatifs dans cette version 1.0) dans la configuration Icinga.
Si la syntaxe est identique, il suffira simplement d'écrire les fichiers dans le répertoire qui va bien et d'inclure le fichier écrit par Z-Eye (pour Icinga, 4 fichiers seulements sont écrit, séparant les hôtes, services et commandes notamment, et ces fichiers sont inclus par la configuration principale Icinga, qui elle n'est pas réécrite). Si elle diffère eh bien il faudra voir si les attributs sont cohérents avec FAM, et garder/supprimer ceux qui ne sont pas nécessaires puis aller écrire les fichiers de la manière qui va bien. Je ne connais pas FAM, mais à mon avis il faudra réécrire le module de monitoring et le réinterfacer avec les quelques modules concernés (cartes, système d'affichage d'alertes et administration d'Icinga).
Pourquoi vouloir remplacer Icinga par autre chose ? Quel est ton besoin ? Utiliser un élément de monitoring existant ? Si c'est le cas, j'envisagerais peut être pour une version future un import de configuration si c'est viable, histoire de faciliter les choses à chacun.
Veepee & UNIX-Experience
[^] # Re: Produits solarwinds
Posté par Loïc Blot (site web personnel) . En réponse à la dépêche Z-Eye, gestion réseau et monitoring unifié. Évalué à 2.
La cartographie réseau que tu vois sur la présentation LinuxFr est générée via graphviz et un fichier .dot écrit par Z-Eye.
Je suis en train de basculer sur la librairie JS sigma pour réaliser une carte interactive qui affiche la carte réseau et la carte icinga en combiné, avec de la colorisation pour la charge des liens et le statut icinga de chaque équipement, mais pour l'instant je suis bloqué sur l'algorithme qui me permet de génerer proprement les coordonnées X et Y. (donc j'ai juste un superbe brouillons de points à coordonnées aléatoires dans l'immédiat :p)
Pour l'import shinken, c'est une bonne idée que tu évoques que de proposer l'import de commutateurs vers le système de monitoring. Je vais y penser pour Icinga, en rajoutant un import automatique des équipements existants. Pour la parenté depuis les données Netdisco j'émets une réserve dans le sens où elle peut faire des graphes Icinga étranges si tu as des liens multiples et croisés entre équipements.
Merci pour le lien IPAM, je m'inspirerai de quelques données administratives intéressantes et promis j'intègre ca d'ici 1 ou 2 mois
Veepee & UNIX-Experience
[^] # Re: Produits solarwinds
Posté par Loïc Blot (site web personnel) . En réponse à la dépêche Z-Eye, gestion réseau et monitoring unifié. Évalué à 5.
Je ne te cache pas que le point faible de Z-Eye est la partie IDS. Même s'il est présent et fonctionne très bien, je ne peux pas fournir de sondes SNORT, la plupart sont soumises à des droits particuliers qui m'empêchent de les redistribuer. De ce fait il s'agit d'un éventail de sondes assez larges mais peut être pas suffisament précis pour des besoins de DC ? (ca je ne sais pas). De plus l'interface qui gère l'IDS est vraiment restreinte, cela n'a pas été ma priorité. Dans l'immédiat elle permet de modifier rapidement les variables qui définissent les différents protocoles courants (HTTP,SMTP,SNMP,SSH…) et serveurs associés.
De plus les algorithmes qui vont de la collecte jusqu'à l'affiche sont assez lourds (SNORT => Barnyard => PG => ACID => PG => Z-Eye => PG). J'aimerais pouvoir les simplifier en me passant de base mais pour le moment je suis plus sur la partie réseau.
En ce qui concerne l'administration de commutateurs, comme je l'ai dit pour le moment il s'agit de commutateurs CISCO, mais mon API permet d'utiliser SSH et de créer un module pour chaque constructeur, ce qui te permet d'utiliser des fonctions "standards" qui lanceront des commandes plus spécifiques sur chaque commutateurs (tu peux faire de l'hybride SNMP/SSH d'ailleurs). Cette spécificité CISCO n'impacte pas la collecte de données qui elle se fait avec des outils de collecte plus complets (Netdisco/MRTG).
Concernant la gestion DHCP/DNS pour le moment il s'agit juste de collecte, mais promis je vais voir pour interfacer ca une fois la 1.1 stabilisée, validée et publiée. Il te faudra peut être attendre 1 à 2 mois le temps que je développe ca comme il faut et que je sois certain de la stabilité/sécurité du code. (donc mai/juin). Ceci ne t'empêche pas de pouvoir l'utiliser dès maintenant et d'upgrader plus tard quand de nouvelles fonctions apparaîtront. (l'ensemble est très facile à upgrader et je donne toujours des instructions exactes de mises à jour de DB, fichiers).
J'avoue comme toi que ce qui pèche c'est effectivement la partie réseau où l'on trouve beaucoup de proprio, c'est à cause de ce besoin aussi que j'ai décidé d'agrandir Z-Eye et d'en faire une application "publique", au lieu de la garder au chaud dans mon institution CNRS.
Veepee & UNIX-Experience
[^] # Re: Produits solarwinds
Posté par Loïc Blot (site web personnel) . En réponse à la dépêche Z-Eye, gestion réseau et monitoring unifié. Évalué à 3.
Solarwinds est un peu plus poussé, peut être plus réservé pour une entreprise multinationale (surtout pour la partie réseau). Je ne sais pas l'échelle de ton entreprise mais pour une petite ou moyenne structure Z-Eye est actuellement très bien adapté (nous avons 45 serveurs, 75 commutateurs (~2500 ports) et 1 coeur de réseau). Les performances de Z-Eye dépendront essentiellement du disque (qui va subir énormément d'écritures pendant les différentes collectes, surtout SNORT). Dans mon cas cela tourne sur un Dell R210 sur le Raid système et ca tourne comme un charme.
Pour la partie IPAM, ce n'est pas encore intégré, pour le moment la distrib se contente de collecte, mais si le besoin s'en fait ressentir je la prévois pour la 1.2 (elle m'est également demandée par mon chef qui aimerait que nos techniciens puissent modifier adresses dans le DHCP).
Pour les performances réseau, Z-Eye utilise MRTG, les données sont collectées de manière active sur les différents équipements. La partie Netflow n'est pas interfacée, mais cela pourrait être une amélioration pour l'avenir, il suffirait de trouver le logiciel qui va bien (peut être est-il déjà présent dans la distrib) et de l'interfacer.
L'avantage certain de Z-Eye c'est qu'il est totalement en web et qu'il est possibilie de définir des droits (avec une granularité illimitée, il suffit juste de rajouter la notion de droit au bon endroit avec le bout d'interface pour pouvoir le gérer). La plupart des outils que tu cites utilisent des clients lourds et forcément Windows.
As tu des fonctions spécifiques en tête qui te seraient essentielles et présentes dans ces produits ?
Veepee & UNIX-Experience
[^] # Re: Security Onion
Posté par Loïc Blot (site web personnel) . En réponse à la dépêche Z-Eye, gestion réseau et monitoring unifié. Évalué à 3.
Effectivement, Z-Eye a pour but à la fois de monitorer le réseau et d'offrir de la sécurité par la visibilité d'évènements (systèmes => icinga, sécurité => SNORT), mais également de pouvoir gérer le réseau et ses éléments fondateurs.
Veepee & UNIX-Experience
[^] # Re: Plus simple que Postfix ?
Posté par Loïc Blot (site web personnel) . En réponse à la dépêche OpenSMTPD 5.3 est de sortie !. Évalué à 7.
Elle est très bien la syntaxe de PF. De plus si tu es dans un écosystème BSD c'est toujours bien de retrouver la même façon de procéder pour le filtrage (cd OpenBGPD qui utilise le même type de syntaxe pour la distribution des routes).
Veepee & UNIX-Experience
[^] # Re: Pub + Compatibilité
Posté par Loïc Blot (site web personnel) . En réponse au sondage Selon vous, pourquoi Linux n'est-il pas prêt pour le bureau ?. Évalué à 1.
malheureusement wine reste encore de la bidouille pour le gamer commun, même avec play on linux. Et steam ne peut pas être le seul, les autres éditeurs (EA, Activision et j'en passe) doivent aussi faire le pas.
Veepee & UNIX-Experience
[^] # Re: Pourquoi ?
Posté par Loïc Blot (site web personnel) . En réponse au journal x2go : le digne successeur de freenx. Évalué à 1.
idem aucun souci entre gnome 3.2, 3.4 et 3.6
Veepee & UNIX-Experience
[^] # Re: décollage bof
Posté par Loïc Blot (site web personnel) . En réponse à la dépêche Steam sous Linux x86/amd64 officialisé. Évalué à 1.
Intel n'est pas un gros constructeur de cartes graphiques, malheureusement.
Crusaders kings déconne sur ma 5450M (et le catalyst ne marche pas avec…), j'ai une sorte de brouillage vert étrange sur toutes les textures et du lag. Sur ma 7970 avec les drivers proprio aucun problème.
Veepee & UNIX-Experience
[^] # Re: Beta ?
Posté par Loïc Blot (site web personnel) . En réponse à la dépêche Steam sous Linux x86/amd64 officialisé. Évalué à 1.
Je valide sous Archlinux, j'ai acheté Serious Sam 3 (on ne peut pas dire que CSS est gourmant) histoire de faire fonctionner à fond la carte graphique (catalyst) , ca tourne comme un charme
Veepee & UNIX-Experience
# Great !
Posté par Loïc Blot (site web personnel) . En réponse à la dépêche Movim 0.6 « Cumulus » dans les bacs, une 0.7 en préparation. Évalué à 3.
Je félicite les designer du projet pour la qualité visuelle du produit, c'est vraiment joli.
Reste à voir ensuite comment ce genre d'outil pourrait proliférer sur la toile, là où le centralisé domine et les gens n'ont pas la notion de "garder ses données chez soi"
Veepee & UNIX-Experience
[^] # Re: Je confirme que ça marche bien
Posté par Loïc Blot (site web personnel) . En réponse au journal Mon Raspberry pi a un uptime de 14 jours !. Évalué à 2.
root@ArchPi> uptime ~
18:44:54 up 4 days, 23:15, 1 user, load average: 0.00, 0.01, 0.05
Eh oui mise à jour du noyau de Archlinux pour Rasp de 3.2 vers 3.6 :)
Veepee & UNIX-Experience
[^] # Re: Et aussi ...
Posté par Loïc Blot (site web personnel) . En réponse à la dépêche Cuvée 18 pour Firefox et Firefox Mobile. Évalué à 2.
Le freeze de l'interface lors de la recherche DNS ? J'ai effectivement entendu parler de ce problème, mais je ne l'ai jamais rencontré au boulot. Ca arrive lors de connexions lentes ?
Veepee & UNIX-Experience
# Crypter n'est pas chiffrer
Posté par Loïc Blot (site web personnel) . En réponse au journal La lecture des cartes CPS sous linux. Évalué à 2. Dernière modification le 25 décembre 2012 à 14:02.
Attention on dit chiffrer et non crypter :(
Chapeau bas pour l'insertion du logiciel libre de manière aussi approfondie en médecine, je ne savais pas qu'il y en avait autant :)
Veepee & UNIX-Experience
# Félicitations
Posté par Loïc Blot (site web personnel) . En réponse à la dépêche Entretien avec Martin Peres, développeur Nouveau. Évalué à 0.
Bonsoir Martin, je tiens à te féliciter, il est rare de voir de jeunes étudiants Français aussi motivés. J'espère que tu sauras amener avec toi d'autres étudiants pour les développements dans le monde du logiciel libre, surtout avec ce qui se prépare sur Bordeaux en ce moment ! Merci pour tes contributions, qui serviront sur le moyen terme à tous.
Veepee & UNIX-Experience
[^] # Re: Davical ->Owncloud
Posté par Loïc Blot (site web personnel) . En réponse à la dépêche Sortie d’ownCloud 4.5.0. Évalué à 3.
Roundcude (0.7 et 0.8) intégré à Owncloud fonctionne parfaitement, il faut utiliser un système d'autologin roundcube. Je n'ai plus les informations mais c'est ce qui permet que roundcube authentifie l'utilisateur directement et qu'il aie accès à l'interface.
Veepee & UNIX-Experience
[^] # Re: Foodle
Posté par Loïc Blot (site web personnel) . En réponse au journal Doodle en libre. Évalué à 1.
Dommage je viens d'essayer avec mon login de l'université Paris Sud et cela plante.
Veepee & UNIX-Experience
[^] # Re: Troll
Posté par Loïc Blot (site web personnel) . En réponse à la dépêche Sortie d'OpenSSH 6.0. Évalué à 5. Dernière modification le 04 mai 2012 à 17:27.
6.0 suit 5.9 tout comme pour OpenBSD, et cela semble logique vu que c'est la même personne à sa tête, la version suivant 4.9 est 5.0, logique différente.
On aurait pu s'appeler SSH release 60 qui suit le release 59. Chez OpenBSD et donc OpenSSH, on ne privilégie pas le chiffre ni la quantité mais la qualité du release
Veepee & UNIX-Experience
[^] # Re: Ceci n'est pas un troll
Posté par Loïc Blot (site web personnel) . En réponse à la dépêche Sortie d'OpenBSD 5.1 « Bug Busters ». Évalué à 3.
oui c'est sûr que ca fait doublons, je pense que c'est pour montrer l'évolution au fur et à mesure des packages qu'ils ont choisi. Enfin c'est la politique OpenBSD, la communication n'est pas leur fort, ce sont leurs idées :)
Veepee & UNIX-Experience
[^] # Re: Ceci n'est pas un troll
Posté par Loïc Blot (site web personnel) . En réponse à la dépêche Sortie d'OpenBSD 5.1 « Bug Busters ». Évalué à 4. Dernière modification le 03 mai 2012 à 00:42.
si tu trouve ca léger, je te suggère de lire ce changelog (ca m'a pris environ 40 minutes le jour de la sortie, surtout vu que c'est trié par ordre chronologique je présume)
http://www.openbsd.org/plus51.html
Les rthread seront une révolution c'est clair, vivement novembre
Veepee & UNIX-Experience
[^] # Re: af-to & NAT64
Posté par Loïc Blot (site web personnel) . En réponse à la dépêche Sortie d'OpenBSD 5.1 « Bug Busters ». Évalué à 4.
très bonne conférence des jres, merci Patrick, je l'avais vue en live stream depuis mon bureau, cela m'a vraiment motivé à faire avancer le réseau que j'administre sur IPv6 (par ailleurs je suis en train d'étudier la migration de mes dual routeurs Debian + Squid NTLM + UCARP sur OpenBSD 5.1, et c'est très bien parti, surtout vu les packages du repo 5.1 qui sont pile dans les versions que j'attendais)
Veepee & UNIX-Experience
[^] # Re: systemd vs upstart
Posté par Loïc Blot (site web personnel) . En réponse à la dépêche Ubuntu 12.04 Precise Pangolin est sortie. Évalué à 0.
systemd est plus puissant dans sa gestion des services.
Il gère les services en target et non plus en runlevel. De plus il gère des dépendances entre service alors que sur systemV et upstart c'est le chiffre qui définit qui démarre en premier. Avec systemD tu as également la parallélisation du démarrage et de l'extinction des services suivant cette dépendances.
Par exemple admettons que tu as l'arbre de dépendances suivant:
syslog -> network -> apache
-> mysql -------V
-> openLDAP -> Freeradius
En bien systemD va démarrer syslog, car ne dépendant de rien, puis le démon réseau, ensuite les 3 services apache mysql et OpenLDAP en parallèle. Freeradius démarrera quand ton MySQL et ton LDAP seront UP
Ca c'est pour le démarrage, mais sinon en terme de gestion systemD se rapproche beaucoup des cgroups et c'est très puissant. En revanche pas pour le commun des mortels, mais dans un environnement de production fort sollicité oui.
Veepee & UNIX-Experience
[^] # Re: Changement de license
Posté par Loïc Blot (site web personnel) . En réponse à la dépêche OPA sur OpenStreetMap. Évalué à 0.
Tout à fait, le comble c'est notre bâtiment à Palaiseau. A environ 100m tu le vois comme maintenant et si tu zoome, à 50m tu le vois en construction (il y a le trou pour les fondations xD)
Veepee & UNIX-Experience
[^] # Re: Encore de l'anti-update...
Posté par Loïc Blot (site web personnel) . En réponse à la dépêche Rétrospective sur le noyau 2.6.32. Évalué à 2.
La différence entre les noyaux est effectivement la compatilibilité matérielle et le changement dans le code de certains sous systèmes du noyau, notamment. Un Noyau LTS sera patché pour combler des failles de sécurité et/ou stabiliser certains éléments. Si tu souhaite supporter des devices plus récents tu devras forcément passer à un noyau supérieur.
Veepee & UNIX-Experience
[^] # Re: Innovant
Posté par Loïc Blot (site web personnel) . En réponse à la dépêche Rétrospective sur le noyau 2.6.32. Évalué à 1.
Pour passer au patchset suivant, tu peux recompiler le noyau, effectivement, en le patchant dans un premier temps, puis en recompilant celui-ci ainsi le userland.
La plupart du temps les patchsets sont appliqués en majorité sur le userland, tout du moins sur 8.2 c'est ce que j'ai pu observer.
Si tu ne compiles pas ton noyau, ce qui est fortement envisageable et conseillé dans un environnement de production ne nécessitant pas l'optimisation des appels système, il suffit simplement de taper freebsd-update fetch install ce qui aura pour effet d'inspecter et passer ton système de 8.2-p4 à 8.2-p6 par exemple. Il faudra en revanche rebooter pour que le nouveau noyau soit pris en compte, tout comme sous Linux.
Veepee & UNIX-Experience