vendredi 05 février

Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Articles précédents : Sécurité

Liens connexes

Page d'accueil de Nulog2 (981 clics)
Captures d'écran de Nulog2 (1683 clics)
Projet NuFW (512 clics)
NuFW.live : le LiveCD de NuFW (307 clics)
INL : concepteur et auteur de l'application (246 clics)
L'annonce linuxfr de la alpha1 (134 clics)

Dépêche modérée par

Nyco

Dépêche éditée par

Sécurité : Nulog 2 est disponible

Posté par _gryzor_ (). Modéré le 18 janvier 2008.

Voici la 2ème génération de l'incontournable outil d'analyse de fichiers journaux de pare-feu. Nulog2, presque 6 ans après la v1, s'appuie toujours sur un format de journalisation SQL, mais présente les informations de manière plus synthétique, et beaucoup plus exploitable.

Au menu des nouveautés :

Réécriture complète du code, passage de PHP à Python avec Twisted Matrix ;
Génération à la volée de diagrammes et de camemberts, au souhait de l'utilisateur ;
Personnalisation totale de la page d'accueil, pour chaque utilisateur ;
Refonte de l'ergonomie de l'outil et de la manipulation des critères d'affichage des connexions réseaux ;
Possibilités de recherches beaucoup plus avancées ;
Export des données affichées en CSV pour traitement personnalisé ;
Passage à la licence GPLv3.

Bien entendu, Nulog2, permet, comme la v1, d'exploiter des logs authentifiés par un pare-feu NuFW. Il est donc très simple de créer ses propres indicateurs à placer sur sa page d'accueil, par exemple "Histogramme des derniers paquets droppés des trois dernières heures de l'IP 10.56.140.47 ou de l'utilisateur Martin".

Page d'accueil de Nulog2 (981 clics)
Captures d'écran de Nulog2 (1683 clics)
Projet NuFW (512 clics)
NuFW.live : le LiveCD de NuFW (307 clics)
INL : concepteur et auteur de l'application (246 clics)
L'annonce linuxfr de la alpha1 (134 clics)

> Lire la suite (19 commentaires, moyenne: 2,1). [dépêche : 603 caractères]

Nulog2 est intégré au liveCD NuFW.Live, sortie en RC1 le 17 janvier 2008. Ce liveCD de démonstration de NuFW et des outils associés (et donc entre autres Nulog) est distribué par INL pour faciliter les tests de NuFW et des outils associés. Les éventuels retours de testeurs seront donc les bienvenus par l'équipe de développement !

Bien sûr, Nulog2 est conçu pour fonctionner pour des pare-feus authentifiants NuFW, mais s'interface également très bien sur des pare-feu Netfilter sans authentification.

Nulog2 sera également présenté sur le stand d'INL au salon Solutions Linux.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

paquet Debian

Posté par err404 (Jabber id, page perso, ) le 19/01/2008 à 01:36. (lien). Évalué à 2.

La version "testing" de Nulog pour Debian est Nulog 2.0~rc1-1
malgré l'indication 2.0 il s'agirait tout de même de la version 1 ?
et le tilde il signifie quoi dans tout ça ?

[^]Re: paquet Debian

Posté par Misc (page perso, ) le 19/01/2008 à 11:24. (lien). Évalué à 2.
non, ça veut dire que c'est la version rc1. Je ne connait pas les détails, mais c'est utlisé pour dire "c'est une 2.0 mais pas tout à fait" ou un truc comme ça.
cf http://www.debian.org/doc/debian-policy/ch-controlfields.htm(...)

Je pense que les devs debian pourront mieux expliquer que moi.

[^]Re: paquet Debian

Posté par _pollux_ () le 19/01/2008 à 16:24. (lien). Évalué à 5.
C'est une version 2.0 rc1 (release candidate).

Le tilde est utilisé parce que le caractère - sert a différencier le numéro du paquet debian, du numéro de l'application.
En gros, x.y-1 et x.y-2 c'est la même application (même sources), c'est juste le packaging qui est différent.

De PHP à un framework Python

Posté par forc3 (page perso, ) le 19/01/2008 à 09:31. (lien). Évalué à 3.

Salut,
J'aurais bien voulu connaître la motivation de quitter PHP pour aller vers Python ?
Choix technologique ?
Changement de développeurs ?

Le retour d'expérience pourrait être utile à tout le monde...

[^]Re: De PHP à un framework Python

Posté par Misc (page perso, ) le 19/01/2008 à 11:40. (lien). Évalué à 3.
Bon, ça ressemble à un troll, mais je me lance.

La vérité sort de la bouche des infobots :

11:35:29| misc> blame php
11:35:30| fajita> blame php is PHP should be presumed to be at fault until conclusively proven otherwise. And even thereafter, if it's convenient.

fajita étant le bot du canal #apache et #apache-fr :)

( sinon, le fait de devoir maintenir un soft en php4 et php5 ( support sarge et etch et distro récentes en même temps), le fait que php ne soit pas si génial que ça comme language avec de nombreux effets de bord, le fait qu'il y a rien de la puissance de twisted en php sont à mon avis des arguments plus plausibles )

[^]Re: De PHP à un framework Python

Posté par Eric Leblond (page perso, ) le 19/01/2008 à 11:55. (lien). Évalué à 10.
La question est mieux posée dans le sujet que dans le corps du message. Il y a en effet deux choses séparées :
le passage d'un langage à un framework
le passage de PHP à Python

Le choix 1 est simple : J'ai commencé à travaillé sur nulog 1 (connu comme ulog-php à l'époque) aux alentours de 2001/2002 . La notion de framework n'était pas encore bien implantée (voir même n'existait pas). Début 2007, nulog commençait à devenir difficille à faire évoluer et nous avons donc décidé de lancer un projet de réécriture au sein d'INL (dont je fais parti). Le projet Nulog 2 a ainsi été initié avec dès le départ la décision d'utiliser un framework et une architecture MVC.

Le choix 2 s'explique par plusieurs points:

Grandes qualités du framework Twisted, notamment capacité à offrir des vues dans des protocoles variés (SOAP, XML-RPC, IRC, HTTP).
Présence de bons développeurs Python à INL, développeurs capable d'épauler Romain Bignon, développeur principal de Nulog 2.
Langage PHP trop laxiste et surtout lié au web alors que l'on souhaitait ne pas se limiter à ce media.

L'ensemble de ces raisons nous ont fait abandonner PHP pour passer à Python/Twisted.
- [^]Re: De PHP à un framework Python
  
  Posté par Jul (page perso, ) le 19/01/2008 à 14:57. (lien). Évalué à 1.
  Bien qu'en tant que mercenaire je fais du PHP avec plus de plaisir que du C#, cependant il faut reconnaître que PHP est chiant à cause de ses changements de comportements aléatoire :
  ex :
  sur deux PHP 5.3.2 j'ai eu les changements de comportements différents sur le même code :
  
  cas 1 trim change de comportement :
  $a=array ("a " => array ( "b" => " c ") );
  v1 : trim ($a) => array ("a" => array ("b" => "c" ))
  v2 : trim ($a) => array
  
  cas 2 implicit explicite :
  avec mes php.ini identiques j'ai eu le code suivant qui a marché un cas sur deux
  class log {
  private $cfg;
  private function w($msg) { $cfg["insource"] && echo "" }
  }
  Dans un cas php a pardonné que j'oublie $this->cfg
  dans l'autre il a fait un warning sans crasher :/ J'aurais mis du temps à trouver le bug si j'avais pas regardé les logs
  
  Et j'ai un 3 éme bug sur le changement de comportement des fonctions de localisation que je ne détaillerais pas.
  
  Et ceci sur deux versions de PHP identiques sauf au niveau du patchlevel :/
  
  Donc même si il y a des frameworks (cake/symfony) en php je pourrais pas faire entièrement faire confiance à un framework aussi bon soit-il quand l'interpréteur est aussi versatile.
  
  PS ce n'est pas parce qu'en logiciel libre on utilisait pas le jargon de framework au début que
  1) il n'existait pas (leur existence remonte à 1990 notamment dans les GUI notamment propriétaire, et dans la littérature dans les années 1986),
  2) le MVC est un design pattern : une façon de concevoir son code en séparant la vue des données. Un DP ne nécessite pas de code normalement, juste de bien concevoir son code. Mais bon quand il y a un "cadriciel ou framework" faut être maso pour s'en priver.
  - [^]Re: De PHP à un framework Python
    
    Posté par Jérôme FIX (page perso, ) le 19/01/2008 à 15:55. (lien). Évalué à 3.
    cas 1 trim change de comportement :
    $a=array ("a " => array ( "b" => " c ") );
    v1 : trim ($a) => array ("a" => array ("b" => "c" ))
    v2 : trim ($a) => array
    
    D'un autre côté, trim attend une chaîne de caractères en paramètre, tu lui passes un tableau.
    Ok il devrait te jeter plutôt que de faire une conversion implicite du tableau en chaîne de caractères; ce qu'il fait d'ailleurs si tu actives le niveau d'erreur :
    
    Notice: Array to string conversion in /var/www/html/test.php on line 4
    
    Call Stack:
    0.0002 92264 1. {main}() /var/www/html/test.php:0
    0.0003 93208 2. trim() /var/www/html/test.php:4
    
    Donc l'erreur est encore une fois entre la chaise et le clavier.
    
    Concernant la différence entre tes deux installations ... est tu vraiment sûr que ce sont les mêmes avec les mêmes options de compilation, la même configuration.
    - [^]Re: De PHP à un framework Python
      
      Posté par Jul (page perso, ) le 19/01/2008 à 16:03. (lien). Évalué à 1.
      oui je suis d'accord, il y avait dans les 2 premiers cas une erreur de syntaxe, mais bon, à mon goût un bon programme crash sur une erreur.
      
      Pour les options de compilations j'ai pas regardé. C'étaient 2 debian, mais je soupçonne que les sources apt étaient pas les même. Le projet étant charrette, et devant gérer des merdouilles sièges clavier (mienne comprises) tout le temps, le sysadmin qui sommeille au fond de moi n'a pas pu investiguer.
      
      Néanmoins, même si j'aurais bien aimé comprendre, après m'en être ouvert à d'autres anciens collègues qui ont quitté le PHP j'ai eu des échos de soucis similaires.
      - [^]Re: De PHP à un framework Python
        
        Posté par Jérôme FIX (page perso, ) le 19/01/2008 à 16:08. (lien). Évalué à 3.
        Le langage est à mon gout aussi beaucoup trop permissif par défaut, mais il est possible surtout en phase de développememt de configurer le serveur pour remonter la moindre pétouille (tes deux exemples par exemples) en direct ou par une gestion d'erreurs personnalisée (http://fr.php.net/manual/fr/ref.errorfunc.php) par exemple.
        
        [+] [^]Re: De PHP à un framework Python
        
        Posté par Jul (page perso, ) le 19/01/2008 à 16:11. (lien). Évalué à -4.
        permissif et versatile.
        
        Il est donc pas fiable => death penalty
        
        [^]Re: De PHP à un framework Python
        
        Posté par desfrenes (page perso, ) le 19/01/2008 à 17:59. (lien). Évalué à 2.
        Tu n'as pas peur pour libroscope alors ?
        
        Apache/1.3.34 (Debian) mod_gzip/1.3.26.1a PHP/5.2.5-0.dotdeb.2 with Suhosin-Patch mod_fastcgi/2.4.2 mod_ssl/2.8.25 OpenSSL/0.9.8c
        
        ;-)
        
        [+] [^]Re: De PHP à un framework Python
        
        Posté par Jul (page perso, ) le 19/01/2008 à 19:20. (lien). Évalué à -3.
        Le serveur est à jour justement parce que j'ai peur.
        
        PS j'ai pas pris apache 2 car je comprend tellement pas la licence que je suis même pas sûr que ce soit libre.
        
        [^]Re: De PHP à un framework Python
        
        Posté par Misc (page perso, ) le 19/01/2008 à 19:57. (lien). Évalué à 6.
        Perso, quand j'ai pas confiance dans une techno, je l'utilise pas. Bien sur, pour ça, faut avoir du temps, ou un emploi du temps flexible, ce qui est pas toujours le cas de tout le monde.
        
        Ensuite, la license apache v2 est approuvé par l'osi, par debian, et elle est compatible gpl v3.
        Et elle est aussi sur la liste de la fsf : http://www.gnu.org/licenses/license-list.html
        
        Pour un type qui marque : "Je n'ai aucun soucis pour travailler dans des environnements et des technologies non libre." sur son site web ( http://corpo.julbox.net/ ), je reconnait que ce genre de remarques me laissent dubitatif.
        
        [^]Re: De PHP à un framework Python
        
        Posté par Jul (page perso, ) le 20/01/2008 à 00:53. (lien). Évalué à 0.
        Misc: et tu loupes les fois où j'ai eu le droit à intégriste du libre, et castrateur du libre. Ca devrait te laisser encore plus perplexe.
        
        Pour apache comme pour tout autre licence, je ne vais pas prendre une licence que je ne comprend pas. Un point c'est tout.
        
        Et oui je fais du perl ou du php en environnement windows, mais je préfère aller confronter les logiciels libres en environnement de prod réel que faire des grands blablas sur la supériorité du libre. J'aime bien quand un client qui fait du c# se dit que lui aussi peut faire des projets libre ou en utiliser, ou que perl est peut être mieux que MS visual C++ pour développer. C'est sûrement plus dur que de convaincre un passionné du libre, et plus gratifiant quand on y arrive.
        
        Tiens d'ailleurs tu remarqueras que python a une implémentation libre en .net éditée, maintenue financée par microsoft.
        http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPytho(...)
        
        Les développeurs en technologie proprio s'y mettent, et ça ne me dérange pas. Car le libre n'est pas seulement dans la licence, ça consiste aussi et surtout à partager ses sources, à permettre d'utiliser, d'étudier, et de redistribuer. Alors que ce soit sous windows, mac, linux, que ce soit en perl, en ruby, en php en c#, je m'en fous.
        
        Voilà je suis pragmatique avant tout, et cela ne me pose pas de problème. Quand j'ai pas confiance dans quelque chose, je le surveille, je le cloisonne, jusqu'à ce que j'ai mieux.
        
        En ce qui me concerne je commence à trouver des imperfections à tous les langages, à tous les OS, et je fais avec.
        
        [^]Re: De PHP à un framework Python
        
        Posté par Jul (page perso, ) le 20/01/2008 à 01:14. (lien). Évalué à 1.
        Et microsoft a aussi son propre sourceforge.
        http://www.codeplex.com/
        Dont le pré-requis est :
        you MUST choose a licence, et les licences proposées inclues les licences OSI (sauf gpl v3)
        
        Et la licence du service :
        http://www.codeplex.com/CodePlex/license
        
        stipule que microsoft ne se donne aucun droit sur la création.
        
        Enfin, si faire du libre ça veut dire mépriser ceux qui font du libre en java, en csharp ou autre, on va peut être devenir sectaire, parce que la je vois pas où dans le libre il est dit que le logiciel libre doit être fait avec des technos "garanties 100% libre". Surtout que cela peut être sujet à caution (les cpus intel sont pas libre, les comité de normalisation ISO/IEEE/mpeg sont pas très ouverts ....)
        
        [^]Re: De PHP à un framework Python
        
        Posté par Antoine () le 20/01/2008 à 02:38. (lien). Évalué à 1.
        Tant que personne ne porte SPIP dans un autre langage que PHP, Libroscope n'a pas trop le choix :-)
        
        [^]Re: De PHP à un framework Python
        
        Posté par Gniarf () le 20/01/2008 à 16:55. (lien). Évalué à 2.
        jeter SPIP ?
        
        --
        "Je n'aime pas votre regard, baissez les yeux!" - Patrick Devedjian, 2008
        
        [^]Re: De PHP à un framework Python
        
        Posté par Antoine () le 20/01/2008 à 17:52. (lien). Évalué à 2.
        Eh bien, cher Gniarf, tu es le bienvenu pour proposer un remplaçant avec les mêmes fonctionnalités et la procédure de migration qui va bien. Vas-y, on t'écoute :)

Revenir en haut de page

Articles précédents : Sécurité

Liens connexes

Dépêche modérée par

Dépêche éditée par

Sécurité : Nulog 2 est disponible

paquet Debian

[^]Re: paquet Debian

[^]Re: paquet Debian

De PHP à un framework Python

[^]Re: De PHP à un framework Python

[^]Re: De PHP à un framework Python

[^]Re: De PHP à un framework Python

[^]Re: De PHP à un framework Python

[^]Re: De PHP à un framework Python

[^]Re: De PHP à un framework Python

[+] [^]Re: De PHP à un framework Python

[^]Re: De PHP à un framework Python

[+] [^]Re: De PHP à un framework Python

[^]Re: De PHP à un framework Python

[^]Re: De PHP à un framework Python

[^]Re: De PHP à un framework Python

[^]Re: De PHP à un framework Python

[^]Re: De PHP à un framework Python

[^]Re: De PHP à un framework Python